Como executar vários serviços em um contêiner do Docker

Docker é uma tecnologia para empacotar componentes de sua pilha como contêineres isolados. É uma prática comum executar cada um de seus processos em seu próprio contêiner, criando uma divisão clara entre os componentes. Isso aprimora a modularidade e permite acessar os benefícios de escalabilidade da conteinerização.

Ainda pode haver situações em que você deseja executar vários serviços em um único contêiner. Embora isso não ocorra naturalmente no ecossistema do Docker, mostraremos algumas abordagens diferentes que você pode usar para criar contêineres com mais de um processo de longa duração.

Identificando o problema

Os contêineres do Docker executam um único processo em primeiro plano. Isso é definido pelas instruções ENTRYPOINT e CMD da imagem. ENTRYPOINT é definido no Dockerfile de uma imagem, enquanto o CMD pode ser substituído ao criar contêineres. Os contêineres param automaticamente quando o processo em primeiro plano é encerrado.

Você pode iniciar outros processos a partir do CMD , mas o contêiner só permanecerá em execução enquanto o processo original em primeiro plano estiver ativo. Manter o contêiner operacional durante a vida útil combinada de dois serviços independentes não é diretamente possível usando o mecanismo ENTRYPOINT/CMD .

Envolvendo vários processos em um ponto de entrada

Os scripts wrapper são a solução mais simples para o problema. Você pode escrever um script que inicia todos os seus processos e espera que eles terminem. Definir o script como seu Docker ENTRYPOINT o executará como o processo em primeiro plano do contêiner, mantendo o contêiner em execução até que um dos scripts encapsulados seja encerrado.

 #!/bin/bash

/opt/primeiro processo &

/opt/segundo processo &

espere -n

sair $?

Este script inicia os binários /opt/first-process e /opt/second-process dentro do contêiner. O uso de & permite que o script continue sem esperar a saída de cada processo. wait é usado para suspender o script até que um dos processos termine. O script sai com o código de status emitido pelo script finalizado.

Esse modelo resulta no contêiner executando o first-process e second-process até que um deles saia. Nesse ponto, o contêiner será interrompido, mesmo que o outro processo ainda esteja em execução.

Para usar este script, modifique o ENTRYPOINT e o CMD da sua imagem do Docker para torná-lo o processo de primeiro plano do contêiner:

 PONTO DE ENTRADA ["/bin/sh"]
CMD [./path/to/script.sh"]

A opção de contêiner --init

Um desafio com o gerenciamento de processos de contêiner é a limpeza eficaz à medida que eles saem. O Docker executa seu CMD como ID de processo 1, tornando-o responsável por lidar com sinais e eliminar zumbis. Se seu script não tiver esses recursos, você poderá acabar com processos filho órfãos persistindo dentro de seu contêiner.

O comando docker run tem um sinalizador --init que modifica o ponto de entrada para usar tini como PID 1. Esta é uma implementação mínima do processo de inicialização que executa seu CMD , manipula o encaminhamento de sinal e colhe zumbis continuamente.

Vale a pena usar --init se você espera gerar muitos processos e não deseja lidar manualmente com a limpeza. Tini é um sabor de inicialização leve projetado para contêineres. É muito menor do que alternativas completas como systemd e upstart .

Usando um gerenciador de processos dedicado

O script manual torna-se rapidamente abaixo do ideal quando você tem muitos processos para gerenciar. Adotar um gerenciador de processos é outra maneira de executar vários serviços dentro de seus contêineres do Docker. O gerente de processo se torna seu ENTRYPOINT e tem a responsabilidade de iniciar, manter e limpar após seus processos de trabalho.

Existem várias opções disponíveis ao implementar essa abordagem. supervisord é uma escolha popular que é facilmente configurada através de um arquivo /etc/supervisor/conf.d/supervisord.conf :

 [programa:apache2]
comando=/usr/sbin/apache2 -DFOREGROUND

[programa:mysqld]
comando=/usr/sbin/mysqld_safe

Este arquivo de configuração configura o supervisord para iniciar o Apache e o MySQL. Para usá-lo em um contêiner do Docker, adicione todos os pacotes necessários à sua imagem e copie o arquivo de configuração do supervisord para o local correto. Defina supervisord como o CMD da imagem para executá-lo automaticamente quando os contêineres forem iniciados.

 DO Ubuntu: mais recente
RUN apt-get install -y apache2 mysql-server supervisor
COPIAR supervisord.conf /etc/supervisor/conf.d/supervisord.conf
PONTO DE ENTRADA ["/bin/sh"]
CMD ["/usr/bin/supervisord"]

Como o supervisord é executado continuamente, não é possível interromper o contêiner quando um dos processos monitorados é encerrado. Uma opção alternativa é s6-overlay , que possui esse recurso. Ele usa um modelo de serviço declarativo onde você coloca scripts de serviço diretamente em /etc/services.d :

 # Adicione s6-overlay à sua imagem
ADICIONE https://github.com/just-containers/s6-overlay/releases/download/v3.1.0.0/s6-overlay-noarch.tar.xz/tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz

RUN printf "#!/bin/shn/usr/sbin/apache2 -DFOREGROUND" > /etc/services.d/first-service/run
RUN chmod +x /etc/services.d/first-service/run

# Use s6-overlay como ponto de entrada da sua imagem
PONTO DE ENTRADA ["/init"]

Você pode adicionar um script de finish executável em seus diretórios de serviço para lidar com a interrupção do contêiner com docker stop . s6-overlay executará automaticamente esses scripts quando seu processo receber um sinal TERM devido ao comando stop .

Os scripts de finalização recebem o código de saída de seu serviço como primeiro argumento. O código é definido como 256 quando o serviço é encerrado devido a um sinal não capturado. O script precisa escrever o código de saída final em /run/s6-linux-init-container-results/exitcode ; s6-overlay lê esse arquivo e sai com o valor dentro dele, fazendo com que esse código seja usado como código de parada do seu contêiner.

 #!/bin/sh
echo "$1" > /run/s6-linux-init-container-results/exitcode

Quando você deve executar vários processos em um contêiner?

Essa técnica é melhor usada com processos fortemente acoplados que não podem ser separados para serem executados como contêineres independentes. Você pode ter um programa que depende de um utilitário auxiliar em segundo plano ou um aplicativo monolítico que executa seu próprio gerenciamento de processos individuais. As técnicas mostradas acima podem ajudá-lo a contentorizar esses tipos de software.

A execução de vários processos em um contêiner ainda deve ser evitada sempre que possível. Aderir a um único processo em primeiro plano maximiza o isolamento, evita que os componentes interfiram uns com os outros e melhora sua capacidade de depurar e testar peças específicas. Você pode dimensionar componentes individualmente usando orquestradores de contêiner, oferecendo a flexibilidade de executar mais instâncias de seus processos com uso intensivo de recursos.

Conclusão

Os contêineres geralmente têm um processo em primeiro plano e são executados enquanto estiverem ativos. Esse modelo se alinha às práticas recomendadas de conteinerização e permite que você obtenha o máximo de benefícios da tecnologia.

Em algumas situações, você pode precisar que vários processos sejam executados em um contêiner. Como todas as imagens têm um único ponto de entrada, você deve escrever um script wrapper ou adicionar um gerenciador de processos que assuma a responsabilidade de iniciar seus binários de destino.

Os gerenciadores de processos oferecem tudo o que você precisa, mas sobrecarregam suas imagens com pacotes e configurações extras. Os scripts wrapper são mais simples, mas podem precisar ser combinados com o sinalizador --init do Docker para evitar a proliferação de processos zumbis.