web-dev-qa-db-fra.com

Arrêter la composition du docker à la fin du conteneur de test

J'exécute actuellement une pile docker-compose pour les tests d'intégration de base avec un lanceur de test rapporteur, un serveur nodejs servant une page Web et un serveur wildfly desservant un Java backend.

La pile est exécutée à partir d'un conteneur dind (docker in docker) dans mon serveur de build (concourse ci).

Mais il semble que les conteneurs ne se terminent pas à la fin des tests du rapporteur.

Donc, puisque les conteneurs pour wildfly et nodejs sont toujours en cours d'exécution, la tâche de génération ne se termine jamais ...

Comment puis-je faire en sorte que la composition se termine avec succès ou échec lorsque les tests sont terminés?

# 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}"
dockerdocker-composeconcourse
25
David Karlsson

Similaire à cela rspec q/a , vous devez exécuter les tests en tant que tâche autonome qui rapporte un état de sortie à votre CI.

Vous pouvez séparer le testeur en son propre yaml ou modifier le testeur par défaut en une commande/point d'entrée sans op.

Séparez le testeur

Spécifie le test-runner config séparément (vous devrez peut-être mettre à niveau vers version 2 networks au lieu d'utiliser links pour travailler sur plusieurs fichiers de composition).

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

Aucun testeur opérationnel

Par défaut, le test-runner vers un point d'entrée/commande no op, puis exécutez manuellement la commande de test

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

Alors

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

Codes retour

Si votre CI a le concept de "tâches postérieures", vous pourrez peut-être ignorer la capture de rc et simplement exécuter le docker-compose down une fois la tâche CI du testeur terminée. Il est également possible que votre CI nettoie les conteneurs pour vous.

16
Matt

Vous pouvez utiliser ces paramètres de composition de docker pour y parvenir:

--abort-on-container-exit Arrête tous les conteneurs si un conteneur a été arrêté.

--exit-code-from Renvoie le code de sortie du conteneur de services sélectionné.

Par exemple, avoir ce docker-compose.yml:

version: '2.3'

services:
  elasticsearch:
    ...
  service-api:
    ...
  service-test:
    ...
    depends_on:
      - elasticsearch
      - service-api

La commande suivante garantit que elasticsearch et service-api descendre après service-test est terminé et renvoie le code de sortie de service-test récipient:

docker-compose -f docker-compose.yml up \
    --abort-on-container-exit \
    --exit-code-from service-test
50
Michael Spector

La solution que j'ai trouvée la plus élégante consiste à utiliser depends_on dans ton docker-compose.yml fichier.

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

Vous pouvez maintenant utiliser docker-compose run --rm test_runner qui configurera vos dépendances, exécutera vos tests, détruira tout et propagera le code retour.

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

J'ai essayé la solution proposée dans cette discussion mais problème toujours dans le cas

Cas-1: docker-compose up -d

Vous pouvez utiliser docker-compose up -d, testez-le par un test-runner puis terminer par docker-compose down mais le problème lorsque vous utilisez docker-compose up -d est que vous ne verrez plus les journaux de la sortie standard.

Cas-2: docker-compose up --exit-code-from a service

Vous pouvez afficher les journaux de docker si vous utilisez --exit-code-from <service> cela implique --abort-on-container-exit mais le service n'enverra pas de commande de sortie en cas de réussite. Ensuite vous devez attraper votre conteneur est terminé testé avant d'envoyer docker-compose down pour les arrêter.

L'une des solutions pour voir les journaux avant de les terminer est d'utiliser --tail=1000 -f

docker-compose up -d
docker-compose logs --tail=1000 -f test-runner
docker-compose down
exit $rc

Il existe également une solution utilisant Nohup mais vous devez attendre la fin du processus, puis ouvrir le fichier journal de sortie, ce qui devrait être plus facile

0
Chetabahana

Pour éviter d'avoir des fichiers de configuration séparés , vous pouvez mettre à jour la configuration docker-compose pour introduire les dépendances entre les services avec l'option depend_on , disponible à partir du format version 2 et plus. En conséquence, le début du test-runner lancera l'exécution des clients.

Veuillez noter que si vous devez attendre un certain temps lorsque le serveur Web réel sera démarré à partir des services internes que vous testez, vous pouvez utiliser le script wait-for-it.sh pour attendre que le serveur soit 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}"

Après la mise à jour de la configuration, simple docker-compose up test-runner déclenchera le démarrage des services associés.

0
Andriy Ivaneyko