docker + nginx + php-fpmを使用して静的コンテンツを提供する


10

dockerを使用してphp webappを構成しようとしています。アイデアはphp-fpm、スタンドアロンコンテナーでアプリを実行し、nginxを実行する別のコンテナーを用意することです。このセットアップのアイデアは、同じnginxコンテナを使用して、同じマシンですでに動作している他のウェブアプリにリクエストをプロキシすることです。問題は、nginx静的ファイル(js、cssなど)を適切に処理できないことfpmです。

ファイルシステムは次のようになります。

/
├── Makefile
├── config
│   └── webapp.config
└── webapp
    └── web
        ├── index.php
        └── static.js

私はMakefileこのように見えるものを使用してすべてを実行しています(これには興味がありませんdocker-compose):

PWD:=$(shell pwd)
CONFIG:='/config'
WEBAPP:='/webapp'

run: | run-network run-webapp run-nginx

run-network:
    docker network create internal-net

run-webapp:
    docker run --rm \
    --name=webapp \
    --net=internal-net \
    --volume=$(PWD)$(WEBAPP):/var/www/webapp:ro \
    -p 9000:9000 \
    php:5.6.22-fpm-alpine

run-nginx:
    docker run --rm \
    --name=nginx \
    --net=internal-net \
    --volume=$(PWD)$(CONFIG)/webapp.conf:/etc/nginx/conf.d/webapp.domain.com.conf:ro \
    -p 80:80 \
    nginx:1.11.0-alpine

これは私のconfig/webapp.confようです。

server {
    listen 80;
    server_name webapp.domain.com;

    # This is where the index.php file is located in the webapp container
    # This folder will contain an index.php file and some static files that should be accessed directly
    root /var/www/webapp/web;

    location / {
        try_files $uri $uri/ @webapp;
    }

    location @webapp {
        rewrite ^(.*)$ /index.php$1 last;
    }

    location ~ ^/index\.php(/|$) {
        include fastcgi_params;

        fastcgi_pass webapp:9000;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS off;
    }
}

そのindex.phpファイルを使用して処理する必要があるアクションはすべて機能します。ただし、静的ファイルは提供されないため、厄介な404エラーが発生します(php webappには実際にルートが構成されていないため)。nginxはそれらを実際のwebappコンテナー内にあるときに、独自のコンテナーファイルシステムからそれらをロードしようとし、に失敗すると考えています@webapp

nginx別のコンテナーにあるファイルを提供するように構成できる方法はありますか?


3
nginxがphpアプリケーション内のファイルにアクセスできることを要求しながら、Dockerを使用してnginxをphpアプリケーションから分離していますか?
Stefan Schmiedl

あなたのコメントを理解したかわかりません...インフラストラクチャの管理にdockerを使用しています。ただし、nginxphpアプリケーション内ではリクエストファイルを作成しfpmていません。そのためにプロキシを作成しており、nginxphp以外の静的ファイルにアクセスする必要があります。
ThisIsErico 2016年

ファイルは「別のコンテナにあります」、つまりnginxがそれらを見ることができる場所ではありませんよね?
Stefan Schmiedl 2016年

そうです、@ Stefan、それらはwebappコンテナーではなく、コンテナー内のボリュームとしてマウントされnginxます。
ThisIsErico 2016

回答:


1

webappボリュームをnginxコンテナにマウントすることで問題を解決することができました。これはrun-nginx今の仕事のようです:

run-nginx:
    docker run --rm \
    --name=nginx \
    --net=internal-net \
    --volume=$(PWD)$(CONFIG)/webapp.conf:/etc/nginx/conf.d/webapp.domain.com.conf:ro \
    --volume=$(PWD)$(WEBAPP)/web:/var/www/webapp/web:ro \
    -p 80:80 \
    nginx:1.11.0-alpine

そして、これはwebapp.confコンテナから静的ファイルをロードしようとするファイルであり、それが不可能な場合は、リクエストをfpmワーカーにプロキシします。

server {
    listen 80;
    server_name webapp.domain.com;

    root /var/www/webapp/web;

    location ~ \.(js|css|png) {
        try_files $uri $uri/;
    }

    location / {
        rewrite ^(.*)$ /index.php$1 last;
    }

    location ~ ^/index\.php(/|$) {
        include fastcgi_params;

        fastcgi_pass webapp:9000;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS off;
    }
}

ただし、同じボリュームを2回共有するよりも、もっと良い方法があるかどうか知りたいのですが。どうもありがとう!


4
nginxとphpを別のコンテナーに分離したことを考えると、そうは思いません。2つの異なる場所にデータが必要な場合は、2回提供する必要があります。誰かがもっと良いアイデアを思いついたら、私もとても興味があります。
Stefan Schmiedl

0

多分これはNFSを使用して達成できます

NFSを実行する1つのDockerコンテナーを、コードが存在する場所に作成できます。これは、nginxおよびphpを実行するコンテナーにリンクできます。ファイルは1つのコンテナーにのみ格納されます。これにより、別の分離層も提供されます。


0

私は2つの提案されたオプションがあります。最初のオプションは、静的アセットを/ staticに入れて、それらに対して別のバックエンドサービスを呼び出すようにnginxに指示することです。手順:

1)静的アセットの/ static / *を指すようにWebサイトを更新します。たとえば、/ styles.cssは/static/styles.cssになります。

2)アセットを別のnginxが提供する別のコンテナーに置く(コンテナーを複数のサイトで再利用できるようにする)

3)nginx.confを編集して、/ static / *へのすべてのリクエストを新しいコンテナに送信します。

location /static/ {
   proxy_pass http://static-container;
}

2番目のオプションは、静的アセットをCDNに移動するだけです。そのため、Webサイトを更新して、各静的アセットを外部URL(/styles.cssではなくhttps: //cdnwebsite/asdsadasda/styles.cssまたは/static/styles.css)

2番目のオプションには、主にパフォーマンスに関して、他のオプションよりもいくつかの利点があります。CDNはそれらをより速く提供し、ブラウザーが各FQDNに対して行うことができる同時接続制限にも取り組んでいるため、サイトのロードに使用される同時接続の数が増えるため、ページのロードが速くなる可能性があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.