Ein Hinweis zum Starten von Docker mit Systemd in Gitlab CI Runner. Vielleicht ist jemand nützlich, vielleicht hat jemand ein ähnliches Problem bereits auf andere Weise gelöst, und es wird interessant sein, wenn Sie in den Kommentaren teilen.
VorwortGitlab Runner wurde im Docker-Container bereitgestellt. Irgendwann kam die Idee auf, die gesamte erforderliche Infrastruktur (z. B. PostgreSQL und Tomcat) in einem Container zu sammeln, um die Anwendung nach der Kompilierungsphase und der Ausführung der Autotests zu installieren. Der Infrastrukturcontainer selbst wurde bereits basierend auf dem Debian-Image mit Systemd erstellt und funktionierte einwandfrei. Bei Verwendung in Runner traten jedoch unerwartete Probleme auf. Der Schrittcode war der Einfachheit halber folgendermaßen:
run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar
Alles scheint normal zu sein, aber beim Start schlägt der Schritt mit einem Fehler fehl, dass systemd nicht als Prozess mit ID 1 ausgeführt wird, oder ein anderer Fehler ist, dass systemd überhaupt nicht ausgeführt wird.
Was wäre das Problem?
Wie sich herausstellte, war ich bei einem neuen Problem mit Gitlab selbst nicht der einzige, der auf dieses Problem gestoßen ist.
Das Problem ist, dass der Gitlab Runner für den Docker-Container den CMD-Befehl immer überschreibt, d. H. Startet den Container mit folgendem Befehl:
docker run --cmd /bin/bash ...
Und es ist unmöglich, das Gitlab CMD neu zu definieren. Sie können nur den Einstiegspunkt im ci-Skript verwenden, aber das Tanzen damit hat zu nichts geführt.
Alle Rollen wurden von den Molekulartests abgedeckt und sie haben die Tests im GitLab-Runner erfolgreich bestanden. Nachdem ich darauf geachtet hatte, überlegte ich, warum ich den Container nicht mit systemd im gestarteten Runner starten sollte, g * mor natürlich, aber das Ergebnis war mir wichtiger als die Schwierigkeiten. Es ist möglich, einen Container einfach mit Docker-Befehlen zu starten, aber es ist nicht effektiv und es wird keine Fehlerbehandlung geben - irgendwie ist es möglicherweise nicht zu vorhersehbar. Deshalb habe ich beschlossen, einen kleinen handgefertigten Artikel in Python zu schreiben, der nur den Container startet und das Archiv mit dem erforderlichen kopiert Dateien und führen Sie eine Liste von Befehlen im Container aus.
→ Der Code ist hier:
GitHubSie können es so ausführen:
cd <path-with-code> pip install virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt python main.py \ --image dramaturg/docker-debian-systemd
Befehle in [] sind optional. Für Befehle, die eine Shell erfordern, z. B. ls -la und andere, wird ein spezielles {bash} -Makro benötigt. Es wird zur Laufzeit durch den
Befehl / bin / bash -c "Befehl" ersetzt .
Ich habe zum ersten Mal in Python geschrieben, also schimpfe nicht. Vielleicht gibt es Probleme im Code oder beim Start werde ich versuchen, es schnell zu beheben. Hier habe ich versucht, die allgemeine einfache Idee einer Startmethode zu erklären. Teilen Sie Ihre Erfahrungen mit, wenn Sie ähnliche Probleme haben.
Über das von dramaturg / docker-debian-systemd verwendete BildEs gibt keine Beschwerden über dieses Image, aber zuerst ist ein Fehler in der Konsole des Host-Computers aufgetreten, dass einige der von systemd erstellten Dateien bereits vorhanden sind. Es gab kein solches Problem im Nginx-Dienst, aber sie wurden in PostgreSQL angezeigt. Die Lösung bestand darin, den Block „VOLUME [“ / sys / fs / cgroup “,„ / run “,„ / run / lock “,„ / tmp “] zu löschen, danach funktionierte alles wie eine Uhr.