Docker: Executa Cronjob para contêineres diferentes

Question

Estou procurando as práticas recomendadas sobre a execução de cronjobs para meu contêiner php fpm.

Agora mesmo:

• Contêiner NGINX
• Contêiner FPM do PHP
• Contêiner do MySQL

Eu adoraria ter outro Container em execução chamado "Cronjob Container", que é um script dentro do meu contêiner PHP FPM (eu preciso de algumas dependências do PHP).

Então, três soluções possíveis:

1.) Executando um próprio container

Eu adoraria usar essa solução!

Seria bom ter um contêiner executando o CRON, onde eu posso (de alguma forma) chamar o docker exec no meu contêiner php fpm ... Ou ter outro jeito.

2.) Executando o CRON dentro do container PHP

Isso seria bom, mas não é uma prática recomendada. Eu poderia iniciar um segundo processo dentro do meu contêiner php fpm executando cron. Isso funcionaria, mas não tenho certeza se isso é com quem você deve trabalhar com o docker.

3.) Execução de Hosts Cron

Isso seria cruel. Eu precisaria encontrar o processID e containerID de um determinado caminho e, em seguida, executar o docker exec. Mas isso é mais ou menos o meu último caminho ... E eu odeio gerenciar cronjobs sem implantação.

Então, qual é a melhor abordagem aqui?

Tenha um bom dia,

Bastian

    

Answer 1

Eu escrevi um daemon que observa contêineres e trabalhos de agendas, definidos em seus metadados, neles. Isso é o mais próximo da sua 1) solução. Exemplo:

version: '2'

services:
  wordpress:
    image: wordpress
  mysql:
    image: mariadb
    volumes:
      - ./database_dumps:/dumps
    labels:
      deck-chores.dump.command: sh -c "mysqldump --all-databases > /dumps/dump-$$(date -Idate)"
      deck-chores.dump.interval: daily

Configuração 'clássica', semelhante ao cron, também é possível.

Aqui estão os documentos , aqui está o repositório de imagens .

    

Answer 2

O próprio Cron pode ser instalado e executado em primeiro plano ( cron -f ), facilitando a instalação em um contêiner. Para acessar outros contêineres, você provavelmente instalaria o docker no mesmo contêiner para o cliente CLI (para não executar o daemon). Em seguida, para acessar o ambiente do docker do host, a solução mais comum é vincular a montagem do soquete do docker ( -v /var/run/docker.sock:/var/run/docker.sock ). A única pegadinha é que você precisa configurar o docker gid dentro de seu contêiner para corresponder ao host gid e, em seguida, adicionar usuários dentro do contêiner ao grupo de encaixe.

Isso significa que esses usuários têm o mesmo acesso de qualquer usuário da janela de encaixe no host, por exemplo, acesso ao nível de raiz, portanto, você precisa confiar totalmente no usuário que os envia ou limitar os comandos que podem ser executados com algum tipo de sudo equivalente. A outra desvantagem é que isso é menos portável, e é pouco provável que os administradores com conhecimento de segurança aprovem a execução de seus contêineres em seus sistemas.

O retorno para a opção B é muito fácil com uma ferramenta como o supervisord. Embora seja menos do que o ideal "um processo por contêiner", não é exatamente um antipadrão, pois mantém todo o contêiner e as dependências juntos e remove quaisquer riscos de segurança para o host.

Se você escolher a primeira ou a segunda opção, o ambiente, quem está enviando os trabalhos, quantos contêineres precisam ter trabalhos enviados, etc. Se for um administrador enviando trabalhos contra vários contêineres, então um O contêiner cron faz sentido. Mas se você for o desenvolvedor de aplicativos que precisa incluir um trabalho agendado com seu aplicativo como um pacote, vá para a segunda opção.

    

Answer 3

Execute o cron em outro container ou mesmo no host, mas execute o script via php-fpm (por exemplo, o cron "curl" ou algo do script PHP).

Certifique-se de proteger tal configuração com um token de segurança, limitações de rede, etc. Um aprimoramento poderia ser ter um conjunto separado de php-fpm com processos dinâmicos que é capaz de gerar no máximo um processo. Este pool só seria acessível pelo cron. Ele também pode se beneficiar de suas próprias configurações individuais, como um tempo de execução maior, mais ou menos memória, etc.

PS: Você pode usar algo como este para chamar o script diretamente no contêiner do FPM e não passar pelo nginx.

Raciocínio: Você provavelmente deseja acessar as mesmas bibliotecas, a mesma configuração, etc. Executar um processo gerado aleatoriamente e não controlado por um gerenciador de sinais no Docker é uma péssima idéia.