¿Es posible hacer amigos Gitlab CI + Docker + Systemd

Una micro nota sobre cómo iniciar Docker con Systemd dentro de Gitlab CI Runner. Tal vez alguien sea útil, tal vez alguien ya haya resuelto un problema similar de otras maneras y será interesante si comparte los comentarios.

Prólogo
Gitlab Runner se implementó dentro del contenedor Docker. En algún momento, surgió la idea de recopilar toda la infraestructura necesaria (por ejemplo, PostgreSQL y Tomcat) dentro de un contenedor para instalar la aplicación después de la etapa de compilación y las pruebas automáticas. El contenedor de infraestructura en sí ya estaba construido en base a la imagen de Debian con Systemd y funcionaba perfectamente. Pero cuando se usa dentro de Runner, comienzan problemas inesperados. El código de paso era, por simplicidad, digamos esto:

run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar 

Todo parece ser normal, pero al inicio el paso fallará con un error de que systemd no se está ejecutando como un proceso con ID 1 o tal vez otro error sea que systemd no se está ejecutando en absoluto.

¿Cuál sería el problema?

Al final resultó que, en un nuevo problema en Gitlab, no fui el único en encontrar este problema.
El problema es que Gitlab Runner para el contenedor Docker siempre sobrescribe el comando CMD, es decir inicia el contenedor con este comando:

 docker run --cmd /bin/bash ... 

Y es imposible redefinir el CMD de Gitlab, solo puede usar el punto de entrada dentro del script ci, pero bailar con él no condujo a nada.

Todos los roles fueron cubiertos por las pruebas de moléculas y pasaron con éxito las pruebas dentro del corredor GitLab. Habiendo prestado atención a esto, pensé, ¿por qué no lanzar el contenedor con systemd dentro del Runner lanzado, g * mor, por supuesto, pero el resultado fue más importante para mí que las dificultades? Es posible simplemente lanzar un contenedor usando los comandos de la ventana acoplable, pero no es efectivo, y no habrá ningún manejo de errores; de alguna manera, podría no ser demasiado predecible, así que decidí escribir un pequeño artículo hecho a mano en Python que simplemente lanzaría el contenedor, copie el archivo con la información necesaria. archivos y ejecutar una lista de comandos dentro del contenedor.

→ El código está aquí: GitHub

Puedes ejecutarlo así:

 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 #   [--network host] #     [--volumes] "/sys/fs/cgroup:/sys/fs/cgroup:ro" "<>" #  volume   systemd,      [--cmd] "/lib/systemd/systemd" # ,      ,      [--data-archive] /opt/data.tar #     *.tar  *.tar.gz [--data-unarchive-path] /opt/data/logs #     ,      [--privileged] #   systemd ,        --exec-commands "touch /opt/example.log" "{bash} ls -la /opt" "mkdir -p /opt/tmp" #       

Los comandos en [] son ​​opcionales. Se necesita una macro {bash} especial para los comandos que requieren un shell, por ejemplo, ls -la y otros. Se reemplazará en tiempo de ejecución con / bin / bash -c "comando" .

Escribí en Python por primera vez, así que no me regañes. Tal vez haya problemas en el código o en el inicio, intentaré solucionarlo rápidamente. Aquí intenté explicar la idea general simple de un método de inicio. Comparte tus experiencias si tienes problemas similares.

Acerca de la imagen utilizada por dramaturg / docker-debian-systemd
No hay quejas sobre esta imagen, pero al principio hubo un error que apareció en la consola de la máquina host, que algunos de los archivos que crea systemd ya existen. No hubo tal problema en el servicio Nginx, pero aparecieron en PostgreSQL. La solución fue eliminar el bloque "VOLUME [" / sys / fs / cgroup "," / run "," / run / lock "," / tmp "]", después de eso todo funcionó como un reloj.

Source: https://habr.com/ru/post/es413375/


All Articles