问题
Right now our Jenkins agents generate a docker-compose.yml for each of our Rails projects and then run docker-compose up. The docker-compose.yml has a main "web" container that has rbenv and all of our other Rails dependencies inside. It is linked to a DB container that contains the test Postgres DB.
The problem comes when we need to actually run the tests and generate exit codes. Our CI server will only deploy if the test script returns exit 0, but docker-compose always returns 0, even if one of the container commands fail.
The other issue is that the DB container runs indefinitely, even after the web container is done running the tests, so docker-compose up
never returns.
Is there a way we can use docker-compose for this process? We would need to be able to run the containers, but exit after the web container is complete and return it's exit code. Right now we are stuck manually using docker to spin up the DB container and run the web container with the --link option.
回答1:
Since version 1.12.0
, you can use the --exit-code-from
option.
From documentation:
--exit-code-from SERVICE
Return the exit code of the selected service container. Implies --abort-on-container-exit.
回答2:
docker-compose run
is the simple way to get the exit statuses you desire. For example:
$ cat docker-compose.yml
roit:
image: busybox
command: 'true'
naw:
image: busybox
command: 'false'
$ docker-compose run --rm roit; echo $?
Removing test_roit_run_1...
0
$ docker-compose run --rm naw; echo $?
Removing test_naw_run_1...
1
Alternatively, you do have the option to inspect the dead containers. You can use the -f
flag to get just the exit status.
$ docker-compose up
Creating test_naw_1...
Creating test_roit_1...
Attaching to test_roit_1
test_roit_1 exited with code 0
Gracefully stopping... (press Ctrl+C again to force)
$ docker-compose ps -q | xargs docker inspect -f '{{ .Name }} exited with status {{ .State.ExitCode }}'
/test_naw_1 exited with status 1
/test_roit_1 exited with status 0
As for the db container that never returns, if you use docker-compose up
then you will need to sigkill that container; that's probably not what you want. Instead, you can use docker-compose up -d
to run your containers daemonized, and manually kill the containers when your test is complete. docker-compose run
should run linked containers for you, but I have heard chatter on SO about a bug preventing that from working as intended right now.
回答3:
Building on kojiro's answer:
docker-compose ps -q | xargs docker inspect -f '{{ .State.ExitCode }}' | grep -v '^0' | wc -l | tr -d ' '
- get container IDs
- get last runs exit code for each container ID
- only status codes that does not start with '0'
- count number of non-0 status codes
- trim out white space
Returns how many non-0 exit codes were returned. Would be 0 if everything exited with code 0.
回答4:
If you're willing to use docker-compose run
to manually kick off your tests, adding the --rm
flag, oddly enough, causes Compose to accurately reflect your command's exit status.
Here's my example:
$ docker-compose -v
docker-compose version 1.7.0, build 0d7bf73
$ (docker-compose run kpi false) || echo 'Test failed!' # False negative.
$ (docker-compose run --rm kpi false) || echo 'Test failed!' # True positive.
Test failed!
$ (docker-compose run --rm kpi true) || echo 'Test failed!' # True negative.
回答5:
Use docker wait
to get the exit code:
$ docker-compose -p foo up -d
$ ret=$(docker wait foo_bar_1)
foo
is the "project name". In the example above, I specified it explicitly, but if you don't supply it, it's the directory name. bar
is the name you give to the system under test in your docker-compose.yml.
Note that docker logs -f
does the right thing, too, exiting when the container stops. So you can put
$ docker logs -f foo_bar_1
between the docker-compose up
and the docker wait
so you can watch your tests run.
回答6:
--exit-code-from SERVICE
and --abort-on-container-exit
don't work in scenarios where you need to run all containers to completion, but fail if one of them exited early. An example might be if running 2 test suits in concurrently in different containers.
With @spenthil's suggestion, you can wrap docker-compose
in a script that will fail if any containers do.
#!/bin/bash
set -e
# Wrap docker-compose and return a non-zero exit code if any containers failed.
docker-compose "$@"
exit $(docker-compose -f docker-compose.ci.build.yml ps -q | tr -d '[:space:]' |
xargs docker inspect -f '{{ .State.ExitCode }}' | grep -v 0 | wc -l | tr -d '[:space:]')
Then on your CI server simply change docker-compose up
to ./docker-compose.sh up
.
回答7:
You can see exist status with:
echo $(docker-compose ps | grep "servicename" | awk '{print $4}')
回答8:
docker-rails allows you to specify which container's error code is returned to the main process, so you CI server can determine the result. It is a great solution for CI and development for rails with docker.
For example
exit_code: web
in your docker-rails.yml
will yield the web
containers exit code as a result of the command docker-rails ci test
. docker-rails.yml
is just a meta wrapper around the standard docker-compose.yml
that gives you the potential to inherit/reuse the same base config for different environments i.e. development vs test vs parallel_tests.
回答9:
In case you might run more docker-compose services with same name on one docker engine, and you don't know the exact name:
docker-compose up -d
(exit "${$(docker-compose logs -f test-chrome)##* }")
echo %?
- returns exit code from test-chrome service
Benefits:
- wait's for exact service to exit
- uses service name, not container name
来源:https://stackoverflow.com/questions/29568352/using-docker-compose-with-ci-how-to-deal-with-exit-codes-and-daemonized-linked