stage1: support interactive containers #601
Conversation
| @@ -147,6 +147,10 @@ func (c *Container) appToSystemd(ra *schema.RuntimeApp, am *schema.ImageManifest | |||
| newUnitOption("Service", "Group", app.Group), | |||
| } | |||
|
|
|||
| if interactive { | |||
| opts = append(opts, newUnitOption("Service", "StandardInput", "tty")) | |||
There was a problem hiding this comment.
Can we add the same for StandardOutput? The default of StandardOutput is journal. I'm not sure how it works, maybe the journal is redirected to /dev/console, which systemd-nspawn has created as a pseudoterminal.
iaguis
force-pushed
the
iaguis/connect-tty
branch
2 times, most recently
from
198cd1f
to
69abcd5
Compare
|
Thanks for the reviews! |
| func AppImagesPath(root string) string { | ||
| return filepath.Join(Stage1RootfsPath(root), stage2Dir) | ||
| } | ||
|
|
||
| // AppImagePath returns the path where an app image (i.e. unpacked ACI) is rooted (i.e. | ||
| // where its contents are extracted during stage0), based on the app image ID. | ||
| func AppImagePath(root string, imageID types.Hash) string { |
There was a problem hiding this comment.
return filepath.Join(AppImagesPath(root), types.ShortHash(imageID.String())
|
One nit but LGTM; @vcaputo could you please take another look? |
By using systemd's Standard{Input,Output,Error} options we set
/dev/console in stage1 as the tty for the app (see systemd.exec(5)).
This makes interactive executables like bash work with rkt run (or
prepare+run-prepared).
This is only supported if the container has only one app.
iaguis
force-pushed
the
iaguis/connect-tty
branch
from
69abcd5
to
19b1d24
Compare
|
LGTM |
|
awesome, thanks again @iaguis |
stage1: support interactive containers
|
my apologies for chiming into this thread really late. I have a couple of questions around the interactive mode. Is there a way to disable support for interactive mode for rocket containers? If I would like my containers to be not accessed interactively at or after they launched , what would be my best option? |
|
@prabhuinbarajan you can just not use |
|
@alban , thanks. Sorry, my earlier query was unclear to begin with - so let me give you my context. I am trying to get to a state where neither my container management run time , nor containers support any ability to ssh / terminal access. In the docker world, the equivalent of this seems to be the docker attach, docker run commands that seems to provide the ability to modify the container state (atleast theoretically) after the container is deployed. I may not be describing this accurately , but if we were to compose a ideal 12 factor app, it is my humble opinion that the container management runtime would not need the ability to support interactive shells. Bizzare as it might seem, reason for this is certain industry segments (ex: fintech) where regulatory requirements such as PCI require hard proof of access, ability to prove that the container states were not modified post deploy etc. An appropriate balance might be if rkt at compile time can take an option on whether or not to support interactive , that would be ideal. if the request seems fair to you, i would be happy to submit a PR. Also would love to hear your thoughts on whether appc would have some security guidance around interactive containers. |
|
rkt does not support the equivalent of I am not familiar with those regulatory requirements and I am not sure to understand what that would involve. Could you open a new issue to discuss this? /cc @mjg59 |
|
@prabhuinbarajan that actually fits very nicely with rkt's design/goals - from the beginning we've not emphasised features like interactive mode (arguably, at the expense of usability), because we intend rkt be used in environments where it shouldn't be necessary (and as you note is in some cases actively discouraged or forbidden) I'd definitely be receptive to a patch making it configurable at build time. I'm not really sure whether this should be specifically for just this flag or more general. |
By using systemd's StandardInput option we set /dev/console in stage1
as the tty for the app (see systemd.exec(5)). This makes interactive
executables like bash work with rkt run (or prepare+run-prepared).
This is only supported if the container has only one app.
Fixes #562