aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Buffington (JIRA)" <>
Subject [jira] [Commented] (AURORA-633) Support running Docker containers
Date Mon, 08 Sep 2014 21:02:29 GMT


Jay Buffington commented on AURORA-633:

We have this implemented (but haven't got approval to open source it, yet). There are two
ways to start a container, with and without the executor:
   * When you specify {{processes}} in the Task, Aurora will start the executor in the docker
   * When you don't specify {{processes}} in the Task, docker will run the ENTRYPOINT or last
CMD specified in Dockerfile.  

When using the executor there are a couple of caveats: 
   * If you specify an ENTRYPOINT and {{processes}} your task will fail to launch.  See MESOS-1761.
   * The scheduler tells the slave to copy the executor into the mesos sandbox directory,
and then mounts it along with the /libs that et al are in and then uses LD_LIBRARY_PATH.
 However, your image will have to contain a python that can start the executor.

When you don't use the executor there are also a couple of caveats: 
    * the thermos observer will not know about your task.  We're considering changing the
"host" link on the job page to point to the task sandbox browser in Mesos rather than the
thermos observer page for tasks that do not use the executor.
    * your job instances will never go through the {{STARTING}} state.  

Since the mesos-slave will be the process that does the {{docker pull}} before starting the
container the job instance will be in state {{ASSIGNED}} while the bits are being downloaded.
 Downloading happens between the time the scheduler sends taskLaunch and when the mesos master
sends the first statusUpdate.  If downloading takes longer than {{--transient_task_state_timeout}}
command line flag the scheduler will assume {{TASK_LOST}}, kill it and reschedule.  Updates
will also be affected, in that the task won't be in {{RUNNING}} until the download is complete,
so users should expect a much longer {{restart_threshold}} in their update config.

> Support running Docker containers
> ---------------------------------
>                 Key: AURORA-633
>                 URL:
>             Project: Aurora
>          Issue Type: Epic
>          Components: Client, Scheduler
>            Reporter: Jay Buffington
>            Assignee: Jay Buffington
> Mesos 0.20 will be released soon, and it will likely include support for a docker containerizer.
 See MESOS-1524.
> To make use of this feature, I propose modifying aurora's DSL to support running docker
containers both with and without the aurora executor.
> Task would be changed to introduce a container field and make processes optional when
a container is specified.  A Task to launch a Docker container using the entry point (aka
command) specified in the container would look like this:
> {noformat}
> Task(
>     name="my-task",
>     container=Docker(
>         image="docker:///centos:6u5',
>     ),
>     resources=Resources(cpu=1, disk=10*GB, ram=1*GB)
> )
> {noformat}
> If you specify processes in your Task then the docker containerizer will fetch and launch
the aurora executor for you.  This would run {{process_a}} then {{process_b}} inside the same
docker container using the aurora executor:
> {noformat}
> Task(
>     name="my-task",
>     container=Docker(
>         image="docker:///centos:6u5',
>     ),
>     processes=[process_a, process_b],
>     constraints=order(process_a, process_b),
>     resources=Resources(cpu=1, disk=10*GB, ram=1*GB)
> )
> {noformat}
> The Docker() struct would closely model the fields that will be in the DockerInfo protobuf
message detailed here:

This message was sent by Atlassian JIRA

View raw message