É possível fazer amigos Gitlab CI + Docker + Systemd

Uma micro-nota sobre como iniciar o Docker com Systemd no Gitlab CI Runner. Talvez alguém seja útil, talvez alguém já tenha resolvido um problema semelhante de outras maneiras e será interessante se você compartilhar os comentários.

Prefácio
O Gitlab Runner foi implantado dentro do contêiner do Docker. Em algum momento, surgiu a idéia de coletar toda a infraestrutura necessária (por exemplo, PostgreSQL e Tomcat) em um contêiner para instalar o aplicativo após o estágio de compilação e os autotestes. O contêiner de infraestrutura em si já foi construído com base na imagem do Debian com Systemd e funcionou perfeitamente. Mas quando usado dentro do Runner, problemas inesperados começaram. O código da etapa foi, por simplicidade, digamos o seguinte:

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

Tudo parece estar normal, mas na inicialização, a etapa falhará com um erro de que o systemd não está sendo executado como um processo com o ID 1 ou talvez outro erro seja que o systemd não está sendo executado.

Qual seria o problema?

Como se viu - em uma nova questão no Gitlab, eu não fui o único a encontrar esse problema.
O problema é que o Gitlab Runner para o contêiner do Docker sempre substitui o comando CMD, ou seja, inicia o contêiner com este comando:

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

E é impossível redefinir o CMD do Gitlab, você só pode usar o ponto de entrada dentro do script ci, mas dançar com ele não levou a nada.

Todas as funções foram cobertas pelos testes de moléculas e foram aprovadas com sucesso dentro do corredor GitLab. Tendo prestado atenção nisso, pensei: por que não lançar o contêiner com systemd dentro do Runner, g * mor lançado, é claro, mas o resultado foi mais importante para mim do que as dificuldades. É possível simplesmente iniciar um contêiner usando comandos do docker, mas não é eficaz, e não haverá nenhum tratamento de erros - de alguma forma pode não ser muito previsível, então decidi escrever um pequeno artigo feito à mão em Python que iria apenas lançar o contêiner, copiar o arquivo com o necessário arquivos e execute uma lista de comandos dentro do contêiner.

→ O código está aqui: GitHub

Você pode executá-lo assim:

 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" #       

Os comandos em [] são opcionais. Uma macro {bash} especial é necessária para comandos que requerem um shell, por exemplo, ls -la e outros, que será substituída por / bin / bash -c "command" em tempo de execução.

Eu escrevi em Python pela primeira vez, então não repreenda. Talvez haja problemas no código ou na inicialização, tentarei corrigi-lo rapidamente. Aqui, tentei explicar a idéia simples geral de um método de inicialização. Compartilhe suas experiências se você tiver problemas semelhantes.

Sobre a imagem usada por dramaturg / docker-debian-systemd
Não há reclamações sobre esta imagem, mas a princípio ocorreu um erro que apareceu no console da máquina host, de que alguns dos arquivos criados pelo systemd já existem. Não havia esse problema no serviço Nginx, mas eles apareceram no PostgreSQL. A solução foi excluir o bloco "VOLUME [" / sys / fs / cgroup "," / run "," / run / lock "," / tmp "]", depois tudo funcionou como um relógio.

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


All Articles