Conversation
This is a dummy/strawman prototype for a new command, `rkt fly`, which executes a single application image with no constraints or pod. This still performs an exec() so retains the basic rkt process model (i.e. any constraints applied to the rkt process are inherited), but has no further lifecycle tracking beyond the execution stage. Essentially, it just: - extracts an application image - chroots into the image - execs the app image's command (and any additional args) Follows the same syntax as `rkt run` Several TODOs/outstanding questions inline.
There was a problem hiding this comment.
where's rktApps coming from? if it's a global var somewhere, can it be refactored to make it local somehow?
There was a problem hiding this comment.
Almost certainly, I don't like the global var, was just cribbing from rkt
run
On Thu, Jun 18, 2015 at 3:31 PM, Eugene Yakubovich <[email protected]
wrote:
In rkt/fly.go
#1072 (comment):
Long: `IMAGE should be a string referencing an image; either a hash, local file on disk, or URL.`,Run: runWrapper(runFly),- }
+)
+func init() {
- cmdRkt.AddCommand(cmdFly)
- // Disable interspersed flags to stop parsing after the first non flag
- // argument. All the subsequent parsing will be done by parseApps.
- // This is needed to correctly handle image args
- cmdFly.Flags().SetInterspersed(false)
+}
+func runFly(cmd *cobra.Command, args []string) (exit int) {
- err := parseApps(&rktApps, args, cmd.Flags(), true)
where's rktApps coming from? if it's a global var somewhere, can it be
refactored to make it local somehow?—
Reply to this email directly or view it on GitHub
https://github.com/coreos/rkt/pull/1072/files#r32785941.
|
|
|
Agreed - should have mentioned I'm curious on more general feedback about On Thu, Jun 18, 2015 at 3:39 PM, Eugene Yakubovich <[email protected]
|
|
We still need to gc these runs somehow, correct? How will it interact with |
|
These exit when the app exists so there's no need for the mark phase of gc. But it still needs to be sweeped. |
There was a problem hiding this comment.
In the case that execpath is a symlink, this check will fail. Maybe change order to chroot first, then stat execargs[0]
|
@jonboulle yes I noticed this issue, ok noted for the commit. I will give it time when I'm blocked with the kernel uidshift. OK thanks! |
|
This feature looks extremely interesting for integration with Mesos and like systems -- it would allow us to use the Mesos isolator with Rocket provisioning. Looking forward to seeing this! |
|
this would be helpful for things like monitoring agents (e.g zabbix) who support custom user parameters, so is there a plan when this comes into rkt? |
|
@f0 yes we are working on this one |
|
@tixxdz do you want to put up your latest branch in another PR? |
|
@jonboulle what is rationale behind this ? is performance an only incentive here or there other features I don't see ? If we eliminate nspwan+systemd we lose isolation(namespaces), manageability(supervising), other helpers(diagexec/volumes/network modes) - I can see value in simplicity (distribution/chroot+exec), but if in future we will add some missing features (like namespaces/bind mounting) we will end up with re implementing nspwan in go (as proposed here #1318). What I expect as end user is clear distinction between these two commands:
why not just create another flavor called "just chroot/exec" as stage1 ? |
|
@jonboulle ok will push it. @ppalucki for the rationale please refer to #1046 @ppalucki "why not just create another flavor called "just chroot/exec" as stage1 ?" well the intended behaviour was to separate the traditional "run" from the "fly" so another flavor is perhaps not the best solution here. With rkt fly the pid and possibly other namespaces will be shared with the host. And yes if rkt fly does not have a clear scope we may reimplement things and nspawn in go... GoalExecute a single application image with no constraints or pod. No init or systemd, so we can share the pid, uts and ipc namespaces easily with the host. @jonboulle @ppalucki @philips yes I also think that we should continue with nspawn+systemd where it's possible. nspawn supports --share-system switch to share other namespaces. In this case containers will not be registered in machined, so they will have basic rkt listing, and I think we should not care about gc'ing them? ping @eyakubovich So, this can be implemented using two solutions: 1) extract+execExtracts an application image, chroots into the image and execs the app image's command. Additionally we may create new mount and network namespaces, users may need this, please see these comments: Only a new mount and network namespaces, it will allow us to cope with solution 2) nspawn and we continue to share the pid namespace. I guess it does not hurt. 2) nspawnUse nspawn --share-system, I think this is the best solution. Why ? it will allow us to support the first use case easily (share the pid namespace) + support user namespaces where an application or a monitoring app will run with a different uid. It will have access to the pid namespace, monitor apps without being affected by other users or any resources limits. "rkt fly --private-users" to run as a different user. Why "--private-users" only with nspawn ? well nspawn does some other chown, mkdir uid shifts that we do not want to implement in rkt. Thoughts ? |
|
@jonboulle the PR that implements solution 1) extract+exec without creating a new mount namespace is here #1416 I believe the only missing part for this one is perhaps to replace the chroot with a new mount namespace, yes waiting for more feedback and use cases for it. Finally in case we add a new mount namespace perhaps we will also need to make the root tree shared and the container one slave so mounts are propagated into the container as it's done in nspawn by default! #1046 (comment) |
|
Closing in favour of #1416 |
8 participants
This is a dummy/strawman prototype for a new command,
rkt fly, whichexecutes a single application image with no constraints or pod.
This still performs an exec() so retains the basic rkt process model
(i.e. any constraints applied to the rkt process are inherited), but has
no further lifecycle tracking beyond the execution stage.
Essentially, it just:
Follows the same syntax as
rkt runSeveral TODOs/outstanding questions inline.