[
https://issues.apache.org/jira/browse/AURORA-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126087#comment-14126087
]
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 container
* 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 libmesos.so 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: https://issues.apache.org/jira/browse/AURORA-633
> 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:
> https://github.com/tnachen/mesos/wiki/DockerInfo-design
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
