Hi Michael, If you're only launching docker containers, one possibility is to also use the new powerstrips extension for Docker:
https://github.com/ClusterHQ/powerstrip You can override default docker behaviors and do custom actions on the host before a container is launched. Note this is not a production ready solution as it's claimed on the github site. Tim On Sun, Feb 22, 2015 at 5:16 PM, Michael Neale <[email protected]> wrote: > Hi Adam - yes the hooks one possibly fit the bill - not entirely clear how > to use it yet. The peristent one *should* work, but the problem for me > isn't so much the management of volume, but the preparation of it (I have > no need to make tasks sticky when the data can freely move around anyway). > > On Sun Feb 22 2015 at 8:04:58 PM Adam Bordelon <[email protected]> wrote: > >> 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. >>>>>> >>>>> >>>>> >>
