[
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:
{noformat}
$ cat Dockerfile
FROM baseimage
ENTRYPOINT /bin/sh -c 'sleep 30;echo "Hello stdout!";echo "Hello stderr!" >&2'
$ sudo docker run -d 3e7a52965e43
31566fcf778647192bff7083580efe1c74524c6c451c0170914d286ba7652778
$ sudo docker logs -f
31566fcf778647192bff7083580efe1c74524c6c451c0170914d286ba7652778 >/tmp/stdout
2>/tmp/stderr
[the docker logs command does not complete until the container exits]
$ cat /tmp/stdout
Hello stdout!
$ cat /tmp/stderr
Hello stderr!
{noformat}
> 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}
> h3. Use ENTRY_POINT
> {code}
> docker run [image]:[version]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
