Comecei a trabalhar com o Docker e o Kubernetes e observei várias pilhas, nas quais algumas pessoas criam nginx + php em uma única imagem e outras criam uma imagem com nginx e outra com php (montando o mesmo caminho e fechando ambos os contêineres na mesma implantação no Kubernetes).
Quais seriam as vantagens de criar duas imagens de janela de encaixe em vez de instalar o nginx + php na mesma?
Respostas:
PHP com nginx geralmente é feito usando php-fpm, que é um processo separado.
Mantendo a idéia central do docker de um processo (consulte o final da resposta para obter mais detalhes sobre este ponto) por contêiner, faz sentido ter o processo nginx e o processo php-fpm em contêineres separados.
Como a comunicação entre nginx e php-fpm surge através do fastcgi, o contêiner php-fpm também pode estar em um host separado e isso permite o uso de um cluster de contêineres php-fpm atrás do nginx.
Após a parede de comentários, veja um pouco mais sobre o histórico, a documentação do docker possui um parágrafo sobre a ideia de que um contêiner deve ter apenas uma preocupação .
A idéia principal de um contêiner linux ( lxc ) é executar um processo em um espaço para nome isolado no nível da CPU e da memória, e o docker adiciona um isolamento no nível do sistema de arquivos.
A vantagem é que o comprometimento de um processo dentro desse espaço para nome não permitirá a leitura de memória de outros processos e, como tal, deve evitar outro comprometimento no host.
Enquanto falam sobre nginx e php-fpm, eles funcionam em pares, mas cada um tem sua própria preocupação, o nginx fará a parte HTTP, o roteamento, a validação de cabeçalhos etc. e o php-fpm fará a interpretação do código e retornará a parte html ao nginx . Embora seja comum ter os dois juntos servindo um único aplicativo que não é obrigatório.
Dependendo do contexto, pode ser mais fácil ter um contêiner, incluindo toda a pilha para um aplicativo, em uma estação de trabalho do desenvolvedor, por exemplo. Mas, idealmente, para uso em produção, tente manter a menor interação dentro do contêiner, pois processos separados no mesmo contêiner com supervisord trazem sua parte do problema em termos de processo zumbi e manipulação de logs (exemplo de história aqui apenas para fins ilustrativos).
Então, finalmente, citarei a página de encaixe com alguma ênfase:
Embora “um processo por contêiner” seja frequentemente uma boa regra geral, não é uma regra rígida e rápida. Use seu bom senso para manter os contêineres o mais limpos e modulares possível .
Não existe uma "regra de bala de prata" que se aplique a tudo; é sempre um equilíbrio entre a complexidade dentro do contêiner e a complexidade que orquestra os próprios contêineres.
Na verdade, um ponto que falta aqui é a escalabilidade horizontal. Há um artigo de Jamie Alquiza há muito tempo abordado isso:
Em resumo, você dimensiona seu php-fpm horizontalmente para alcançar um desempenho mais alto. Escalar o Nginx + php-fpm juntos não traz nenhum benefício. Convido você a fazer alguns testes de estresse (por exemplo, Tsung, Gatling, etc .; por favor, não faça o Apache ab, que é um brinquedo muito antigo) para verificar o que o artigo dizia. Pessoalmente, tenho várias experiências no mundo real provadas que o artigo é verdadeiro em geral.
Mas existem duas desvantagens (talvez não para o Kubernetes) para máquinas / VMs bare metal:
EDITADO: Agora é quase metade do ano de 2019. O modelo antigo, php-fpm + nginx no mesmo pod, tem uso diferente. Se você está familiarizado com a malha de serviço, o nginx (ou o que chamamos de Nginmesh) serve como um carro lateral para lidar com o tráfego para o leste-oeste. O tráfego para leste-oeste costumava ser usado para autenticação entre serviços ou outras funcionalidades sofisticadas, enquanto o php-fpm puro não podia fazer isso junto.
Não há benefícios significativos que superem a necessidade de gerenciar dois contêineres. Desde que você tenha um relacionamento 1: 1 entre os processos e eles servem a um único propósito, coloque-os no mesmo contêiner.