☰

proxy reverso nginx para php-fpm

tag-icon • tag-icon php nginx docker reverse-proxy
proxy reverso nginx para php-fpm

Estou tendo alguns problemas conceituais com uma configuração Nginx. Começando com um nginxproxy reverso com terminação SSL, uso uma docker-compose.ymlconfiguração com alguns contêineres, cada um fornecendo um serviço virtual. Esses serviços são fornecidos como subdiretórios sob um único nome de host:

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

Trechos 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

Achei que haveria ganho de eficiência executando uma única instância nginxe usando php-fpmem cada um dos contêineres.

EUpensarque a premissa php-fpmseja tal que os contêineres não necessitem de nginxprocessos próprios; os nginxprocessos 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 base nginxe php-fpmarquitetura está correta?Alternativamente, uma infra-estrutura nginx/ php-fpminfraestrutura adequada deve ser usada php-fpmem conjunto direto (mesmo host e sistema de arquivos) ou é razoável e eficiente multi-hospedagem/multi-sistema de arquivos?

(Recentemente, entrei em contato para contratar ajuda, e a primeira resposta foi "você precisa executar nginxem cada contêiner", o que não fazia sentido para meu entendimento php-fpm.)

(Há muitas perguntas aqui que fazem nginx.confperguntas específicas, não sobre esta arquitetura reconhecidamente de nível superior.)

Responder1

Esta é uma resposta fraca, mas acredito:

Sim, esta é em geral a filosofia correta, mas com algumas ressalvas. php-fpmexiste para processar .phparquivos, mas acho que não para servir todos os arquivos (não-php). Para isso, o processo frontal nginxprecisa ver todos os arquivos, mesmo que não faça o processamento real do PHP.

Para que isso aconteça de forma inteligente usando o docker, os arquivos no php-fpmcontêiner precisam ser compartilhados explicitamente com o nginxcontêiner. A maneira preferida de fazer isso no docker é fornecer um volume nomeado e usá-lo para ambos os contêineres. Por exemplo, um docker-compose.ymlarquivo:

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 estar vazios quando você inicia o script e irão ser preenchido por um dos recipientes. (Na verdade, pode ser preenchido por ambos ou por nenhum, dependendo de vários fatores.)

Um efeito colateral disso é que os volumespersistir.

  • “Isto é bom” para a eficiência, na medida em que não é recriado desnecessariamente.
  • “Isso é ruim” porque um benefício de ter serviços virtualizados é que você pode reiniciá-los e ter a garantia de uma lousa limpa. Com volumes nomeados persistentes, você não obtém (automaticamente) uma lista limpa, pois os arquivos usados ​​na instância anterior serão usados ​​em vez da versão austera em uma camada fs inferior.

A maneira de contornar esse "ruim" é liberar os volumes manualmente. Isso pode ser feito no desligamento com docker-compose down -v, que de acordo com a ajuda:

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

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 ou nomeados ou qualquer outro).

informação relacionada