docker - Terminar la ventana acoplable componer cuando finalice el contenedor de prueba

docker-compose concourse

Question

Actualmente estoy ejecutando una pila de composición acoplable para las pruebas de integración básicas con un corredor de prueba de transportadores, un servidor nodejs que sirve una página web y un servidor wildfly que sirve un servidor Java.

La pila se ejecuta desde un contenedor dind (docker in docker) en mi servidor de compilación (concourse ci).

Pero parece que los contenedores no terminan al terminar las pruebas del transportador.

Entonces, como los contenedores para wildfly y nodejs todavía están ejecutando, la tarea de compilación nunca termina ...

¿Cómo puedo hacer que la composición finalice con éxito o fracaso cuando las pruebas hayan finalizado?

# 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}"

Answer 1

La solución que encontré más elegante es utilizar depends_on en su archivo docker-compose.yml .

services:
dynamodb:
...
test_runner:
...
depends_on:
- dynamodb

Ahora puede usar la docker-compose run --rm test_runner que configurará sus dependencias, ejecutará sus pruebas, eliminará todo y propagará el código de retorno.

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 $?

Answer 2

Puede realizar tareas de limpieza utilizando ensure en un paso de tarea en Concourse. https://concourse-ci.org/ensure-step.html

En su caso, podría agregar un bloque de garantía después de las pruebas de su transportador y ejecutar una tarea para derribar lo que antes se docker-compose . También puede usar un paso de on-success https://concourse-ci.org/on-success-step.html para hacer el desmontaje, y los contenedores y los contenedores de la docker-compose se mantendrían si sus pruebas fallan.

Answer 3

Puede utilizar estos parámetros de composición acoplable para lograr eso:

--abort-on-container-exit Detiene todos los contenedores si se detuvo algún contenedor.

--exit-code-from Devuelve el código de salida del contenedor de servicio seleccionado.

Por ejemplo, tener este docker-compose.yml :

version: ''2.3''
services:
elasticsearch:
...
service-api:
...
service-test:
...
depends_on:
- elasticsearch
- service-api

El siguiente comando asegura que elasticsearch y service-api se service-api vez finalizada service-test , y devuelve el código de salida del contenedor service-test :

docker-compose -f docker-compose.yml up /
--abort-on-container-exit /
--exit-code-from service-test

Answer 4

Similar a este rspec q / a , debe ejecutar las pruebas como una tarea independiente que informe un estado de salida a su CI.

Podría separar el corredor de prueba en su propio yaml o modificar el corredor de prueba para que se establezca por defecto en un comando no op / entrypoint.

Separa el corredor de prueba

Especifique la configuración del test-runner separado (Es posible que deba actualizar a las networks versión 2 en lugar de usar links para trabajar en varios archivos de redacción ).

docker-compose up -d
docker-compose -f test-runner.yml run test-runner
rc=$?
docker-compose down
exit $rc

Ningún corredor de prueba op

Por defecto, el test-runner a un punto de entrada / comando no op y luego ejecute manualmente el comando de prueba

services:
test-runner:
image: "${RUNNER_IMG}"
command: ''true''

Entonces

docker-compose up -d
docker-compose run test-runner /launch-tests.sh
rc=$?
docker-compose down
exit $rc

Códigos de retorno

Si su CI tiene el concepto de "publicar tareas", es posible que pueda omitir la captura de rc y simplemente ejecutar la docker-compose down después de que la tarea de prueba del corredor de prueba haya finalizado. También es posible que su IC limpie los contenedores por usted.

Answer 5

Para evitar tener archivos de configuración separados , puede actualizar la configuración de la depends_on acoplable para introducir las dependencias entre los servicios con la opción depends_on , disponible desde el formato de la versión 2 en adelante. Como resultado, el inicio del test-runner iniciará la ejecución de los clientes.

Tenga en cuenta que si necesita esperar un momento en que el servidor web real se inicie desde los servicios que está probando, puede usar el script wait-for-it.sh para esperar hasta que el servidor esté disponible.

# 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}"

Después de actualizar la configuración, el sencillo docker-compose up test-runner activará el inicio de los servicios relacionados.