How stdout-stderr work with docker containers?

Question

I remember that, stdin, stdout & stderr are first 3 entries of file descriptor table in Process control block.

On a AWS EC2 instance(host1), We have jenkins slave(say slave-container).

slave-container consist of docker client that talks to docker daemon running on host1

slave-container launches another docker container(say build-container to build source code) on host1.

Below is the pipeline output from slave-container:

Running on slave-container in /var/jenkins_home/workspace/abc-app
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Buildabcapp)
[Pipeline] sh
+ docker inspect -f . 111111111110.dkr.ecr.us-east-1.amazonaws.com/someteam/abc-build:7-jdk.x.2
.
[Pipeline] withDockerContainer
slave-container seems to be running inside container 55664444444444444444444444444444444444444444
$ docker run -t -d -u 9000:9000 -w /var/jenkins_home/workspace/abc-app --volumes-from 55664444444444444444444444444444444444444444  111111111110.dkr.ecr.us-east-1.amazonaws.com/someteam/abc-build:7-jdk.x.2 cat
[Pipeline] {
[Pipeline] sh
+ grep -q success
+ echo Yes

Above docker run command launches build-container that runs shell commands that gives output on stdout of slave-container:

+ grep -q success
+ echo Yes

How stdout/stderr of build-container shown on stdout of slave-container?

See! `{}` has nothing to do with suppressing outputs (as discussed with you here: https://stackoverflow.com/questions/56960876/jenkins-pipeline-how-to-read-the-success-status-of-build/56962094#56962094). Also instead of integrating all your things together then start trying to figure things out, I would do one step at a time. Jenkins is the important factor here, not docker I believe. — Perplexabot, Jul 12 '19 at 17:52
Anything with a `+` before it is most likely due to `Jenkins` not `docker` — Perplexabot, Jul 12 '19 at 17:58

score 1 · Answer 1 · answered Jul 12 '19 at 15:54

The Docker Engine exposes an API that is consumed by the docker client when you run different commands.

In the particular case of running docker run without the -d parameter the client uses the endpoints:

POST /containers/create - For creating the container

POST /containers/(id or name)/attach - For attaching to the container and stream the stdout and stderr to the client.

For more information check the API docs: https://docs.docker.com/engine/api/v1.24/#31-containers

But in my case... it has `-d` – overexchange Jul 12 '19 at 16:55 — overexchange, Jul 12 '19 at 16:55

Perplexabot · Answer 2 · 2019-07-12T18:06:05.943

The reason for your unexpected behavior is because Jenkins runs all sh functions with set -x prior to the actual shell commands. Look here if you are not familiar with set -x.

This can be proved by inspecting Jenkins source code for the sh function, look:

public String[] buildCommandLine(FilePath script) {
    if(command.startsWith("#!")) {
        // interpreter override
        int end = command.indexOf('\n');
        if(end<0)   end=command.length();
        List<String> args = new ArrayList<>(Arrays.asList(Util.tokenize(command.substring(0, end).trim())));
        args.add(script.getRemote());
        args.set(0,args.get(0).substring(2));   // trim off "#!"
        return args.toArray(new String[0]);
    } else
        return new String[] { getDescriptor().getShellOrDefault(script.getChannel()), "-xe", script.getRemote()};
}

As you can see in the default case it runs with a set -x and set -e. You can override that behavior by preceding your script with a shebang.

Those commands are coming from docker container that has no jenkins... please check the `docker run` command that has image argument(`55664444444444444444444444444444444444444444 `) — overexchange, Jul 12 '19 at 18:33
I see the line you are talking about and I still think this is related to `Jenkins` vs `docker` . I think it would be useful if you add the relevant portion of your `Jenkinsfile` . — Perplexabot, Jul 12 '19 at 18:47

How stdout-stderr work with docker containers?

2 Answers2