nginx reverse-proxy para php-fpm

Question

Estou tendo algum problema conceitualmente com uma configuração Nginx. Começando com um proxy reverso nginx SSL-terminator, eu uso uma configuração docker-compose.yml com alguns contêineres, cada um fornecendo um serviço virtual. Esses serviços são fornecidos como subdiretórios em um único nome de host:

net --443--> nginx
             | | '--- ContainerA "https://example.com/serviceA/"
             | '----- ContainerB "https://example.com/serviceB/"
             '------- ContainerC "https://example.com/serviceC/"

Snippets de listas de processos:

nginx:~$ ps fax
127285 ?        Ss     0:00  nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
127419 ?        S      0:00   \_ nginx: worker process
127420 ?        S      0:00   \_ nginx: worker process
127421 ?        S      0:00   \_ nginx: worker process

ContainerA:~$ ps fax
127132 ?        Ss     0:09  php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
234053 ?        S      8:27   \_ php-fpm: pool www
236952 ?        S      8:12   \_ php-fpm: pool www
259123 ?        S      6:42   \_ php-fpm: pool www

Eu pensei que haveria eficiência obtida executando uma única instância de nginx e usando php-fpm em cada um dos contêineres.

Eu acho que a premissa de php-fpm é tal que os contêineres não precisam de seus próprios nginx processos; os processos nginx se comunicam com cada contêiner pela porta 9000 (a parte da rede funciona). Na prática, porém, estou tendo problemas, então preciso verificar se minha premissa é correta:

Essa suposição de uma arquitetura básica nginx e php-fpm está correta? Como alternativa, é uma infraestrutura nginx / php-fpm adequada para usar php-fpm em show direto (mesmo host e sistema de arquivos) ou é multi-hosting / multi-filesystem razoável e eficiente?

(Eu recentemente estendi a mão para contratar alguma ajuda, e sua primeira resposta foi "você precisa executar nginx em cada contêiner", o que não fazia sentido para minha compreensão de php-fpm .)

(Há muitas perguntas aqui que pedem perguntas específicas de nginx.conf , não sobre essa arquitetura reconhecidamente de nível superior.)

    

Answer 1

Esta é uma resposta fraca, mas acredito:

Sim , esta é, em geral, a filosofia certa, mas com algumas ressalvas. php-fpm está lá para processar .php arquivos, mas acho que não para servir todos os arquivos (não-php). Para isso, o processo nginx da frente precisa ver todos os arquivos, mesmo que ele não faça o processamento real do PHP.

Para que isso ocorra de maneira inteligente usando o docker, os arquivos no contêiner php-fpm precisam ser compartilhados explicitamente com o contêiner nginx . A maneira preferida de fazer isso no docker é fornecer um volume nomeado e usá-lo para ambos os contêineres. Por exemplo, um arquivo docker-compose.yml :

version: '2'
services:
  serviceA:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolA:/path/to/serviceA
  serviceB:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolB:/path/to/serviceB
  nginx:
    image: ...
    volumes:
    - tmpvolA:/var/www/serviceA
    - tmpvolB:/var/www/serviceB
volumes:
  tmpvolA:
  tmpvolB:

(Muitos campos não estão incluídos ...) Os dois volumes listados no final são os "volumes nomeados" dos quais o docker fala e estão vazios por um motivo: eles devem ficar vazios quando você iniciar o script e será preenchido por um dos contêineres. (Na verdade, pode ser preenchido por ambos ou nenhum deles, dependendo de vários fatores.)

Um efeito colateral disso é que os volumes persistem .

• "Isso é bom" para eficiência, pois não é recriado desnecessariamente.
• "Isso é ruim" porque um dos benefícios de ter serviços virtualizados é que você pode reiniciá-lo e ter a garantia de que está tudo limpo. Com volumes nomeados persistentes, você não (automaticamente) obtém um slate limpo, pois os arquivos usados na instância anterior serão usados em vez da versão austera em uma camada fs inferior.

O caminho em torno deste "mau" é liberar os volumes manualmente. Isso pode ser feito no encerramento com docker-compose down -v , que por ajuda:

    -v, --volumes       Remove named volumes declared in the 'volumes' section
                        of the Compose file and anonymous volumes
                        attached to containers.

Isso também pode ser feito manualmente com docker volume rm <volume-id> ou docker volume prune (que remove todos os volumes não utilizados no momento, sejam temporários, nomeados ou qualquer outro).