GitLab Shell Runner. Gleichzeitige Ausführung von getesteten Services mit Docker Compose

Dieser Artikel richtet sich sowohl an Tester als auch an Entwickler, ist jedoch besonders für Automatisierer von Interesse, die mit dem Problem konfrontiert sind, GitLab CI/CD für integrierte Tests unter unzureichenden infrastrukturellen Ressourcen und/oder dem Fehlen einer Container-Orchestrierungsplattform einzurichten. Ich werde erklären, wie man das Bereitstellen von Testumgebungen mit Docker Compose auf einem einzigen GitLab Shell Runner einrichtet, sodass sich die laufenden Services bei der Bereitstellung mehrerer Umgebungen nicht gegenseitig stören.

Inhalt

• Voraussetzungen
• GitLab Shell Runner
• Vorbereitung der docker-compose.yml
• Vorbereitung des Makefile
• Vorbereitung der .gitlab-ci.yml
  • Ausführung der Integrationstests
  • Bereinigung des Runners
• Ergebnis

Voraussetzungen

1. In meiner Praxis kam es häufig vor, dass ich das integrierte Testen in Projekten 'reparieren' musste. Dabei ist oft das größte Problem die CI-Pipeline, in der die Integrationstests des entwickelten Service(s) in der Dev-/Stage-Umgebung durchgeführt werden. Dies führte zu zahlreichen Problemen:

   • Wegen Fehlern in einem bestimmten Dienst während der Integrationstestphase kann der Teststand durch fehlerhafte Daten beschädigt werden. Es gab Fälle, in denen das Senden einer Anfrage mit fehlerhaftem JSON-Format den Dienst zum Abstürzen brachte, was den Stand vollständig in einen nicht funktionierenden Zustand versetzte.
   • Die Leistung des Teststandes kann mit zunehmenden Testdaten langsamer werden. Ich denke, es ist nicht notwendig, ein Beispiel für das Bereinigen/Zurücksetzen der Datenbank zu beschreiben. In meiner Praxis habe ich kein Projekt erlebt, bei dem dieser Prozess reibungslos ablief.
   • Es besteht das Risiko, die Funktionsfähigkeit des Teststandes bei der Prüfung allgemeiner Systemeinstellungen zu beeinträchtigen. Zum Beispiel user/group/password/application policy.
   • Testdaten von automatisierten Tests stören manuelle Tester.

   Manche werden sagen, dass gute automatisierte Tests ihre Daten nach der Nutzung bereinigen sollten. Ich habe Argumente dagegen:

   • Dynamische Stände sind äußerst benutzerfreundlich.
   • Nicht jeder Gegenstand kann über die API aus dem System gelöscht werden. Zum Beispiel ist der Aufruf zur Löschung eines Objekts nicht implementiert, da er der Geschäftlogik widerspricht.
   • Bei der Erstellung eines Objekts über die API können eine Vielzahl von Metadaten generiert werden, deren Löschung problematisch ist.
   • Wenn Tests untereinander abhängen, wird der Prozess der Datenbereinigung nach der Ausführung der Tests zur echten Plage.
   • Zusätzliche (und meiner Meinung nach ungerechtfertigte) Aufrufe an die API.
   • Und das Hauptargument: wenn Testdaten direkt aus der Datenbank bereinigt werden. Das wird zu einem echten PK/FK-Zirkus! Von den Entwicklern hört man: „Ich habe nur die Tabelle hinzugefügt/entfernt/umbenannt, warum sind dann 100500 Integrationstests betroffen?“

   Meiner Meinung nach ist die optimale Lösung eine dynamische Umgebung.

2. Viele nutzen docker-compose zum Starten von Testumgebungen, aber nur wenige verwenden docker-compose bei der Durchführung von Integrationstests in CI/CD. Dabei lasse ich Kubernetes, Swarm und andere Container-Orchestrierungsplattformen außen vor. Nicht in jedem Unternehmen sind diese vorhanden. Wäre es nicht gut, wenn die docker-compose.yml universell wäre?
3. Selbst wenn wir unseren eigenen QA-Runner haben, wie sorgen wir dafür, dass die über docker-compose gestarteten Services sich nicht gegenseitig behindern?
4. Wie sammelt man die Logs der getesteten Services?
5. Wie reinigt man den Runner?

Ich habe einen eigenen GitLab-Runner für meine Projekte, und mit diesen Fragen bin ich bei der Entwicklung konfrontiert worden Java-Client für TestRail. Genauer gesagt, beim Start von Integrationstests. Hier werden wir diese Fragen mit Beispielen aus diesem Projekt klären.

Zurück zum Inhalt

GitLab Shell Runner

Für den Runner empfehle ich eine Linux-VM mit 4 vCPU, 4 GB RAM und 50 GB HDD.
Im Internet gibt es sehr viele Informationen zur Einrichtung von gitlab-runner, deswegen hier nur die Kurzfassung:

• Greifen Sie per SSH auf die Maschine zu.

• Wenn Sie weniger als 8 GB RAM haben, empfehle ich einen Swap von 10 GB anzulegen., damit der OOM-Killer nicht eingreift und uns Aufgaben aufgrund von RAM-Mangel beendet. Dies kann passieren, wenn mehr als 5 Aufgaben gleichzeitig gestartet werden. Die Aufgaben werden langsamer bearbeitet, aber stabil.

  Beispiel mit OOM-Killer:

  Wenn Sie in den Logs der Aufgabe sehen: bash: Zeile 82: 26474 Getötet, führen Sie einfach auf dem Runner aus: sudo dmesg | grep 26474

  [26474]  1002 26474  1061935   123806     339        0             0 java
  Out of Memory: Prozess 26474 (java) wurde beendet oder ein Kindopfer geopfert.
  Prozess 26474 (java) mit total-vm:4247740kB, anon-rss:495224kB, file-rss:0kB, shmem-rss:0kB wurde getötet.

  Und wenn die Anzeige ungefähr so aussieht, fügen Sie entweder Swap hinzu oder erhöhen Sie den RAM.

• Installieren Sie gitlab-runner, docker, version: '1' services: simplesample-sonar: image: sonarqube:lts ports: - 9001:9000 - 9092:9092 network_mode: bridge, make.
• Fügen Sie den Benutzer gitlab-runner zur Gruppe hinzu. docker

  sudo groupadd docker
  sudo usermod -aG docker gitlab-runner

• Registrieren Sie gitlab-runner.

• Öffnen Sie die Datei zur Bearbeitung /etc/gitlab-runner/config.toml und fügen Sie hinzu

  concurrent=20
  [[runners]]
    request_concurrency = 10

  Das ermöglicht das gleichzeitige Ausführen von Aufgaben auf einem Runner. Detailliertere Informationen finden Sie hier. hier.
  Wenn Sie eine leistungsstärkere Maschine haben, zum Beispiel 8 vCPU und 16 GB RAM, können diese Zahlen mindestens um das Doppelte erhöht werden. Doch das hängt davon ab, was genau auf diesem Runner ausgeführt wird und in welcher Menge.

Das ist ausreichend.

Zurück zum Inhalt

Vorbereitung der docker-compose.yml

Die Hauptaufgabe besteht darin, eine universelle docker-compose.yml zu erstellen, die Entwickler und Tester sowohl lokal als auch im CI-Pipeline nutzen können.

Zuerst erstellen wir einzigartige Servicenamen für das CI. Eine der einzigartigen Variablen in GitLab CI ist die Variable CI_JOB_ID. Wenn wir angeben container_name mit dem Wert "service-${CI_JOB_ID:-local}", dann gilt:

• wenn CI_JOB_ID Wenn nicht in den Umgebungsvariablen definiert,
  wird der Servicename sein service-local
• wenn CI_JOB_ID Wenn in den Umgebungsvariablen definiert (zum Beispiel 123),
  wird der Servicename sein service-123

Als Nächstes erstellen wir ein gemeinsames Netzwerk für die gestarteten Dienste. Dies gibt uns Netzwerkteilung, wenn mehrere Testumgebungen ausgeführt werden.

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

Das ist der erste Schritt zum Erfolg =)

Ein Beispiel meiner docker-compose.yml mit Kommentaren

version: "3"

# Für das ordnungsgemäße Funktionieren von web (php) und fmt ist es nötig, 
# dass die Container gemeinsam ausführbare Inhalte haben.
# In unserem Fall ist das Verzeichnis /var/www/testrail
volumes:
  static-content:

# Isolierung der Umgebung auf Netzwerkebene
networks:
  default:
    external:
      name: testrail-network-${CI_JOB_ID:-local}

services:
  db:
    image: mysql:5.7.22
    # Jeder container_name enthält ${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}"
    # Wenn die Variablen TR_HTTP_PORT oder TR_HTTPS_PORTS nicht definiert sind,
    # wird der Dienst auf den Ports 80 bzw. 443 gestartet.
    ports:
      - ${TR_HTTP_PORT:-80}:80
      - ${TR_HTTPS_PORT:-443}:443
    volumes:
      - static-content:/var/www/testrail
    links:
      - db
      - fpm
    networks:
      - default

Beispiel für den lokalen Start

docker-compose -f docker-compose.yml up -d
Starte   testrail-mysql-local     ... erledigt
Starte   testrail-migration-local ... erledigt
Starte   testrail-fpm-local       ... erledigt
Erstelle testrail-web-local       ... erledigt

Aber es ist nicht so einfach, einen CI-Betrieb zu starten.

Zurück zum Inhalt

Vorbereitung des Makefile

Ich benutze Makefile, da es sehr praktisch sowohl für die lokale Umgebungsverwaltung als auch in CI ist. Nachfolgend Inline-Kommentare.

# У меня в проектах все вспомогательные вещи лежат в директории `.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

Wir überprüfen.

make docker-up

$ make docker-up 
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml kill
Beende testrail-web-local   ... erledigt
Beende testrail-fpm-local   ... erledigt
Beende testrail-mysql-local ... erledigt
docker network rm network-${CI_JOB_ID:-testrail} || true
netwerk-testrail
docker network create network-${CI_JOB_ID:-testrail}
d2ec063324081c8bbc1b08fd92242c2ea59d70cf4025fab8efcbc5c6360f083f
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml pull
Lade db        ... erledigt
Lade migration ... erledigt
Lade fpm       ... erledigt
Lade web       ... erledigt
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Erstelle testrail-mysql-local ... erledigt
Erstelle testrail-fpm-local       ... erledigt
Erstelle testrail-migration-local ... erledigt
Erstelle testrail-web-local       ... erledigt
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: Kann Verzeichnis ‘./logs’ nicht erstellen: Verzeichnis existiert
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

Zurück zum Inhalt

Vorbereitung der .gitlab-ci.yml

Ausführung der Integrationstests

Integration:
  stage: test
  tags:
    - my-shell-runner
  before_script:
    # Authentifizierung im Repository
    - docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
    # Generierung pseudouniquier TR_HTTP_PORT und TR_HTTPS_PORT
    - export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
    - export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
    # Verzeichnis mit der Auftrags-ID erstellen
    - mkdir ${CI_JOB_ID}
    # Kopieren Sie unsere docker-compose.yml in das erstellte Verzeichnis
    # um einen anderen Kontext für jede Aufgabe zu haben
    - cp .indirect/docker-compose.yml ${CI_JOB_ID}/docker-compose.yml
  script:
    # Unsere Umgebung hochfahren
    - make docker-up
    # Führen Sie Tests mit der ausführbaren JAR aus (ich mache das so)
    - java -jar itest.jar --http-port ${TR_HTTP_PORT} --https-port ${TR_HTTPS_PORT}
    # oder im Container
    - docker run --network=testrail-network-${CI_JOB_ID:-local} --rm itest
  after_script:
    # Logs sammeln
    - make docker-logs
    # Umgebung anhalten
    - make docker-kill
  artifacts:
    # Logs speichern
    when: always
    paths:
      - logs
    expire_in: 30 Tage

Durch das Starten eines solchen Jobs wird das Verzeichnis logs in den Artefakten die Protokolle der Dienste und Tests enthalten. Dies ist besonders praktisch im Falle von Fehlern. Jeder Test, der parallel läuft, schreibt sein eigenes Protokoll, aber darüber werde ich gesondert berichten.

Zurück zum Inhalt

Bereinigung des Runners

Die Aufgabe wird nur nach Zeitplan ausgeführt.

stufen:
- bereinigen
- bauen
- testen

Bereinigen Runner:
  stufe: bereinigen
  nur:
    - zeitpläne
  tags:
    - mein-shell-runner
  skript:
    - make docker-clean

Dann gehen wir in unser GitLab-Projekt -> CI/CD -> Zeitpläne -> Neuer Zeitplan und fügen einen neuen Zeitplan hinzu.

Zurück zum Inhalt

Ergebnis

Wir starten 4 Aufgaben in GitLab CI.

In den Protokollen der letzten Aufgabe mit den Integrationstests sehen wir Container von verschiedenen Aufgaben.

CONTAINER ID  NAMEN
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

Detailiertes Protokoll

$ docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
WARNUNG! Die Verwendung von --password über die CLI ist unsicher. Verwenden Sie --password-stdin.
WARNUNG! Ihr Passwort wird unverschlüsselt in /home/gitlab-runner/.docker/config.json gespeichert.
Konfigurieren Sie einen Anmeldehelfer, um diese Warnung zu entfernen. Siehe
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Anmeldung erfolgreich
$ 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
Fehler: Solches Netzwerk existiert nicht: testrail-network-204645172
docker network create testrail-network-${CI_JOB_ID:-local}
0a59552b4464b8ab484de6ae5054f3d5752902910bacb0a7b5eca698766d0331
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml pull
Web wird heruntergeladen ... erledigt
FPM wird heruntergeladen ... erledigt
Migration wird heruntergeladen ... erledigt
DB wird heruntergeladen ... erledigt
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Erstelle Volume "204645172_static-content" mit dem Standardtreiber
Erstelle testrail-mysql-204645172 ... 
Erstelle testrail-mysql-204645172 ... erledigt
Erstelle testrail-migration-204645172 ... erledigt
Erstelle testrail-fpm-204645172 ... erledigt
Erstelle testrail-web-204645172 ... erledigt
docker ps
CONTAINER-ID        IMAGE                                                          BEFEHL                  ERSTELLT              STATUS              PORTS                                           NAME
c6b76f9135ed        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor 13 Sekunden       Hoch 1 Sekunden         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…"   vor 16 Sekunden       Hoch 13 Sekunden       9000/tcp                                        testrail-fpm-204645172
2cdab1edbf6a        registry.gitlab.com/touchbit/image/testrail/migration:latest   "docker-entrypoint.s…"   vor 16 Sekunden       Hoch 13 Sekunden       3306/tcp, 33060/tcp                             testrail-migration-204645172
826aaf7c0a29        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor 18 Sekunden       Hoch 16 Sekunden       3306/tcp                                        testrail-mysql-204645172
6dbb3fae0322        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor 36 Sekunden       Hoch 22 Sekunden       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…"   vor 38 Sekunden       Hoch 35 Sekunden       9000/tcp                                        testrail-fpm-204645084
70fea72aa10d        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor 40 Sekunden       Hoch 37 Sekunden       3306/tcp                                        testrail-mysql-204645084
d8aa24b2892d        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor etwa einer Minute   Hoch 53 Sekunden       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…"   vor etwa einer Minute   Hoch etwa eine Minute   9000/tcp                                        testrail-fpm-204644881
685d8023a3ec        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor etwa einer Minute   Hoch etwa eine Minute   3306/tcp                                        testrail-mysql-204644881
1cdfc692003a        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor etwa einer Minute   Hoch etwa eine 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…"   vor etwa einer Minute   Hoch etwa eine Minute   9000/tcp                                        testrail-fpm-204644793
029e16b26201        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor etwa einer Minute   Hoch etwa eine Minute   3306/tcp                                        testrail-mysql-204644793
c10443222ac6        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor 5 Stunden          Hoch 5 Stunden          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…"   vor 5 Stunden          Hoch 5 Stunden          9000/tcp                                        testrail-fpm-204567103
6ae0accab28d        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor 5 Stunden          Hoch 5 Stunden          3306/tcp                                        testrail-mysql-204567103
b66b60d79e43        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor 5 Stunden          Hoch 5 Stunden          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…"   vor 5 Stunden          Hoch 5 Stunden          9000/tcp                                        testrail-fpm-204553690
a8879c5ef941        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor 5 Stunden          Hoch 5 Stunden          3306/tcp                                        testrail-mysql-204553690
069954ba6010        registry.gitlab.com/touchbit/image/testrail/web:latest         "nginx -g 'daemon of…"   vor 5 Stunden          Hoch 5 Stunden          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…"   vor 5 Stunden          Hoch 5 Stunden          9000/tcp                                        testrail-fpm-204553539
1a1eed057ea0        mysql:5.7.22                                                   "docker-entrypoint.s…"   vor 5 Stunden          Hoch 5 Stunden          3306/tcp                                        testrail-mysql-204553539

Alle Aufgaben wurden erfolgreich abgeschlossen

Die Artefakte der Aufgabe enthalten Protokolle von Diensten und Tests

Es sieht alles gut aus, aber es gibt einen Haken. Der Pipeline kann während der Ausführung von Integrationstests zwangsweise abgebrochen werden, und in diesem Fall werden die gestarteten Container nicht gestoppt. Ab und zu muss der Runner gereinigt werden. Leider hat die Aufgabe zur Nachbearbeitung in GitLab CE immer noch den Status Öffnen

Aber wir haben die Möglichkeit, die Aufgabe nach Zeitplan zu starten, und niemand hindert uns daran, sie manuell zu starten.
Gehen wir zu unserem Projekt -> CI/CD -> Zeitpläne und starten wir die Aufgabe Clean runner

Insgesamt:

• Wir haben einen Shell-Runner.
• Es gibt keine Konflikte zwischen Aufgaben und Umgebung.
• Wir haben parallele Ausführungen von Aufgaben mit Integrationstests.
• Integrationstests können sowohl lokal als auch in einem Container ausgeführt werden.
• Die Protokolle von Diensten und Tests werden gesammelt und an der Pipeline-Aufgabe angehängt.
• Es gibt die Möglichkeit, den Runner von alten Docker-Images zu bereinigen.

Einrichtungszeit — ca. 2 Stunden.
Das ist alles. Ich freue mich auf Ihr Feedback.

Zurück zum Inhalt

Quelle: habr.com