Cet article intéressera aussi bien les testeurs que les développeurs, mais s'adresse davantage aux automates confrontés à la problématique de la mise en place de GitLab CI/CD pour les tests d'intégration face à des ressources d'infrastructure insuffisantes et/ou à l'absence d'orchestration de conteneurs. plate-forme. Je vais vous expliquer comment configurer le déploiement des environnements de test à l'aide de docker compose sur un seul exécuteur de shell GitLab et pour que lors du déploiement de plusieurs environnements, les services lancés n'interfèrent pas les uns avec les autres.
Teneur
Предпосылки
-
Dans ma pratique, il m'arrivait souvent de « traiter » des tests d'intégration sur des projets. Et souvent, le premier et le plus important problème est le pipeline CI, dans lequel les tests d'intégration développé le ou les services sont hébergés dans l'environnement dev/stage. Cela a posé pas mal de problèmes :
- En raison de défauts dans l'un ou l'autre service lors des tests d'intégration, le circuit de test peut être corrompu par des données cassées. Il y a eu des cas où l'envoi d'une demande avec un format JSON cassé a raccroché le service, ce qui a rendu le stand complètement inopérant.
- Le ralentissement du circuit de test avec la croissance des données de test. Je pense que cela n'a aucun sens de décrire un exemple de nettoyage/restauration de la base de données. Dans ma pratique, je n'ai pas rencontré de projet où cette procédure se déroulerait sans problème.
- Le risque de perturber les performances du circuit de test lors du test des paramètres généraux du système. Par exemple, stratégie utilisateur/groupe/mot de passe/application.
- Les données de test des autotests rendent la vie difficile aux testeurs manuels.
Quelqu'un dira que de bons autotests devraient nettoyer les données après eux. J'ai des arguments contre :
- Les supports dynamiques sont très pratiques à utiliser.
- Tous les objets ne peuvent pas être supprimés du système via l'API. Par exemple, un appel pour supprimer un objet n'est pas implémenté car il contredit la logique métier.
- Lors de la création d'un objet via l'API, une énorme quantité de métadonnées peut être créée et il est difficile de les supprimer.
- Si les tests dépendent les uns des autres, le processus de nettoyage des données après l'exécution des tests se transforme en un véritable casse-tête.
- Appels supplémentaires (et, à mon avis, non justifiés) à l'API.
- Et l'argument principal : quand les données de test commencent à être nettoyées directement de la base de données. Cela devient un véritable cirque PK/FK ! Les développeurs nous disent : « Je viens d'ajouter/supprimer/renommer le panneau, pourquoi 100500 XNUMX tests d'intégration ont-ils échoué ? »
À mon avis, la solution la plus optimale est un environnement dynamique.
- De nombreuses personnes utilisent docker-compose pour exécuter un environnement de test, mais peu de personnes utilisent docker-compose pour effectuer des tests d'intégration dans CI/CD. Et ici je ne prends pas en compte les kubernetes, swarm et autres plateformes d'orchestration de conteneurs. Toutes les entreprises n’en disposent pas. Ce serait bien si docker-compose.yml était universel.
- Même si nous avons notre propre programme d'assurance qualité, comment pouvons-nous nous assurer que les services lancés via docker-compose n'interfèrent pas les uns avec les autres ?
- Comment collecter les logs des services testés ?
- Comment nettoyer le tapis ?
J'ai mon propre runner GitLab pour mes projets et j'ai rencontré ces problèmes lors du développement pour . Plus précisément, lors de l’exécution de tests d’intégration. Ici, nous continuerons à résoudre ces problèmes avec des exemples de ce projet.
Coureur de shell GitLab
Pour un coureur, je recommande une machine virtuelle Linux avec 4 vCPU, 4 Go de RAM, 50 Go de disque dur.
Il existe de nombreuses informations sur la configuration de gitlab-runner sur Internet, donc en bref :
- On va à la machine via SSH
-
Si vous disposez de moins de 8 Go de RAM, alors je vous recommande pour que le tueur OOM ne vienne pas nous tuer des tâches par manque de RAM. Cela peut se produire lorsque plus de 5 tâches sont exécutées en même temps. Les tâches seront plus lentes, mais stables.
Exemple avec OOM killer
Si dans les journaux de tâches vous voyez
bash: line 82: 26474 Killed, puis exécutez simplement sur le coureursudo 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:0kBEt si l'image ressemble à ceci, ajoutez du swap ou ajoutez de la RAM.
- Fixer , , , Fabriquer.
- Ajouter un utilisateur
gitlab-runnerau groupedockersudo groupadd docker sudo usermod -aG docker gitlab-runner - gitlab-runner.
-
Ouvrir pour modification
/etc/gitlab-runner/config.tomlet ajouterconcurrent=20 [[runners]] request_concurrency = 10Cela vous permettra d'exécuter des tâches parallèles sur le même coureur. En savoir plus .
Si vous disposez d'une machine plus puissante, par exemple 8 vCPU, 16 Go de RAM, ces chiffres peuvent être au moins 2 fois plus grands. Mais tout dépend de ce qui sera exactement lancé sur ce coureur et en quelle quantité.
C'est assez.
Préparation de docker-compose.yml
La tâche principale est un docker-compose.yml universel que les développeurs/testeurs peuvent utiliser à la fois localement et dans le pipeline CI.
Tout d’abord, nous créons des noms de service uniques pour CI. L'une des variables uniques de GitLab CI est la variable CI_JOB_ID. Si vous précisez container_name avec un sens "service-${CI_JOB_ID:-local}", alors dans le cas :
- si
CI_JOB_IDnon défini dans les variables d'environnement,
alors le nom du service seraservice-local - si
CI_JOB_IDdéfini dans les variables d'environnement (par exemple 123),
alors le nom du service seraservice-123
Deuxièmement, nous créons un réseau commun pour exécuter les services. 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}En fait, c'est la première étape vers le succès =)
Un exemple de mon docker-compose.yml avec commentaires
version: "3"
# Для корректной работы web (php) и fmt нужно,
# чтобы контейнеры имели общий исполняемый контент.
# В нашем случае, это директория /var/www/testrail
volumes:
static-content:
# Изолируем окружение на сетевом уровне
networks:
default:
external:
name: testrail-network-${CI_JOB_ID:-local}
services:
db:
image: mysql:5.7.22
# Каждый container_name содержит ${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}"
# Если переменные TR_HTTP_PORT или TR_HTTPS_PORTS не определены,
# то сервис поднимается на 80 и 443 порту соответственно.
ports:
- ${TR_HTTP_PORT:-80}:80
- ${TR_HTTPS_PORT:-443}:443
volumes:
- static-content:/var/www/testrail
links:
- db
- fpm
networks:
- defaultExemple d'exécution locale
docker-compose -f docker-compose.yml up -d
Starting testrail-mysql-local ... done
Starting testrail-migration-local ... done
Starting testrail-fpm-local ... done
Recreating testrail-web-local ... doneMais tout n'est pas si simple avec le lancement en CI.
Préparation du Makefile
J'utilise le Makefile car il est très pratique à la fois pour la gestion de l'environnement local et pour le CI. Plus de 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
Chèque
faire un 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
créer des journaux Docker
$ 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
Préparation de .gitlab-ci.yml
Exécution de tests d'intégration
Integration:
stage: test
tags:
- my-shell-runner
before_script:
# Аутентифицируемся в registry
- docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
# Генерируем псевдоуникальные TR_HTTP_PORT и TR_HTTPS_PORT
- export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
- export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
# создаем директорию с идентификатором задачи
- mkdir ${CI_JOB_ID}
# копируем в созданную директорию наш docker-compose.yml
# чтобы контекст был разный для каждой задачи
- cp .indirect/docker-compose.yml ${CI_JOB_ID}/docker-compose.yml
script:
# поднимаем наше окружение
- make docker-up
# запускаем тесты исполняемым jar (у меня так)
- java -jar itest.jar --http-port ${TR_HTTP_PORT} --https-port ${TR_HTTPS_PORT}
# или в контейнере
- docker run --network=testrail-network-${CI_JOB_ID:-local} --rm itest
after_script:
# собираем логи
- make docker-logs
# останавливаем окружение
- make docker-kill
artifacts:
# сохраняем логи
when: always
paths:
- logs
expire_in: 30 daysSuite à l'exécution d'une telle tâche, le répertoire des journaux dans les artefacts contiendra les journaux des services et des tests. Ce qui est très pratique en cas d'erreurs. Chaque test écrit en parallèle son propre journal, mais j'en parlerai séparément.
Nettoyer le coureur
La tâche s'exécutera uniquement selon le calendrier.
stages:
- clean
- build
- test
Clean runner:
stage: clean
only:
- schedules
tags:
- my-shell-runner
script:
- make docker-cleanEnsuite, accédez à notre projet GitLab -> CI/CD -> Plannings -> New Schedule et ajoutez un nouveau planning
Résultat
Exécuter 4 tâches dans GitLab CI
Dans les logs de la dernière tâche avec tests d'intégration, nous voyons des conteneurs de différentes tâches
CONTAINER ID NAMES
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-204553539Journal plus détaillé
$ docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/gitlab-runner/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
$ 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
Error: No such network: testrail-network-204645172
docker network create testrail-network-${CI_JOB_ID:-local}
0a59552b4464b8ab484de6ae5054f3d5752902910bacb0a7b5eca698766d0331
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml pull
Pulling web ... done
Pulling fpm ... done
Pulling migration ... done
Pulling db ... done
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Creating volume "204645172_static-content" with default driver
Creating testrail-mysql-204645172 ...
Creating testrail-mysql-204645172 ... done
Creating testrail-migration-204645172 ... done
Creating testrail-fpm-204645172 ... done
Creating testrail-web-204645172 ... done
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c6b76f9135ed registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" 13 seconds ago Up 1 second 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…" 16 seconds ago Up 13 seconds 9000/tcp testrail-fpm-204645172
2cdab1edbf6a registry.gitlab.com/touchbit/image/testrail/migration:latest "docker-entrypoint.s…" 16 seconds ago Up 13 seconds 3306/tcp, 33060/tcp testrail-migration-204645172
826aaf7c0a29 mysql:5.7.22 "docker-entrypoint.s…" 18 seconds ago Up 16 seconds 3306/tcp testrail-mysql-204645172
6dbb3fae0322 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" 36 seconds ago Up 22 seconds 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…" 38 seconds ago Up 35 seconds 9000/tcp testrail-fpm-204645084
70fea72aa10d mysql:5.7.22 "docker-entrypoint.s…" 40 seconds ago Up 37 seconds 3306/tcp testrail-mysql-204645084
d8aa24b2892d registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" About a minute ago Up 53 seconds 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…" About a minute ago Up About a minute 9000/tcp testrail-fpm-204644881
685d8023a3ec mysql:5.7.22 "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp testrail-mysql-204644881
1cdfc692003a registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" About a minute ago Up About a 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…" About a minute ago Up About a minute 9000/tcp testrail-fpm-204644793
029e16b26201 mysql:5.7.22 "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp testrail-mysql-204644793
c10443222ac6 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" 5 hours ago Up 5 hours 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…" 5 hours ago Up 5 hours 9000/tcp testrail-fpm-204567103
6ae0accab28d mysql:5.7.22 "docker-entrypoint.s…" 5 hours ago Up 5 hours 3306/tcp testrail-mysql-204567103
b66b60d79e43 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" 5 hours ago Up 5 hours 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…" 5 hours ago Up 5 hours 9000/tcp testrail-fpm-204553690
a8879c5ef941 mysql:5.7.22 "docker-entrypoint.s…" 5 hours ago Up 5 hours 3306/tcp testrail-mysql-204553690
069954ba6010 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon of…" 5 hours ago Up 5 hours 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…" 5 hours ago Up 5 hours 9000/tcp testrail-fpm-204553539
1a1eed057ea0 mysql:5.7.22 "docker-entrypoint.s…" 5 hours ago Up 5 hours 3306/tcp testrail-mysql-204553539Toutes les tâches terminées avec succès
Les artefacts de tâches contiennent des journaux de services et de tests
Tout semble beau, mais il y a une nuance. Un pipeline peut être annulé de force pendant l'exécution des tests d'intégration, auquel cas les conteneurs en cours d'exécution ne seront pas arrêtés. De temps en temps, vous devez nettoyer le tapis. Malheureusement, la tâche de révision dans GitLab CE est toujours en cours
Mais nous avons ajouté un lancement de tâche planifié, et personne ne nous interdit de le démarrer manuellement.
Allez dans notre projet -> CI/CD -> Planifications et exécutez la tâche Clean runner
Total:
- Nous avons un coureur d'obus.
- Il n'y a pas de conflits entre les tâches et l'environnement.
- Nous avons un lancement parallèle de tâches avec des tests d'intégration.
- Vous pouvez exécuter des tests d'intégration à la fois localement et dans un conteneur.
- Les journaux de service et de test sont collectés et joints à la tâche de pipeline.
- Il est possible de nettoyer le coureur des anciennes images Docker.
Le temps d'installation est d'environ 2 heures.
En fait, c'est tout. Je serai heureux de faire part de vos commentaires.
Source: habr.com