Завершить докер скомпоновать, когда тестовый контейнер заканчивается
В настоящее время я запускаю стековый пакет для док-станции для базовых тестов интеграции с тестовым бегуном-поставщиком, сервером nodejs, обслуживающим веб-страницу, и сервером wildfly, обслуживающим Java-сервер.
Стек запускается из контейнера dind (docker in docker) на моем сервере сборки (concourse ci).
Но, похоже, что контейнеры не заканчиваются при завершении испытаний транспортира.
Итак, поскольку контейнеры для wildfly и nodejs все еще запущены, задача сборки никогда не заканчивается...
Как я могу сделать конец композиции успешным или неудачным, когда тесты будут завершены?
# Test runner
test-runner:
image: "${RUNNER_IMG}"
privileged: true
links:
- client
- server
volumes:
- /Users/me/frontend_test/client-devops:/protractor/project
- /dev/shm:/dev/shm
entrypoint:
- /entrypoint.sh
- --baseUrl=http://client:9000/dist/
- /protractor/conf-dev.js
- --suite=remember
# Client deployment
client:
image: "${CLIENT_IMG}"
links:
- server
# Server deployment
server:
image: "${SERVER_IMG}"
Ответы
Ответ 1
Подобно этому rspec q/a, вам нужно запустить тесты как отдельную задачу, которая сообщит о состоянии выхода обратно вашему CI.
Вы можете разделить тест-бегун на его собственный yaml или изменить тест-бегун по умолчанию на команду no op/entrypoint.
Отдельный бегун
Укажите конфигурацию test-runner
отдельно (вам может потребоваться обновление до networks
версии 2 вместо использования links
для работы с несколькими файлами компоновки).
docker-compose up -d
docker-compose -f test-runner.yml run test-runner
rc=$?
docker-compose down
exit $rc
Нет оп тестового бегуна
По умолчанию для test-runner
используется точка входа/команды no op, а затем вручную запускается тестовая команда
services:
test-runner:
image: "${RUNNER_IMG}"
command: 'true'
затем
docker-compose up -d
docker-compose run test-runner /launch-tests.sh
rc=$?
docker-compose down
exit $rc
Коды возврата
Если ваш CI имеет концепцию "пост-задач", вы можете пропустить захват rc
и просто запустить docker-compose down
после того, как задача CI тестового бегуна завершена. Также возможно, что ваш CI очищает контейнеры для вас.
Ответ 2
Вы можете использовать эти параметры docker-compose для достижения этого:
--abort-on-container-exit
Останавливает все контейнеры, если какой-либо контейнер был остановлен.
--exit-code-from
Возвращает код выхода выбранного сервисного контейнера.
Например, имея этот docker-compose.yml
:
version: '2.3'
services:
elasticsearch:
...
service-api:
...
service-test:
...
depends_on:
- elasticsearch
- service-api
Следующая команда гарантирует, elasticsearch
и service-api
работу после завершения service-test
, и вернет код выхода из контейнера service-test
:
docker-compose -f docker-compose.yml up \
--abort-on-container-exit \
--exit-code-from service-test
Ответ 3
Решение, которое я считаю самым элегантным, заключается в использовании depends_on
в вашем файле docker-compose.yml
.
services:
dynamodb:
...
test_runner:
...
depends_on:
- dynamodb
Теперь вы можете использовать docker-compose run --rm test_runner
, который будет настраивать ваши зависимости, запускать тесты, сбрасывать все и распространять код возврата.
docker-compose run test_runner false
Starting test_dynamodb_1 ... done
echo $?
1
docker-compose run test_runner true
Starting test_dynamodb_1 ... done
echo $?
Ответ 4
Чтобы избежать наличия отдельных файлов конфигурации, вы можете обновить конфигурацию docker-compose, чтобы представить зависимости между службами с параметром depen_on, доступным в формате версии 2 и выше. В результате запуск test-runner
инициирует запуск клиентов.
Обратите внимание, что если вам нужно подождать некоторое время, когда настоящий веб-сервер будет запущен из служб, которые вы тестируете, вы можете использовать скрипт wait-for-it.sh, чтобы дождаться, пока сервер не станет доступным.
# Test runner
test-runner:
image: "${RUNNER_IMG}"
privileged: true
links:
- client
- server
volumes:
- /Users/me/frontend_test/client-devops:/protractor/project
- /dev/shm:/dev/shm
depends_on:
- client
entrypoint:
- wait-for-it.sh
- client
- -t
- '180'
- --
- /entrypoint.sh
- --baseUrl=http://client:9000/dist/
- /protractor/conf-dev.js
- --suite=remember
# Client deployment
client:
image: "${CLIENT_IMG}"
depends_on:
- server
links:
- server
# Server deployment
server:
image: "${SERVER_IMG}"
После обновления конфигурации простой docker-compose up test-runner
запустит соответствующие сервисы.
Ответ 5
Я попробовал решение, предлагаемое в этом обсуждении, но проблема все еще в случае
Случай 1: составление докера -d
Вы можете использовать docker-compose up -d
, проверить его с помощью test-runner
docker-compose up -d
, а затем завершить с помощью docker-compose down
но проблема при использовании docker-compose up -d
заключается в том, что вы не увидите журналы стандарта выходной больше.
Случай 2: docker-compose up - exit-code -f из службы
Вы можете просмотреть журналы докера, если вы используете --exit-code-from <service>
который подразумевает --abort-on-container-exit
но служба не отправит команду выхода, когда это будет успешно выполнено. Затем вам нужно поймать, что ваш контейнер закончен, перед отправкой docker-compose down
чтобы остановить их.
Одним из решений для просмотра журналов перед их завершением является использование --tail=1000 -f
docker-compose up -d
docker-compose logs --tail=1000 -f test-runner
docker-compose down
exit $rc
Существует также решение, использующее nohup
но вам нужно подождать, пока процесс не будет полностью завершен, затем открыть файл выходных журналов, так что описанное выше должно быть проще
Ответ 6
Вы можете выполнять задачи очистки с помощью ensure
на шаге задачи в Зале. https://concourse-ci.org/ensure-step.html
В вашем случае вы можете добавить блок ensure
после испытаний вашего транспортиратора и запустить задачу, чтобы снести то, что раньше было docker-compose
'd. Вы также можете использовать шаг on-success
https://concourse-ci.org/on-success-step.html, чтобы сделать отрыв, а контейнеры docker-compose
'd будут храниться, если ваш тесты терпят неудачу.