ProHoster > Blog > podávání > GitLab Shell Runner. Pomocí Docker Compose spusťte konkurenční služby
GitLab Shell Runner. Pomocí Docker Compose spusťte konkurenční služby
Tento článek bude zajímavý jak pro testery, tak pro vývojáře, ale je určen spíše pro automaty, kteří se potýkají s problémem nastavení GitLab CI / CD pro integrační testování tváří v tvář nedostatečným zdrojům infrastruktury a/nebo absenci kontejnerové orchestrace plošina. Řeknu vám, jak nakonfigurovat nasazení testovacích prostředí pomocí docker compose na jediném běhu prostředí GitLab a tak, aby se při nasazení více prostředí vzájemně spouštěné služby nerušily.
V mé praxi se často stávalo „ošetření“ integračního testování na projektech. A často prvním a nejvýznamnějším problémem je potrubí CI, ve kterém je integrační testování rozvinutý služba (služby) je hostována v prostředí dev/stage. To způsobilo několik problémů:
Kvůli závadám v té či oné službě během testování integrace může být testovací obvod poškozen poškozenými daty. Vyskytly se případy, kdy odeslání požadavku s nefunkčním formátem JSON zavěsilo službu, což způsobilo úplnou nefunkčnost stojanu.
Zpomalení testovacího okruhu s nárůstem testovacích dat. Myslím, že nemá smysl popisovat příklad s čištěním / vrácením databáze. Ve své praxi jsem se nesetkal s projektem, kde by tento postup probíhal hladce.
Riziko narušení výkonu testovacího okruhu při testování obecných nastavení systému. Například zásady uživatele/skupiny/hesla/aplikace.
Testovací data z autotestů ztěžují život manuálním testerům.
Někdo řekne, že dobré autotesty by po sobě měly data uklidit. Mám argumenty proti:
Dynamické stojany se velmi pohodlně používají.
Ne každý objekt lze ze systému odstranit přes API. Například není implementováno volání k odstranění objektu, protože to odporuje obchodní logice.
Při vytváření objektu přes API lze vytvořit obrovské množství metadat, jejichž odstranění je problematické.
Pokud jsou testy na sobě závislé, pak se proces čištění dat po provedení testů změní v bolest hlavy.
Dodatečné (a podle mého názoru neopodstatněné) volání API.
A hlavní argument: když se testovací data začnou čistit přímo z databáze. Tohle se mění ve skutečný PK/FK cirkus! Slyšíme od vývojářů: „Právě jsem přidal/odstranil/přejmenoval značku, proč 100500 XNUMX integračních testů propadlo?“
Dle mého názoru je nejoptimálnějším řešením dynamické prostředí.
Mnoho lidí používá docker-compose ke spuštění testovacího prostředí, ale jen málo lidí používá docker-compose při testování integrace v CI/CD. A tady neberu v úvahu kubernetes, swarm a další platformy pro orchestraci kontejnerů. Ne každá společnost je má. Bylo by hezké, kdyby docker-compose.yml byl univerzální.
I když máme vlastní QA runner, jak můžeme zajistit, aby se služby spouštěné prostřednictvím docker-compose vzájemně nerušily?
Jak sbírat protokoly testovaných služeb?
Jak vyčistit běžec?
Mám pro své projekty vlastní GitLab runner a na tyto problémy jsem narazil při vývoji Java klient pro zkušební kolejnice. Přesněji při spouštění integračních testů. Zde budeme pokračovat v řešení těchto problémů s příklady z tohoto projektu.
Pro běžce doporučuji linuxový virtuální stroj se 4 vCPU, 4 GB RAM, 50 GB HDD.
Na internetu je spousta informací o nastavení gitlab-runner, takže ve zkratce:
Jdeme do stroje přes SSH
Pokud máte méně než 8 GB RAM, pak doporučuji proveďte swap 10 GBaby nepřišel OOM zabiják a nezabil nám úkoly kvůli nedostatku RAM. K tomu může dojít, když současně běží více než 5 úloh. Úkoly budou pomalejší, ale stabilní.
Příklad s OOM zabijákem
Pokud v protokolech úloh vidíte bash: line 82: 26474 Killed, pak stačí provést na běžci 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
A pokud obrázek vypadá nějak takto, tak buď přidejte swap, nebo hoďte RAM.
To vám umožní spouštět paralelní úlohy na stejném běžci. Přečtěte si více zde.
Pokud máte výkonnější stroj, například 8 vCPU, 16 GB RAM, pak lze tato čísla udělat alespoň 2krát větší. Vše ale záleží na tom, co přesně bude na tomto běžci spuštěno a v jakém množství.
Hlavním úkolem je univerzální docker-compose.yml, který mohou vývojáři / testeři používat lokálně i v CI pipeline.
Nejprve vytváříme jedinečné názvy služeb pro CI. Jednou z jedinečných proměnných v GitLab CI je proměnná CI_JOB_ID. Pokud určíte container_name s hodnotou "service-${CI_JOB_ID:-local}", pak v případě:
jestliže CI_JOB_ID není definováno v proměnných prostředí,
pak bude název služby service-local
jestliže CI_JOB_ID definované v proměnných prostředí (např. 123),
pak bude název služby service-123
Za druhé, vytvoříme společnou síť pro provozování služeb. To nám poskytuje izolaci na úrovni sítě při spouštění více testovacích prostředí.
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
V důsledku spuštění takové úlohy bude adresář logs v artefaktech obsahovat protokoly služeb a testů. Což se v případě chyb velmi hodí. Každý test paralelně zapisuje svůj vlastní protokol, ale o tom budu mluvit samostatně.
$ 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
Všechny úkoly byly úspěšně dokončeny
Artefakty úkolů obsahují protokoly služeb a testů
Všechno se zdá být krásné, ale existuje nuance. Potrubí lze násilně zrušit, když běží integrační testy, v takovém případě se běžící kontejnery nezastaví. Čas od času je potřeba vyčistit běžec. Úkol k revizi v GitLab CE je bohužel stále ve stavu Otevřená
Přidali jsme ale plánované spouštění úlohy a nikdo nám nezakazuje spouštět ji ručně.
Přejděte do našeho projektu -> CI/CD -> Plány a spusťte úlohu Clean runner
Celkem:
Máme jeden skořepinový běžec.
Mezi úkoly a prostředím nedochází ke konfliktům.
Máme paralelní spouštění úloh s integračními testy.
Integrační testy můžete spouštět lokálně i v kontejneru.
Servisní a testovací protokoly se shromažďují a připojují k úloze potrubí.
Je možné vyčistit běžec od starých obrázků dockeru.
Doba nastavení je ~2 hodiny.
To je ve skutečnosti vše. Budu rád za zpětnou vazbu.