hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7654) Support ENTRY_POINT for docker container
Date Wed, 09 May 2018 14:25:00 GMT

    [ https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468907#comment-16468907

Jason Lowe commented on YARN-7654:

{{docker logs -f}} does what we want (at least as of Docker 1.13.1 where I've been testing
it).  It grabs the logs from the beginning and then proceeds to follow it.  The concern that
it is a process that persists is no different than running with the foreground process, as
both are processes that will keep running and complete when the container completes.

bq.  Detach does not produce more accurate result than running in the foreground from docker
inspect point of view because operations to docker daemon via docker CLI are asynchronous
via docker daemon's rest api.

What I mean by more reliable is that the docker run with detach does not have races with the
docker daemon.  The docker run with detach will not complete until the container is running
(i.e.: completed localizing the image and finished launching), therefore the docker daemon
will definitely know about the container and its name.  That's why we haven't needed retries
on the inspect command in the past.  The converse with running in the foreground is very racy.
 We can't wait until it returns since the foreground process won't complete until the container
is done executing, but we don't know when the docker daemon will have started the container.
 It could be in a fraction of a second or it could be many minutes.

bq. docker logs does not seem to separate out stdout from stderr.

Hmm, it is working fine for me:
$ cat Dockerfile
FROM baseimage
ENTRYPOINT /bin/sh -c 'sleep 30;echo "Hello stdout!";echo "Hello stderr!" >&2'
$ sudo docker run -d 3e7a52965e43
$ sudo docker logs -f 31566fcf778647192bff7083580efe1c74524c6c451c0170914d286ba7652778 >/tmp/stdout
[the docker logs command does not complete until the container exits]
$ cat /tmp/stdout
Hello stdout!
$ cat /tmp/stderr
Hello stderr!

> Support ENTRY_POINT for docker container
> ----------------------------------------
>                 Key: YARN-7654
>                 URL: https://issues.apache.org/jira/browse/YARN-7654
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>    Affects Versions: 3.1.0
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Blocker
>              Labels: Docker
>         Attachments: YARN-7654.001.patch, YARN-7654.002.patch, YARN-7654.003.patch, YARN-7654.004.patch,
YARN-7654.005.patch, YARN-7654.006.patch, YARN-7654.007.patch, YARN-7654.008.patch, YARN-7654.009.patch,
YARN-7654.010.patch, YARN-7654.011.patch, YARN-7654.012.patch, YARN-7654.013.patch, YARN-7654.014.patch,
YARN-7654.015.patch, YARN-7654.016.patch, YARN-7654.017.patch, YARN-7654.018.patch, YARN-7654.019.patch,
YARN-7654.020.patch, YARN-7654.021.patch
> Docker image may have ENTRY_POINT predefined, but this is not supported in the current
implementation.  It would be nice if we can detect existence of {{launch_command}} and base
on this variable launch docker container in different ways:
> h3. Launch command exists
> {code}
> docker run [image]:[version]
> docker exec [container_id] [launch_command]
> {code}
> {code}
> docker run [image]:[version]
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message