从Docker容器内部读取rsync文件？

Question

We are using Docker for the build/deploy of a NodeJS app. We have a test container that is built by Jenkins, and executes our unit tests. The Dockerfile looks like this:

FROM node:boron

# <snip> some misc unimportant config here

# Run the tests
ENTRYPOINT npm test

I would like to modify this step so that we run npm run test:cov , which runs the unit tests + generates a coverage report HTML file. I've modified the Dockerfile to say:

# Run the tests + generate coverage
ENTRYPOINT npm run test:cov

... which works. Yay!

...But now I'm unsure how to rsync the coverage report ( generated by the above command inside the Dockerfile ) to a remote server.

In Jenkins, the above config is invoked this way:

docker run -t test --rm

which, again, runs the above test and exists the container.

how can I add some additional steps after the entrypoint command executes, to (for example) rsync some results out to a remote server?

Answer 1

Make a script to execute as the entrypoint and put the commands in the script. You pass in args when calling docker run and they get passed to the script.

The docs have an example of the postgres image's script. You can build off that.

Docker Entrypoint Docs

Answer 2

I am not a "node" expert, so bear with me on the details.

First of all, you may consider if you need a separate Dockerfile for running the tests. Ideally, you'd want your image to be built, then tested, without modifying the actual image.

Building a test-image that uses your NodeJS app as a base image ( FROM my-nodejs-image ) could do the trick, but may not be needed if all you have to do is run a different command / entrypoint on the image.

Secondly; stateful data (the coverage report falls into that category) should not be stored inside the container (ie, not stored on the container's filesystem). You want your containers to be ephemeral, and anything that should live beyond the container's lifecycle (anything that should be preserved after the container itself is gone), should be stored outside of the container; either in a "volume", or in a bind-mounted directory.

Let me start with the "separate Dockerfile" point. Let's say, your NodeJS application Dockerfile looks like this;

FROM node:boron

COPY package.json /usr/src/app/
RUN npm install && npm cache clean
COPY . /usr/src/app

CMD [ "npm", "start" ]

You build your image, and tag it, for example, with the commit it was built from;

docker build -t myapp:$GIT_COMMIT .

Once the image was built succesfully, you want to test it. Probably a quick test to verify it actually "runs". Many ways to do that, perhaps something like;

docker run \
  -d \
  --rm \
  --network=test-network \
  --name test-{$GIT_COMMIT} \
  myapp:$GIT_COMMIT

And a container to test it actually does something;

docker run --rm --network=test-network my-test-image curl test-{$GIT_COMMIT}

Once tested (and the temporary container removed), you can run your coverage tests, however, instead of writing the coverage report inside the container, write it to a volume or bind-mount. You can override the command to run in the container with docker run ;

mkdir -p /coverage-reports/{$GIT_COMMIT}
docker run \
  --rm \
  --name test-{$GIT_COMMIT}\
  -v /coverage-reports/{$GIT_COMMIT}:/usr/src/app/coverage \
  myapp:$GIT_COMMIT npm run test:cov

The commands above;

• Create a unique local directory to store the test-artifacts (coverage report)
• Runs the image you built (and tagged myapp:$GIT_COMMIT )
• Bind-mount the /coverage-reports/{$GIT_COMMIT} into the container at usr/src/app/coverage
• Runs the coverage tests (which will write to /usr/src/app/coverage if I'm not mistaken - again, not a Node expert)
• Removes the container once it exits

After the container exits, the coverage report is stored in /coverage-reports/{$GIT_COMMIT} on the host. You can use your regular tools to rsync those where you want.

As an alternative, you can use a volume plugin to write the results to (eg) an s3 bucket, which saves you from having to rsync the results.

Once tests are successful, you can docker tag the image to bump your application's version (eg docker tag myapp:1.0.12345 ), docker push to your registry, and deploy the new version.