☰

nginx 역방향 프록시에서 php-fpm으로

tag-icon • tag-icon php nginx docker reverse-proxy
nginx 역방향 프록시에서 php-fpm으로

Nginx 구성에 개념적으로 문제가 있습니다. SSL 종료자 역방향 프록시 로 시작하여 각각 가상 서비스를 제공하는 몇 개의 컨테이너가 있는 설정을 nginx사용합니다 . docker-compose.yml이러한 서비스는 단일 호스트 이름 아래 하위 디렉터리로 제공됩니다.

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

프로세스 목록 조각:

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

nginx의 단일 인스턴스를 실행 하고 php-fpm각 컨테이너에서 사용 하면 효율성이 향상될 것이라고 생각했습니다 .

나생각하다php-fpm컨테이너에 자체 프로세스가 필요하지 않다는 전제가 있습니다 nginx. 프로세스 nginx는 포트 9000을 통해 각 컨테이너와 통신합니다(네트워크 부분이 작동함). 하지만 실제로는 문제가 있으므로 전제가 올바른지 확인해야 합니다.

기본 nginx및 php-fpm아키텍처에 대한 이러한 가정이 올바른가요?또는 적절한 nginx/ php-fpm인프라가 직접 콘서트(동일한 호스트 및 파일 시스템)로 사용하도록 의도되었거나 php-fpm다중 호스팅/다중 파일 시스템이 합리적이고 효율적입니까?

(최근에 도움을 받기 위해 연락했는데 첫 번째 응답은 " nginx각 컨테이너에서 실행해야 합니다"였습니다. 이는 제가 이해한 php-fpm.

nginx.conf( 이러한 상위 수준 아키텍처에 관한 것이 아니라 특정 질문을 묻는 질문이 여기에 많이 있습니다 .)

답변1

이것은 약한 대답이지만 나는 다음과 같이 믿습니다.

예, 이는 일반적으로 올바른 철학이지만 몇 가지 주의사항이 있습니다. 파일을 php-fpm처리하기 위해 존재 .php하지만 모든 (PHP가 아닌) 파일을 제공하는 것은 아니라고 생각합니다. 이를 위해 전면 nginx프로세스는 실제 PHP 처리를 수행하지 않더라도 모든 파일을 확인해야 합니다.

docker를 사용하여 이를 스마트하게 수행하려면 컨테이너의 파일을 컨테이너 php-fpm와 명시적으로 공유해야 합니다 nginx. Docker에서 이를 수행하는 가장 좋은 방법은 명명된 볼륨을 제공하고 이를 두 컨테이너 모두에 사용하는 것입니다. 예를 들어 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:

(많은 필드가 포함되지 않습니다 ...) 끝에 나열된 두 볼륨은 docker가 말하는 "이름이 지정된 볼륨"이며 이유 때문에 비어 있습니다. 스크립트를 시작할 때 비어 있도록 의도되었으며 용기 중 하나로 채워집니다. (실제로는 여러 요인에 따라 둘 다 채워질 수도 있고 둘 다 채워지지 않을 수도 있습니다.)

이것의 한 가지 부작용은 볼륨이지속하다.

  • 불필요하게 재생성되지 않는다는 점에서 효율성 측면에서 "이것은 좋습니다".
  • "이것은 나쁘다". 왜냐하면 가상화된 서비스의 이점 중 하나는 서비스를 다시 시작할 수 있고 깨끗한 상태를 보장받을 수 있다는 것이기 때문입니다. 영구 명명된 볼륨을 사용하면 이전 인스턴스에서 사용된 파일이 하위 fs 계층의 엄격한 버전 대신 사용되므로 (자동으로) 깨끗한 상태를 얻지 못합니다.

이 "불량"을 해결하는 방법은 볼륨을 수동으로 플러시하는 것입니다. 이 작업은 docker-compose down -v도움말에 따라 종료 시 수행할 수 있습니다 .

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

docker volume rm <volume-id>or를 사용하여 수동으로 수행할 수도 있습니다 docker volume prune(임시 볼륨이든 명명된 볼륨이든 현재 사용하지 않는 모든 볼륨을 제거함).

관련 정보