ProHoster > Blog > Amministrazione > GitLab Shell Runner. Lanciate in modu competitivu servizii testabili cù Docker Compose
GitLab Shell Runner. Lanciate in modu competitivu servizii testabili cù Docker Compose
Questu articulu serà d'interessu sia per i tester sia per i sviluppatori, ma hè destinatu principarmenti à i specialisti di l'automatizazione chì anu affruntatu u prublema di stallà GitLab CI/CD per teste di integrazione in cundizioni di risorse infrastrutturali insufficienti è / o l'assenza di un containeru. piattaforma d'orchestrazione. Vi diceraghju cumu stabilisce a implementazione di l'ambienti di prova utilizendu docker compose nantu à un unicu runner di shell GitLab è cusì chì quandu implementate parechji ambienti, i servizii lanciati ùn interferiscenu micca l'un l'altru.
In a mo pratica, spessu succorsu chì a prova di integrazione hè stata "trattata" nantu à i prughjetti. È spessu u primu è u prublema più significativu hè u pipeline CI, in quale teste di integrazione esse sviluppatu serviziu (s) hè realizatu in un ambiente di dev / stage. Questu hà causatu uni pochi di prublemi:
A causa di difetti in un serviziu particulari durante a prova di integrazione, u circuitu di prova pò esse dannatu da dati rotti. Ci sò stati casi quandu l'inviu di una dumanda cù un formatu JSON rottu hà crash u serviziu, chì rende u stand completamente inoperabile.
Rallentamentu di u circuitu di prova cum'è i dati di prova aumentanu. Pensu chì ùn hà micca sensu di discrive un esempiu cù a pulizia / rolling back a basa di dati. In a mo pratica, ùn aghju micca scontru un prughjettu induve sta prucedura hè andata bè.
Rischiu di disturbà a funziunalità di u circuitu di prova durante a prova di paràmetri generale di u sistema. Per esempiu, usu / gruppu / password / pulitica d'applicazione.
I dati di teste da e teste automatizate rende a vita difficiule per i tester manuali.
Qualchidunu diceranu chì i boni autotests duveranu pulizziari i dati dopu elli stessi. Aghju argumenti contru:
I stands dinamichi sò assai convenienti à aduprà.
Ùn ogni ughjettu pò esse eliminatu da u sistema per via di l'API. Per esempiu, una chjamata per sguassà un oggettu ùn hè micca implementata perchè contraddice a logica cummerciale.
Quandu crea un ughjettu via l'API, una quantità enorme di metadata pò esse creatu, chì hè problematicu per sguassà.
Se e teste anu dipendenze trà elli, u prucessu di pulizia di e dati dopu à eseguite e teste si trasforma in un mal di testa.
Chjami supplementari (è, in my opinion, micca ghjustificate) à l'API.
È l'argumentu principalu: quandu i dati di teste cumincianu à esse sbulicati direttamente da a basa di dati. Questu hè diventatu un veru circu PK / FK! Sentemu da i sviluppatori: "Aghju aghjustatu / sguassatu / rinominatu un segnu, perchè 100500 XNUMX teste d'integrazione sò stati chjappi?"
In my opinion, a suluzione più ottima hè un ambiente dinamicu.
Parechje persone utilizanu docker-compose per eseguisce un ambiente di prova, ma poche persone utilizanu docker-compose quandu realizanu teste di integrazione in CI/CD. È quì ùn sò micca pigliatu in contu i kubernetes, swarm è altre plataforme d'orchestrazione di container. Ùn ogni cumpagnia li hà. Saria bellu se docker-compose.yml era universale.
Ancu s'ellu avemu u nostru propiu QA runner, cumu pudemu assicurà chì i servizii lanciati via docker-compose ùn interferiscenu micca l'un l'altru?
Cumu cullà logs di servizii pruvati?
Cumu pulisce u corridore?
Aghju u mo propiu GitLab runner per i mo prughjetti è aghju scontru sti dumande durante u sviluppu Client Java di rail di prova. Più precisamente, quandu eseguite testi di integrazione. Sottu avemu risolviri sti prublemi cù esempii da stu prughjettu.
Per un corridore, ricumandemu una macchina virtuale Linux cù 4 vCPU, 4 GB RAM, 50 GB HDD.
Ci hè assai infurmazione nantu à a creazione di gitlab-runner in Internet, cusì brevemente:
Accedi à a macchina via SSH
Sì avete menu di 8 GB di RAM, allora vi cunsigliu fà scambià 10 GBcusì chì l'assassinu OOM ùn vene micca à tumbà i nostri compiti per mancanza di RAM. Questu pò accade quandu più di 5 attività sò lanciate simultaneamente. I travaglii avanzaranu più lentamente, ma fermamente.
Esempiu cù OOM killer
Se vede in i logs di u travagliu bash: line 82: 26474 Killed, poi basta à eseguisce nantu à u corridore 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
E se l'imaghjini pare qualcosa cusì, allora aghjunghje swap o aghjunghje RAM.
Questu vi permetterà di eseguisce attività parallele nantu à un corridore. Leghjite più ccà.
Se tenete una macchina più putente, per esempiu 8 vCPU, 16 GB RAM, allora questi numeri ponu esse fattu almenu 2 volte più grande. Ma tuttu dipende di ciò chì esattamente serà lanciatu nantu à questu corridore è in quale quantità.
U compitu principalu hè un docker-compose.yml universale, chì i sviluppatori / tester ponu utilizà à u locu è in u pipeline CI.
Prima di tuttu, facemu nomi di serviziu unichi per CI. Una di e variàbili uniche in GitLab CI hè a variàbile CI_JOB_ID. Se tu specifichi container_name cun significatu "service-${CI_JOB_ID:-local}", allora in u casu:
si CI_JOB_ID micca definitu in variabili ambientali,
allora u nome di serviziu serà service-local
si CI_JOB_ID definitu in variabili d'ambiente (per esempiu 123),
allora u nome di serviziu serà service-123
Siconda, creamu una reta cumuna per i servizii lanciati. Questu ci dà un isolamentu à livellu di rete quandu eseguite diversi ambienti di prova.
In fatti, questu hè u primu passu per u successu =)
Esempiu di u mo docker-compose.yml cù cumenti
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:
- default
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 days
In u risultatu di eseguisce una tale attività, u repertoriu di logs in l'artefatti cuntene logs di serviziu è di prova. Chì hè assai còmuda in casu di errore. Ogni teste in parallelu scrive u so propiu log, ma parleraghju di questu separatamente.
$ 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-204553539
Tutti i travaglii cumpletu cù successu
L'artefatti di u travagliu cuntenenu logs di serviziu è di prova
Tuttu pare esse bellu, ma ci hè una sfumatura. Pipeline pò esse annullatu per forza mentre i testi di integrazione sò in esecuzione, in quale casu i cuntenituri in esecuzione ùn saranu micca firmati. Da u tempu à u tempu avete bisognu di pulisce u corridore. Sfortunatamente, u compitu per migliurà in GitLab CE hè sempre in statu Open
Ma avemu aghjustatu u lanciamentu di un compitu secondu un calendariu, è nimu ci pruibisce di eseguisce manualmente.
Andà à u nostru prughjettu -> CI/CD -> Schedules è eseguite u compitu Clean runner
Total:
Avemu un corridore di cunchiglia.
Ùn ci hè micca cunflittu trà i travaglii è l'ambiente.
Eseguimu travaglii cù testi di integrazione in parallelu.
Pudete eseguisce testi di integrazione sia in u locu o in un containeru.
I logs di serviziu è di prova sò cullati è attaccati à u compitu di pipeline.
Hè pussibule di pulisce u corridore da vechji imagine Docker.
U tempu di installazione hè ~ 2 ore.
Hè tuttu, in realtà. Seraghju felice di riceve feedback.