Quais são as vantagens de dockerizing nginx e php em diferentes contêineres?

18

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?

CarlosAS
fonte

Respostas:

19

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.

Tensibai
fonte
3
A ideia principal é realmente "Cada contêiner deve ter apenas uma preocupação" e "não é necessariamente verdade que deve haver apenas um processo do sistema operacional por contêiner". docs.docker.com/engine/userguide/eng-image/…
user2640621
Eu admito que é um atalho para entender a idéia, o nginx não é um processo monolítico único nem é php-fpm, mas substitui o processo pela preocupação em minha resposta e ainda está tudo bem nginx faz o roteamento, php-fpm faz a interpretação
Tensibai
3
A resposta é geralmente um serviço, uma porta por contêiner, não realmente um processo. Por outro lado, se você possui vários processos em execução em um contêiner, é necessário considerar algum processo de inicialização, gerenciamento de serviços, reinicializações, log independente, dependências independentes de pacotes, isso fica um pouco mais complicado. E, às vezes, o mapeamento 1: 1 se transforma em mapeamento 1: n ao dimensionar.
Jiri Klouda
@Jiri brincando de advogado do diabo: então um apache na frente de um aplicativo de trilhos usando um banco de dados do postgres deve ir dentro do mesmo contêiner? Afinal, esse é apenas um serviço em um ponto de vista externo.
Tensibai
1
Resposta do @JiriKlouda alterada, espero que seja detalhada o suficiente para transmitir todos os pontos levantados nos comentários.
Tensibai 22/09
4

Na verdade, um ponto que falta aqui é a escalabilidade horizontal. Há um artigo de Jamie Alquiza há muito tempo abordado isso:

http://archive.is/pDzz0

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:

  1. Como configurar o Nginx descobrir dinamicamente as alterações do contêiner php-fpm? Esta é a parte fácil.
  2. Como compartilhamos o mesmo volume / sistema de arquivos após o dimensionamento? Os contêineres Nginx e php-fpm devem ler exatamente o mesmo conteúdo para obter consistência. Isso deixa para você a menor parte do quebra-cabeça (e a parte mais divertida) para trabalhar.

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.

Ming Hsieh
fonte
3

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.

user2640621
fonte
Você quer dizer imagens diferentes no mesmo contêiner?
CarlosAS
Como você iniciará o nginx e o php-fpm no mesmo contêiner? Por favor, adicione um exemplo.
030
1
@ 030 aqui um exemplo
CarlosAS
2
@carlos exemple muito válida para fins dev, eu bloquear este tipo de coisas para uso em produção (em execução supervisord dentro de um recipiente pode se transformar em um footgun com bastante facilidade)
Tensibai
Não concordo com essa resposta, com este raciocínio: um servidor apache com segurança mod conversando com um tomcat conversando com um servidor postgresql que hospeda apenas um aplicativo deve caber em um único contêiner.
Tensibai
-1

A vantagem é: você pode executar vários contêineres php-fpm no back-end, chamamos de cluster PHP, via número de portas. Porta de exemplo 9000, 9001, 9002 .. e assim por diante

Dylan B
fonte