(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. >>> >> >>
