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, 15 Sep 2014 18:46:34 GMT


Jay Buffington commented on AURORA-633:

There is one outstanding implementation issue I'd like some advice on how to resolve:

When you're using the docker containerizer with an executor the checkpoints include the absolute
path to the sandbox.  Inside the container those paths are usually something like {{/mnt/mesos/sandbox/}}
and outside they are something like {{/tmp/mesos/slaves/20140911-165408-1208029356-5050-1753-0/frameworks/20140814-221057-1208029356-5050-10525-0000/executors/thermos-1410558164938-jaybuff-devel-hello-world-0-60165cb7-9252-4a03-af3b-92d88b1472f3/runs/latest/sandbox/}}.

This means when the observer tries to display stdout/stderr it looks for them in {{/mnt/mesos/sandbox}}
which is wrong because the observer is always running outside the container.

I have two ways to fix this:
   * inside the container us a symlink to make the thermos_runner see pwd as the same dir
inside and outside the container
   * somehow tell the observer to send the stdout/stderr links to mesos master to display
those files.  It would need to know the master base url and framework uuid which could be
passed in by the scheduler UI via URL args.

Neither one of these solutions is ideal.  Thoughts?

> 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