Servire contenuto statico usando docker + nginx + php-fpm


10

Sto cercando di configurare una webapp php usando la finestra mobile. L'idea è di eseguire l'app utilizzando php-fpmun contenitore autonomo e disporre di un altro contenitore che eseguirà nginx. L'idea per questa configurazione è quella di utilizzare lo stesso contenitore nginx per inoltrare richieste ad altre webapp che stanno già lavorando sullo stesso computer. Il problema è che non riesco nginxa elaborare correttamente i file statici (js, css, ecc.), Poiché le richieste a quelli continuano fpm.

Ecco come appare il filesystem:

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

Sto eseguendo il tutto usando un Makefileche assomiglia a questo (non interessato a docker-composequesto):

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

Ecco config/webapp.confcome appare il mio .

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;
    }
}

Qualsiasi azione che deve essere elaborata utilizzando quel index.phpfile funzionerà. Tuttavia, i file statici non verranno offerti, con conseguenti 404errori negativi (poiché la webapp php non ha percorsi configurati per quelli). Credo che nginx tenti di caricare quelli dal proprio filesystem contenitore, quando sono effettivamente nel webappcontenitore, fallendo nuovamente @webapp.

C'è un modo che posso configurare nginxper servire quei file che risiedono in un altro contenitore?


3
Stai usando la finestra mobile per isolare nginx dalle applicazioni php mentre richiedi che nginx abbia accesso ai file all'interno delle applicazioni php?
Stefan Schmiedl,

Non sono sicuro di aver capito il tuo commento ... Sto usando la finestra mobile per gestire la mia infrastruttura. Tuttavia, non sto creando nginxfile di richiesta all'interno dell'applicazione php, sto facendo il proxy fpmper farlo e ho bisogno nginxdi accedere a file statici non php.
ThisIsErico

I file "risiedono in un altro contenitore", cioè non dove nginx può vederli, giusto?
Stefan Schmiedl,

Esatto @Stefan, vengono montati solo come volumi nel webappcontenitore, non in nginxquello.
ThisIsErico,

Risposte:


1

Sono riuscito a risolvere il problema montando il webappvolume nel nginxcontenitore. Ecco run-nginxcome appare ora il lavoro:

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

E questo è il webapp.conffile, che tenterà di caricare i file statici dal contenitore e, se ciò non fosse possibile, proxy la richiesta al fpmlavoratore:

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;
    }
}

Tuttavia, vorrei sapere se esiste un modo migliore per farlo invece di condividere lo stesso volume due volte. Molte grazie!


4
Data la tua separazione di nginx e php in diversi contenitori, non credo. Hai bisogno dei dati in due posizioni diverse, devi fornirli due volte. Sono anche molto curioso se qualcuno ha un'idea migliore.
Stefan Schmiedl,

0

Forse questo potrebbe essere ottenuto utilizzando NFS

Un contenitore docker che esegue NFS potrebbe essere creato dove risiede il codice, che potrebbe essere collegato ai contenitori che eseguono nginx e php. I file sarebbero archiviati in un solo contenitore. Ciò potrebbe fornire anche un altro livello di isolamento.


0

Ho due opzioni suggerite: la prima è mettere le tue risorse statiche in eg / static e dare istruzioni a nginx di chiamare un servizio di backend diverso per quelle. passi:

1) Aggiorna i tuoi siti Web in modo che puntino a / static / * per qualsiasi risorsa statica, quindi ad esempio /styles.css diventa /static/styles.css

2) Metti le tue risorse in un contenitore separato servito da forse un altro nginx (così puoi riutilizzare il contenitore per diversi siti)

3) Modifica nginx.conf per inviare tutte le richieste a / static / * al nuovo contenitore:

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

La seconda opzione è semplicemente spostare le risorse statiche in una rete CDN, quindi è sufficiente aggiornare il sito Web per caricare ciascuna risorsa statica da un URL esterno ( https: //cdnwebsite/asdsadasda/styles.css anziché /styles.css o /static/styles.css)

La seconda opzione presenta numerosi vantaggi rispetto alle altre, principalmente in termini di prestazioni. Un CDN servirà quelli più veloci e stai anche lavorando intorno al limite di connessione simultanea che un browser può stabilire per ogni FQDN, quindi la tua pagina potrebbe caricarsi più velocemente a causa di più connessioni simultanee utilizzate per caricare il tuo sito.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.