ProHoster > Blog > Administración > GitLab Shell Runner. Lanzamento competitivo de servizos probados mediante Docker Compose
GitLab Shell Runner. Lanzamento competitivo de servizos probados mediante Docker Compose
Este artigo será de interese tanto para probadores como para desenvolvedores, pero está destinado principalmente a especialistas en automatización que se enfrontan ao problema de configurar GitLab CI/CD para probas de integración en condicións de insuficiencia de recursos de infraestrutura e/ou ausencia de contedor. plataforma de orquestración. Vouche dicir como configurar o despregamento de ambientes de proba usando docker compose nun único shell runner de GitLab e para que ao despregar varios ambientes, os servizos iniciados non interfiran entre si.
Na miña práctica, moitas veces ocorreu que as probas de integración eran "tratadas" nos proxectos. E moitas veces o primeiro e máis importante problema é o gasoduto CI, no que se realizan as probas de integración sendo desenvolvido o servizo(s) realízase nun ambiente de desenvolvemento/etapa. Isto causou bastantes problemas:
Debido a defectos nun servizo determinado durante as probas de integración, o circuíto de proba pode resultar danado por datos rotos. Houbo casos nos que o envío dunha solicitude cun formato JSON roto provocou un fallo no servizo, o que fixo que o soporte fose completamente inoperable.
Ralentización do circuíto de proba a medida que aumentan os datos da proba. Creo que non ten sentido describir un exemplo coa limpeza/reversión da base de datos. Na miña práctica, non atopei ningún proxecto no que este procedemento fose sen problemas.
Existe o risco de interromper a funcionalidade do circuíto de proba ao probar a configuración xeral do sistema. Por exemplo, usuario/grupo/contrasinal/política de aplicación.
Os datos das probas automatizadas dificultan a vida dos probadores manuais.
Algúns dirán que as boas probas automáticas deberían limpar os datos despois de si mesmas. Teño argumentos en contra:
Os soportes dinámicos son moi cómodos de usar.
Non todos os obxectos se poden eliminar do sistema a través da API. Por exemplo, non se implementou unha chamada para eliminar un obxecto porque contradí a lóxica empresarial.
Ao crear un obxecto a través da API, pódese crear unha gran cantidade de metadatos, o que é problemático de eliminar.
Se as probas teñen dependencias entre elas, o proceso de limpeza de datos despois de executar as probas convértese nun dor de cabeza.
Chamadas adicionais (e, na miña opinión, non xustificadas) á API.
E o argumento principal: cando os datos de proba comezan a borrarse directamente da base de datos. Isto estase a converter nun auténtico circo PK/FK! Escoitamos dos desenvolvedores: "Acabo de engadir/eliminar/ renomear un sinal, por que se atraparon 100500 probas de integración?"
Na miña opinión, a solución máis óptima é un ambiente dinámico.
Moitas persoas usan docker-compose para executar un ambiente de proba, pero poucas persoas usan docker-compose cando realizan probas de integración en CI/CD. E aquí non estou tendo en conta os kubernetes, swarm e outras plataformas de orquestración de contedores. Non todas as empresas os teñen. Sería bo que docker-compose.yml fose universal.
Aínda que teñamos o noso propio corredor de control de calidade, como podemos asegurarnos de que os servizos lanzados a través de docker-compose non interfiran entre si?
Como recoller rexistros dos servizos probados?
Como limpar o corredor?
Teño o meu propio corredor de GitLab para os meus proxectos e atopeime con estas preguntas durante o desenvolvemento Cliente Java para TestRail. Máis precisamente, cando se executan probas de integración. A continuación resolveremos estes problemas utilizando exemplos deste proxecto.
Para un corredor, recoméndolle unha máquina virtual Linux con 4 vCPU, 4 GB de RAM, 50 GB de disco duro.
Hai moita información sobre como configurar gitlab-runner en Internet, así que brevemente:
Inicie sesión na máquina a través de SSH
Se tes menos de 8 GB de RAM, recoméndoo facer intercambio de 10 GBpara que o asasino de OOM non veña e mate as nosas tarefas por falta de memoria RAM. Isto pode ocorrer cando se inician máis de 5 tarefas á vez. As tarefas avanzarán máis lentamente, pero de forma constante.
Exemplo con OOM killer
Se ves nos rexistros de tarefas bash: line 82: 26474 Killed, entón só executa sobre o corredor 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 a imaxe parece algo así, engade intercambio ou engade RAM.
Isto permitirache realizar tarefas paralelas nun corredor. Le máis aquí.
Se tes unha máquina máis potente, por exemplo 8 vCPU, 16 GB de RAM, estes números pódense facer polo menos 2 veces máis grandes. Pero todo depende do que se lanzará exactamente neste corredor e en que cantidade.
A tarefa principal é un docker-compose.yml universal, que os desenvolvedores/probadores poden usar tanto localmente como no pipeline CI.
En primeiro lugar, creamos nomes de servizos únicos para CI. Unha das variables únicas en GitLab CI é a variable CI_JOB_ID. Se o especificas container_name con valor "service-${CI_JOB_ID:-local}", entón no caso:
se CI_JOB_ID non definido nas variables de ambiente,
entón o nome do servizo será service-local
se CI_JOB_ID definido en variables de ambiente (por exemplo 123),
entón o nome do servizo será service-123
En segundo lugar, creamos unha rede común para os servizos iniciados. Isto ofrécenos illamento a nivel de rede cando executamos varios ambientes de proba.
En realidade, este é o primeiro paso para o éxito =)
Exemplo do meu docker-compose.yml con comentarios
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
Como resultado da execución desta tarefa, o directorio de rexistros dos artefactos conterá rexistros de servizo e de proba. O que é moi cómodo en caso de erros. Cada proba en paralelo escribe o seu propio rexistro, pero disto falarei por separado.
$ 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
Todas as tarefas completadas con éxito
Os artefactos das tarefas conteñen rexistros de probas e servizos
Todo parece ser bonito, pero hai un matiz. O pipeline pódese cancelar de forma forzada mentres se executan as probas de integración, nese caso non se deterán os contedores en execución. De cando en vez cómpre limpar o corredor. Desafortunadamente, a tarefa de mellora en GitLab CE aínda está en estado aberto
Pero engadimos o lanzamento dunha tarefa segundo unha programación, e ninguén nos prohibe executala manualmente.
Vaia ao noso proxecto -> CI/CD -> Programacións e executa a tarefa Clean runner
Total:
Temos un corredor de cunchas.
Non hai conflitos entre as tarefas e o ambiente.
Realizamos tarefas con probas de integración en paralelo.
Pode executar probas de integración localmente ou nun contedor.
Os rexistros de servizo e de proba recóllense e anxúntanse á tarefa de canalización.
É posible limpar o corredor das imaxes antigas de Docker.
O tempo de configuración é de aproximadamente 2 horas.
Iso é todo, en realidade. Estarei encantado de recibir comentarios.