GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Cet article intĂ©ressera tant les testeurs que les dĂ©veloppeurs, mais il est principalement destinĂ© aux automatisateurs qui ont rencontrĂ© le problĂšme de configuration de GitLab CI/CD pour rĂ©aliser des tests d'intĂ©gration dans des environnements avec des ressources d'infrastructure insuffisantes et/ou en l'absence d'une plateforme d'orchestration de conteneurs. Je vais expliquer comment configurer le dĂ©ploiement des environnements de test Ă  l'aide de docker compose sur un seul runner GitLab shell, de maniĂšre Ă  ce que les services lancĂ©s lors du dĂ©ploiement de plusieurs environnements ne se gĂȘnent pas mutuellement.


Contenu

Prérequis

  1. Dans ma pratique, il m'est souvent arrivĂ© de "rĂ©parer" les tests d'intĂ©gration sur les projets. Et souvent, le premier et le plus important problĂšme est le pipeline CI dans lequel les tests d'intĂ©gration du service(s) en cours de dĂ©veloppement est effectuĂ© dans un environnement dev/stage. Cela a causĂ© de nombreux problĂšmes : En raison de dĂ©fauts dans un service ou un autre, le circuit de test peut ĂȘtre corrompu par des donnĂ©es erronĂ©es lors des tests d'intĂ©gration. Il y a eu des cas oĂč l'envoi d'une requĂȘte avec un format JSON erronĂ© faisait planter le service, rendant l'ensemble du stand totalement non fonctionnel.

    • Un ralentissement du circuit de test avec l'augmentation des donnĂ©es de test. Je pense qu'il n'est pas nĂ©cessaire de dĂ©crire un exemple avec le nettoyage/reversement de la base de donnĂ©es. Dans ma pratique, je n'ai pas rencontrĂ© de projet oĂč cette procĂ©dure se dĂ©roulait sans accroc.
    • Le risque de compromettre le bon fonctionnement du circuit de test lors de l'Ă©valuation des configurations communes du systĂšme. Par exemple, user/group/password/application policy.
    • Les donnĂ©es de test des tests automatisĂ©s gĂȘnent les testeurs manuels.
    • Certains diront que de bons tests automatisĂ©s devraient nettoyer les donnĂ©es aprĂšs leur exĂ©cution. J'ai des arguments contre cela :

    Les environnements dynamiques sont trĂšs pratiques Ă  utiliser.

    • Tous les objets ne peuvent pas ĂȘtre supprimĂ©s du systĂšme via l'API. Par exemple, l'appel pour supprimer un objet n'est pas implĂ©mentĂ©, car il contredirait la logique mĂ©tier.
    • Lors de la crĂ©ation d'un objet via l'API, un grand nombre de mĂ©tadonnĂ©es peuvent ĂȘtre gĂ©nĂ©rĂ©es, ce qui est problĂ©matique Ă  supprimer.
    • Si les tests ont des dĂ©pendances entre eux, le processus de nettoyage des donnĂ©es aprĂšs l'exĂ©cution des tests devient un vĂ©ritable casse-tĂȘte.
    • Des appels supplĂ©mentaires (et, Ă  mon avis, injustifiĂ©s) Ă  l'API.
    • Des appels supplĂ©mentaires (qui, Ă  mon avis, ne sont pas justifiĂ©s) Ă  l'API.
    • Et le principal argument : lorsque les donnĂ©es de test commencent Ă  ĂȘtre nettoyĂ©es directement Ă  partir de la base de donnĂ©es. Cela se transforme en un vĂ©ritable cirque PK/FK ! Les dĂ©veloppeurs disent : « J'ai juste ajoutĂ©/supprimĂ©/renommĂ© une table, pourquoi 100500 tests d'intĂ©gration Ă©chouent-ils ? »

    À mon avis, la solution la plus optimale est un environnement dynamique.

  2. Beaucoup utilisent docker-compose pour lancer un environnement de test, mais peu l'utilisent lors des tests d'intégration dans CI/CD. Et ici, je ne prends pas en compte Kubernetes, Swarm et d'autres plateformes d'orchestration de conteneurs. Elles ne sont pas présentes dans toutes les entreprises. Ce serait bien que le fichier docker-compose.yml soit universel.
  3. MĂȘme si nous avons notre propre runner QA, comment pouvons-nous faire en sorte que les services lancĂ©s via docker-compose ne se gĂȘnent pas ?
  4. Comment collecter les logs des services testés ?
  5. Comment nettoyer le runner ?

J'ai mon propre GitLab runner pour mes projets et j'ai rencontré ces questions lors du développement. Client Java pour TestRail. Plus précisément lors de l'exécution des tests d'intégration. C'est là que nous allons résoudre ces questions avec des exemples de ce projet.

Au contenu

GitLab Shell Runner

Pour le runner, je recommande une machine virtuelle Linux avec 4 vCPU, 4 Go de RAM, 50 Go de disque dur.
Il y a beaucoup d'informations sur Internet concernant la configuration de gitlab-runner, donc en bref :

  • Connectez-vous Ă  la machine via SSH
  • Si vous avez moins de 8 Go de RAM, je recommande de crĂ©er un swap de 10 Go, pour ne pas avoir de OOM killer qui tue nos tĂąches Ă  cause d'un manque de RAM. Cela peut arriver lorsque plus de 5 tĂąches sont lancĂ©es simultanĂ©ment. Les tĂąches prendront plus de temps, mais fonctionneront de maniĂšre stable.

    Exemple avec OOM killer

    Si dans les logs de la tùche vous voyez bash: line 82: 26474 Killed, exécutez simplement sur le runner sudo dmesg | grep 26474

    [26474]  1002 26474  1061935   123806     339        0             0 java
    Out of memory: Kill process 26474 (java) score 127 or sacrifice child
    Killed process 26474 (java) total-vm:4247740kB, anon-rss:495224kB, file-rss:0kB, shmem-rss:0kB

    Et si l'image ressemble Ă  cela, alors soit ajoutez du swap, soit augmentez la RAM.

  • Nous installons gitlab-runner, docker, docker-compose, make.
  • Ajoutons l'utilisateur gitlab-runner au groupe docker
    sudo groupadd docker
    sudo usermod -aG docker gitlab-runner
  • Enregistrement gitlab-runner.
  • Ouvrons pour Ă©dition /etc/gitlab-runner/config.toml et ajoutons

    concurrent=20
    [[runners]]
      request_concurrency = 10

    Cela permettra d'exécuter des tùches parallÚles sur un seul runner. Lire plus en détail ici.
    Si vous avez une machine plus puissante, par exemple 8 vCPU, 16 Go de RAM, ces chiffres peuvent ĂȘtre multipliĂ©s par au moins 2. Tout dĂ©pend de ce qui sera exĂ©cutĂ© prĂ©cisĂ©ment sur ce runner et en quelle quantitĂ©.

C'est suffisant.

Au contenu

Préparation de docker-compose.yml

La tùche principale est de créer un fichier docker-compose.yml universel que les développeurs/testeurs peuvent utiliser à la fois localement et dans le pipeline CI.

Tout d'abord, nous donnons des noms uniques aux services pour CI. L'une des variables uniques dans GitLab CI est la variable CI_JOB_ID. Si vous indiquez container_name avec la valeur "service-${CI_JOB_ID:-local}", alors dans le cas oĂč :

  • si CI_JOB_ID n'est pas dĂ©finie dans les variables d'environnement,
    le nom du service sera service-local
  • si CI_JOB_ID dĂ©finie dans les variables d'environnement (par exemple 123),
    le nom du service sera service-123

DeuxiÚmement, nous créons un réseau commun pour les services exécutés. Cela nous donne une isolation au niveau du réseau lors de l'exécution de plusieurs environnements de test.

networks:
  default:
    external:
      name: service-network-${CI_JOB_ID:-local}

C'est en fait le premier pas vers le succĂšs =)

Exemple de mon docker-compose.yml avec des commentaires

version: "3"

# Pour le bon fonctionnement de web (php) et fmt, il faut que les conteneurs aient un contenu exécutable commun.
# Dans notre cas, c'est le répertoire /var/www/testrail
volumes:
  static-content:

# Isoler l'environnement au niveau du réseau
networks:
  default:
    external:
      name: testrail-network-${CI_JOB_ID:-local}

services:
  db:
    image: mysql:5.7.22
    # Chaque container_name contient ${CI_JOB_ID:-local}
    container_name: "testrail-mysql-${CI_JOB_ID:-local}"
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: mydb
      MYSQL_ROOT_PASSWORD: 1234
      SKIP_GRANT_TABLES: 1
      SKIP_NETWORKING: 1
      SERVICE_TAGS: dev
      SERVICE_NAME: mysql
    networks:
    - default

  migration:
    image: registry.gitlab.com/touchbit/image/testrail/migration:latest
    container_name: "testrail-migration-${CI_JOB_ID:-local}"
    links:
    - db
    depends_on:
    - db
    networks:
    - default

  fpm:
    image: registry.gitlab.com/touchbit/image/testrail/fpm:latest
    container_name: "testrail-fpm-${CI_JOB_ID:-local}"
    volumes:
    - static-content:/var/www/testrail
    links:
    - db
    networks:
    - default

  web:
    image: registry.gitlab.com/touchbit/image/testrail/web:latest
    container_name: "testrail-web-${CI_JOB_ID:-local}"
    # Si les variables TR_HTTP_PORT ou TR_HTTPS_PORT ne sont pas définies,
    # alors le service se lĂšve sur le port 80 et 443 respectivement.
    ports:
      - ${TR_HTTP_PORT:-80}:80
      - ${TR_HTTPS_PORT:-443}:443
    volumes:
      - static-content:/var/www/testrail
    links:
      - db
      - fpm
    networks:
      - default

Exemple de lancement local

docker-compose -f docker-compose.yml up -d
Démarrage   testrail-mysql-local     ... fait
Démarrage   testrail-migration-local ... fait
Démarrage   testrail-fpm-local       ... fait
Recréer testrail-web-local       ... fait

Mais tout n'est pas si simple avec le lancement en CI.

Au contenu

Préparation de Makefile

J'utilise Makefile car c'est trĂšs pratique pour la gestion locale de l'environnement ainsi qu'en CI. Ensuite, les commentaires en ligne

# ĐŁ ĐŒĐ”ĐœŃ ĐČ ĐżŃ€ĐŸĐ”Đșтах ĐČсД ĐČŃĐżĐŸĐŒĐŸĐłĐ°Ń‚Đ”Đ»ŃŒĐœŃ‹Đ” ĐČДщО лДжат ĐČ ĐŽĐžŃ€Đ”ĐșŃ‚ĐŸŃ€ĐžĐž `.indirect`,
# ĐČ Ń‚ĐŸĐŒ чОслД Đž `docker-compose.yml`

# Đ˜ŃĐżĐŸĐ»ŃŒĐ·ĐŸĐČать bash с ĐŸĐżŃ†ĐžĐ”Đč pipefail 
# pipefail - фДĐčлОт ĐČŃ‹ĐżĐŸĐ»ĐœĐ”ĐœĐžĐ” паĐčпа, ДслО ĐșĐŸĐŒĐ°ĐœĐŽĐ° ĐČŃ‹ĐżĐŸĐ»ĐœĐžĐ»Đ°ŃŃŒ с ĐŸŃˆĐžĐ±ĐșĐŸĐč
SHELL=/bin/bash -o pipefail

# ĐžŃŃ‚Đ°ĐœĐ°ĐČлОĐČĐ°Đ”ĐŒ ĐșĐŸĐœŃ‚Đ”ĐčĐœĐ”Ń€Ń‹ Đž ŃƒĐŽĐ°Đ»ŃĐ”ĐŒ ŃĐ”Ń‚ŃŒ
docker-kill:
    docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml kill
    docker network rm network-$${CI_JOB_ID:-testrail} || true

# ĐŸŃ€Đ”ĐŽĐČĐ°Ń€ĐžŃ‚Đ”Đ»ŃŒĐœĐŸ ĐČŃ‹ĐżĐŸĐ»ĐœŃĐ”ĐŒ docker-kill 
docker-up: docker-kill
    # ĐĄĐŸĐ·ĐŽĐ°Đ”ĐŒ ŃĐ”Ń‚ŃŒ ĐŽĐ»Ń ĐŸĐșŃ€ŃƒĐ¶Đ”ĐœĐžŃ 
    docker network create network-$${CI_JOB_ID:-testrail}
    # Đ—Đ°Đ±ĐžŃ€Đ°Đ”ĐŒ ĐżĐŸŃĐ»Đ”ĐŽĐœĐžĐ” ĐŸĐ±Ń€Đ°Đ·Ń‹ Оз docker-registry
    docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml pull
    # ЗапусĐșĐ°Đ”ĐŒ ĐŸĐșŃ€ŃƒĐ¶Đ”ĐœĐžĐ”
    # force-recreate - ĐżŃ€ĐžĐœŃƒĐŽĐžŃ‚Đ”Đ»ŃŒĐœĐŸĐ” ĐżĐ”Ń€Đ”ŃĐŸĐ·ĐŽĐ°ĐœĐžĐ” ĐșĐŸĐœŃ‚Đ”ĐčĐœĐ”Ń€ĐŸĐČ
    # renew-anon-volumes - ĐœĐ” ĐžŃĐżĐŸĐ»ŃŒĐ·ĐŸĐČать volumes ĐżŃ€Đ”ĐŽŃ‹ĐŽŃƒŃ‰ĐžŃ… ĐșĐŸĐœŃ‚Đ”ĐčĐœĐ”Ń€ĐŸĐČ
    docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
    # Ну Đž, ĐœĐ° ĐČсяĐșĐžĐč ŃĐ»ŃƒŃ‡Đ°Đč, ĐČыĐČДстО Ń‡Ń‚ĐŸ Ń‚Đ°ĐŒ у ĐœĐ°Ń ĐČ ĐżŃ€ĐžĐœŃ†ĐžĐżĐ” Đ·Đ°ĐżŃƒŃ‰Đ”ĐœĐŸ ĐœĐ° ĐŒĐ°ŃˆĐžĐœĐșĐ”
    docker ps

# ĐšĐŸĐ»Đ»Đ”ĐșŃ‚ĐžĐŒ Đ»ĐŸĐłĐž сДрĐČĐžŃĐŸĐČ
docker-logs:
    mkdir ./logs || true
    docker logs testrail-web-$${CI_JOB_ID:-local}       >& logs/testrail-web.log
    docker logs testrail-fpm-$${CI_JOB_ID:-local}       >& logs/testrail-fpm.log
    docker logs testrail-migration-$${CI_JOB_ID:-local} >& logs/testrail-migration.log
    docker logs testrail-mysql-$${CI_JOB_ID:-local}     >& logs/testrail-mysql.log

# ОчостĐșа Ń€Đ°ĐœĐœĐ”Ń€Đ°
docker-clean:
    @echo ĐžŃŃ‚Đ°ĐœĐ°ĐČлОĐČĐ°Đ”ĐŒ ĐČсД testrail-ĐșĐŸĐœŃ‚Đ”ĐčĐœĐ”Ń€Ń‹
    docker kill $$(docker ps --filter=name=testrail -q) || true
    @echo ОчостĐșа ĐŽĐŸĐșДр ĐșĐŸĐœŃ‚Đ”ĐčĐœĐ”Ń€ĐŸĐČ
    docker rm -f $$(docker ps -a -f --filter=name=testrail status=exited -q) || true
    @echo ОчостĐșа dangling ĐŸĐ±Ń€Đ°Đ·ĐŸĐČ
    docker rmi -f $$(docker images -f "dangling=true" -q) || true
    @echo ОчостĐșа testrail ĐŸĐ±Ń€Đ°Đ·ĐŸĐČ
    docker rmi -f $$(docker images --filter=reference='registry.gitlab.com/touchbit/image/testrail/*' -q) || true
    @echo ОчостĐșа ĐČсДх ĐœĐ”ĐžŃĐżĐŸĐ»ŃŒĐ·ŃƒĐ”ĐŒŃ‹Ń… volume
    docker volume rm -f $$(docker volume ls -q) || true
    @echo ОчостĐșа ĐČсДх testrail сДтДĐč
    docker network rm $(docker network ls --filter=name=testrail -q) || true
    docker ps

Vérification

make docker-up

$ make docker-up 
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml kill
Killing testrail-web-local   ... done
Killing testrail-fpm-local   ... done
Killing testrail-mysql-local ... done
docker network rm network-${CI_JOB_ID:-testrail} || true
network-testrail
docker network create network-${CI_JOB_ID:-testrail}
d2ec063324081c8bbc1b08fd92242c2ea59d70cf4025fab8efcbc5c6360f083f
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml pull
Pulling db        ... done
Pulling migration ... done
Pulling fpm       ... done
Pulling web       ... done
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Recreating testrail-mysql-local ... done
Recreating testrail-fpm-local       ... done
Recreating testrail-migration-local ... done
Recreating testrail-web-local       ... done
docker ps
CONTAINER ID  PORTS                                     NAMES
a845d3cb0e5a  0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp  testrail-web-local
19d8ef001398  9000/tcp                                  testrail-fpm-local
e28840a2369c  3306/tcp, 33060/tcp                       testrail-migration-local
0e7900c23f37  3306/tcp                                  testrail-mysql-local

make docker-logs

$ make docker-logs
mkdir .\/logs || true
mkdir: cannot create directory ‘.\/logs’: File exists
docker logs testrail-web-${CI_JOB_ID:-local}       >& logs\/testrail-web.log
docker logs testrail-fpm-${CI_JOB_ID:-local}       >& logs\/testrail-fpm.log
docker logs testrail-migration-${CI_JOB_ID:-local} >& logs\/testrail-migration.log
docker logs testrail-mysql-${CI_JOB_ID:-local}     >& logs\/testrail-mysql.log

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Au contenu

Préparation de .gitlab-ci.yml

Lancement des tests d'intégration

Intégration:
  étape: test
  tags:
    - my-shell-runner
  before_script:
    # Authentification dans le registre
    - docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
    # Génération des ports TR_HTTP_PORT et TR_HTTPS_PORT pseudo-uniques
    - export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
    - export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
    # Création d'un répertoire avec l'identifiant de la tùche
    - mkdir ${CI_JOB_ID}
    # Copie de notre docker-compose.yml dans le répertoire créé
    # afin que le contexte soit différent pour chaque tùche
    - cp .indirect\/docker-compose.yml ${CI_JOB_ID}\/docker-compose.yml
  script:
    # Mise en place de notre environnement
    - make docker-up
    # Exécution des tests avec jar exécutable (c'est comme cela que je fonctionne)
    - java -jar itest.jar --http-port ${TR_HTTP_PORT} --https-port ${TR_HTTPS_PORT}
    # ou dans le conteneur
    - docker run --network=testrail-network-${CI_JOB_ID:-local} --rm itest
  after_script:
    # Récupération des logs
    - make docker-logs
    # ArrĂȘt de l'environnement
    - make docker-kill
  artifacts:
    # Sauvegarde des logs
    when: always
    paths:
      - logs
    expire_in: 30 days

En conséquence de l'exécution d'une telle tùche, le répertoire logs des artefacts contiendra les logs des services et des tests. Ce qui est trÚs pratique en cas d'erreurs. Chaque test en parallÚle écrit son propre log, mais j'en parlerai séparément.

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Au contenu

Nettoyage du runner

La tùche ne sera exécutée que selon un calendrier.

stages:
- clean
- build
- test

Nettoyage:
  étape: clean
  only:
    - schedules
  tags:
    - my-shell-runner
  script:
    - make docker-clean

Ensuite, allons dans notre projet GitLab -> CI/CD -> Schedules -> New Schedule et ajoutons un nouvel emploi du temps

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Au contenu

Résultat

Nous lançons 4 tùches dans GitLab CI
GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Dans les journaux de la derniÚre tùche avec les tests d'intégration, nous voyons des conteneurs de différentes tùches

IDENTIFIANT DU CONTENEUR  NOMS
c6b76f9135ed  testrail-web-204645172
01d303262d8e  testrail-fpm-204645172
2cdab1edbf6a  testrail-migration-204645172
826aaf7c0a29  testrail-mysql-204645172
6dbb3fae0322  testrail-web-204645084
3540f8d448ce  testrail-fpm-204645084
70fea72aa10d  testrail-mysql-204645084
d8aa24b2892d  testrail-web-204644881
6d4ccd910fad  testrail-fpm-204644881
685d8023a3ec  testrail-mysql-204644881
1cdfc692003a  testrail-web-204644793
6f26dfb2683e  testrail-fpm-204644793
029e16b26201  testrail-mysql-204644793
c10443222ac6  testrail-web-204567103
04339229397e  testrail-fpm-204567103
6ae0accab28d  testrail-mysql-204567103
b66b60d79e43  testrail-web-204553690
033b1f46afa9  testrail-fpm-204553690
a8879c5ef941  testrail-mysql-204553690
069954ba6010  testrail-web-204553539
ed6b17d911a5  testrail-fpm-204553539
1a1eed057ea0  testrail-mysql-204553539

Journal plus détaillé

$ docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
AVERTISSEMENT ! Utiliser --password via la CLI n'est pas sécurisé. Utilisez --password-stdin.
AVERTISSEMENT ! Votre mot de passe sera stocké en texte clair dans /home/gitlab-runner/.docker/config.json.
Configurez un assistant d'identification pour supprimer cet avertissement. Voir
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Connexion réussie
$ export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
$ export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
$ mkdir ${CI_JOB_ID}
$ cp .indirect/docker-compose.yml ${CI_JOB_ID}/docker-compose.yml
$ make docker-up
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml kill
docker network rm testrail-network-${CI_JOB_ID:-local} || true
Erreur : Pas de tel réseau : testrail-network-204645172
docker network create testrail-network-${CI_JOB_ID:-local}
0a59552b4464b8ab484de6ae5054f3d5752902910bacb0a7b5eca698766d0331
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml pull
Tirage de web       ... fait
Tirage de fpm       ... fait
Tirage de migration ... fait
Tirage de db        ... fait
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Création du volume "204645172_static-content" avec le pilote par défaut
Création de testrail-mysql-204645172 ... 
Création de testrail-mysql-204645172 ... terminé
Création de testrail-migration-204645172 ... terminé
Création de testrail-fpm-204645172       ... terminé
Création de testrail-web-204645172       ... terminé
docker ps
ID CONTENEUR        IMAGE                                                          COMMANDE                  CRÉÉ              ÉTAT              PORTS                                           NOMS
c6b76f9135ed        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a 13 secondes       En ligne 1 seconde         0.0.0.0:51148->80/tcp, 0.0.0.0:25426->443/tcp   testrail-web-204645172
01d303262d8e        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a 16 secondes       En ligne 13 secondes       9000/tcp                                        testrail-fpm-204645172
2cdab1edbf6a        registry.gitlab.com/touchbit/image/testrail/migration:latest   "docker-entrypoint.s
"   Il y a 16 secondes       En ligne 13 secondes       3306/tcp, 33060/tcp                             testrail-migration-204645172
826aaf7c0a29        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a 18 secondes       En ligne 16 secondes       3306/tcp                                        testrail-mysql-204645172
6dbb3fae0322        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a 36 secondes       En ligne 22 secondes       0.0.0.0:44202->80/tcp, 0.0.0.0:20151->443/tcp   testrail-web-204645084
3540f8d448ce        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a 38 secondes       En ligne 35 secondes       9000/tcp                                        testrail-fpm-204645084
70fea72aa10d        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a 40 secondes       En ligne 37 secondes       3306/tcp                                        testrail-mysql-204645084
d8aa24b2892d        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a environ une minute   En ligne 53 secondes       0.0.0.0:31103->80/tcp, 0.0.0.0:43872->443/tcp   testrail-web-204644881
6d4ccd910fad        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a environ une minute   En ligne environ une minute   9000/tcp                                        testrail-fpm-204644881
685d8023a3ec        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a environ une minute   En ligne environ une minute   3306/tcp                                        testrail-mysql-204644881
1cdfc692003a        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a environ une minute   En ligne environ une minute   0.0.0.0:44752->80/tcp, 0.0.0.0:23540->443/tcp   testrail-web-204644793
6f26dfb2683e        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a environ une minute   En ligne environ une minute   9000/tcp                                        testrail-fpm-204644793
029e16b26201        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a environ une minute   En ligne environ une minute   3306/tcp                                        testrail-mysql-204644793
c10443222ac6        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a 5 heures          En ligne 5 heures          0.0.0.0:57123->80/tcp, 0.0.0.0:31657->443/tcp   testrail-web-204567103
04339229397e        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a 5 heures          En ligne 5 heures          9000/tcp                                        testrail-fpm-204567103
6ae0accab28d        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a 5 heures          En ligne 5 heures          3306/tcp                                        testrail-mysql-204567103
b66b60d79e43        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a 5 heures          En ligne 5 heures          0.0.0.0:56321->80/tcp, 0.0.0.0:58749->443/tcp   testrail-web-204553690
033b1f46afa9        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a 5 heures          En ligne 5 heures          9000/tcp                                        testrail-fpm-204553690
a8879c5ef941        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a 5 heures          En ligne 5 heures          3306/tcp                                        testrail-mysql-204553690
069954ba6010        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon de
"   Il y a 5 heures          En ligne 5 heures          0.0.0.0:32869->80/tcp, 0.0.0.0:16066->443/tcp   testrail-web-204553539
ed6b17d911a5        registry.gitlab.com/touchbit/image/testrail/fpm:latest         "docker-php-entrypoi
"   Il y a 5 heures          En ligne 5 heures          9000/tcp                                        testrail-fpm-204553539
1a1eed057ea0        mysql:5.7.22                                                   "docker-entrypoint.s
"   Il y a 5 heures          En ligne 5 heures          3306/tcp                                        testrail-mysql-204553539

Toutes les tùches ont été terminées avec succÚs

Les artefacts de la tĂąche contiennent les journaux des services et des tests
GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Tout semble en ordre, mais il y a un dĂ©tail. Le pipeline peut ĂȘtre annulĂ© de force pendant l'exĂ©cution des tests d'intĂ©gration, et dans ce cas, les conteneurs lancĂ©s ne seront pas arrĂȘtĂ©s. Il est parfois nĂ©cessaire de nettoyer le runner. Malheureusement, la tĂąche de mise Ă  jour dans GitLab CE est toujours en statut. Ouvrir

Mais nous avons ajouté l'exécution de la tùche selon un calendrier, et personne ne nous interdit de la lancer manuellement.
Passons à notre projet -> CI/CD -> Schedules et lançons la tùche Nettoyer le runner

GitLab Shell Runner. Exécution concurrente des services testés à l'aide de Docker Compose

Total :

  • Nous avons un runner shell.
  • Il n'y a pas de conflits entre les tĂąches et l'environnement.
  • Nous avons un lancement parallĂšle de tĂąches avec les tests d'intĂ©gration.
  • Les tests d'intĂ©gration peuvent ĂȘtre lancĂ©s Ă  la fois localement et dans un conteneur.
  • Les journaux des services et des tests sont collectĂ©s et attachĂ©s Ă  la tĂąche du pipeline.
  • Il est possible de nettoyer le runner des anciennes images docker.

Le temps de configuration — ~2 heures.
VoilĂ , c'est Ă  peu prĂšs tout. Je serais ravi d'avoir vos retours.

Au contenu

Source : habr.com

Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS đŸ”„ Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster