Michael, check out https://issues.apache.org/jira/browse/MESOS-2060 for a recent feature to provide task launch hooks like you're asking about, although it acts as a master/slave-specific library rather than a task-specific prep step, so you'll have to customize the behavior based on some information about the task. Alternatively, you could use the upcoming Persistent Volumes feature ( https://issues.apache.org/jira/browse/MESOS-1554) in such a way that you first launch a task to prep the state in a volume, and after its completion launch the long-running docker task that uses that volume.
On Thu, Feb 19, 2015 at 6:45 PM, Michael Neale <[email protected]> wrote: > (in a vain help to try and clarify) - I started with a similar pattern to > what I have seen with redis - people ensure there is a redis on each host > listening on a known port so apps can use it (by setting a unique > constraint on host name, and then making sure number of instances == size > of cluster). I started doing the same thing with a service that provides > the volume data - this works great - but has to prepare the data *before* > the docker container launches - or perhaps just as it is launching (docker > can't see host mounts in bind mounts after it has launched - for boring > reasons...). > > On Fri Feb 20 2015 at 1:38:20 PM Michael Neale <[email protected]> > wrote: > >> well not specifically talking about the mesos containerizer - it was just >> something I tried. The main aim is to deploy containers that can be bind >> mounted in a volume which is "prepared" on the host - the container apps >> (docker apps) being deployed don't particularly care how that was prepared >> - just that it was there. I was hoping for another task (or something) that >> had run before had prepared it (in some cases it may simply be rsyncing >> some data in place, in others, mounting a device - result is the same - a >> volume/path can be provided to the docker container). >> >> Does that make a little more sense ? (a bit hard to explain). >> >> On Fri Feb 20 2015 at 1:23:46 PM Tim Chen <[email protected]> wrote: >> >>> Hi Michael, >>> >>> Can you elaborate how you use the Mesos containerizer to you prepare >>> your host? >>> >>> In general hooks are exactly for this purpose, which is underway right >>> now for defining the hooks in Mesos and also allowing it to be customized. >>> >>> Tim >>> >>> On Thu, Feb 19, 2015 at 6:18 PM, Michael Neale <[email protected]> >>> wrote: >>> >>>> I am currently using marathon and have a need to "prepare" the host in >>>> some cases (currently looking at mounting a volume that the task may need - >>>> how that device is created is out of band BTW). >>>> >>>> In theory this would be ideally done on some hook - but I am not sure >>>> where (the hook would be called before the task proper is launched) - it >>>> could be simply as part of a task launch script if a plain command. >>>> >>>> With the docker containerizer - I can actually use priv mode and >>>> control the host (if I want) - but then I would like to have this task run >>>> separately to the main marathon long running task (as it has extra access >>>> which normally apps don't need) - I could bind mount in the docker socket >>>> and launch a non priv container from within the mesos launched start >>>> container ... >>>> >>>> I can also use the default (?) mesos containerizer - which seems to let >>>> me run docker commands (ie bypassing the firstclass support in mesos for >>>> docker) but this "feels" like I am doing it wrong - is that wrong? >>>> >>>> So in summary: is there a concept of a pre-launch step, and should I be >>>> working around the docker containerizer by using the mesos default >>>> containerizer instead? >>>> >>>> pointers appreciated. >>>> >>> >>>
