Une micro note sur la façon de lancer Docker avec Systemd dans Gitlab CI Runner. Peut-être que quelqu'un sera utile, peut-être que quelqu'un a déjà résolu un problème similaire à d'autres égards et ce sera intéressant si vous partagez les commentaires.
PréfaceGitlab Runner a été déployé à l'intérieur du conteneur Docker. À un moment donné, l'idée est venue de rassembler toutes les infrastructures nécessaires (par exemple, PostgreSQL et Tomcat) dans un seul conteneur pour installer l'application après la phase de compilation et les autotests. Le conteneur d'infrastructure lui-même était déjà construit sur la base de l'image Debian avec Systemd et fonctionnait parfaitement. Mais une fois utilisé dans Runner, des problèmes inattendus ont commencé. Le code d'étape était, pour simplifier, disons ceci:
run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar
Tout semble normal, mais au démarrage, l'étape échouera avec une erreur que systemd ne s'exécute pas en tant que processus avec l'ID 1 ou peut-être une autre erreur sera que systemd ne s'exécute pas du tout.
Quel serait le problème?
Il s'est avéré que - sur un nouveau problème sur Gitlab lui-même, je n'étais pas le seul à rencontrer ce problème.
Le problème est que le Gitlab Runner pour le conteneur Docker écrase toujours la commande CMD, c'est-à-dire démarre le conteneur avec cette commande:
docker run --cmd /bin/bash ...
Et il est impossible de redéfinir le CMD Gitlab, vous ne pouvez utiliser que le point d'entrée à l'intérieur du script ci, mais danser avec lui n'a conduit à rien.
Tous les rôles ont été couverts par les tests moléculaires et ils ont réussi les tests à l'intérieur du runner GitLab. Après avoir prêté attention à cela, j'ai pensé, pourquoi ne pas lancer le conteneur avec systemd à l'intérieur du Runner lancé, g * mor, bien sûr, mais le résultat était plus important pour moi que les difficultés. Il est possible de simplement lancer un conteneur à l'aide des commandes de docker, mais ce n'est pas efficace, et il n'y aura pas de gestion des erreurs - en quelque sorte, ce n'est peut-être pas trop prévisible, j'ai donc décidé d'écrire un petit article fait à la main en Python qui lancerait simplement le conteneur, copierait l'archive avec le nécessaire fichiers et exécutez une liste de commandes à l'intérieur du conteneur.
→ Le code est ici:
GitHubVous pouvez l'exécuter comme ceci:
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
Les commandes entre [] sont facultatives. Une macro {bash} spéciale est nécessaire pour les commandes qui nécessitent un shell, par exemple, ls -la et autres. Elle sera remplacée par
/ bin / bash -c "commande" lors de l'exécution.
J'ai écrit en Python pour la première fois, alors ne grondez pas. Il y aura peut-être des problèmes dans le code ou au démarrage, je vais essayer de le corriger rapidement. Ici, j'ai essayé d'expliquer l'idée générale simple d'une méthode de démarrage. Partagez vos expériences si vous rencontrez des problèmes similaires.
À propos de l'image utilisée par dramaturg / docker-debian-systemdIl n'y a rien à redire sur cette image, mais au début, une erreur est apparue dans la console de la machine hôte, que certains des fichiers créés par systemd existent déjà. Il n'y avait pas un tel problème dans le service Nginx, mais ils sont apparus dans PostgreSQL. La solution consistait à supprimer le bloc "VOLUME [" / sys / fs / cgroup "," / run "," / run / lock "," / tmp "]", après quoi tout fonctionnait comme une horloge.