Docker + nginx + php-fpm का उपयोग करके स्थिर सामग्री परोसें

Question

मैं doer का उपयोग करके php webapp को कॉन्फ़िगर करने का प्रयास कर रहा हूँ। विचार php-fpmस्टैंडअलोन कंटेनर का उपयोग करके ऐप को चलाने का है और एक अन्य कंटेनर है जो नगनेक्स चलाएगा। इस सेटअप के लिए विचार यह है कि उसी नगनेक्स कंटेनर का उपयोग अन्य वेबएप्स के लिए प्रॉक्सी अनुरोधों के लिए किया जाए जो पहले से ही एक ही मशीन पर काम कर रहे हैं। समस्या यह है कि मैं nginxस्थिर फ़ाइलों (जेएस, सीएसएस, आदि) को ठीक से संसाधित करने के लिए नहीं मिल सकता हूं , क्योंकि उन लोगों के लिए अनुरोध जारी है 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 के पास वास्तव में उन लोगों के लिए कॉन्फ़िगर किए गए मार्ग नहीं हैं)। मेरा मानना ​​है कि नगनेक्स अपने खुद के कंटेनर फाइल सिस्टम से लोड करने की कोशिश करता है, जब वे वास्तव में webappकंटेनर में होते हैं, तो वापस असफल हो जाते हैं @webapp।

क्या कोई तरीका है कि मैं nginxउन फ़ाइलों की सेवा करने के लिए कॉन्फ़िगर कर सकता हूं जो दूसरे कंटेनर में रहते हैं?

Comments

क्या आप नैपकिन को php अनुप्रयोगों से अलग करने के लिए docker का उपयोग कर रहे हैं, जबकि आवश्यकता है कि nginx के पास php अनुप्रयोगों में फ़ाइलों तक पहुँच हो?

— स्टेफन श्मिडल

मुझे यकीन नहीं है कि मैं आपकी टिप्पणी को समझ पा रहा हूं ... मैं अपने बुनियादी ढांचे के प्रबंधन के लिए डॉक का उपयोग कर रहा हूं। हालाँकि, मैं nginxphp एप्लिकेशन के भीतर अनुरोध फ़ाइलें नहीं बना रहा हूँ, मैं fpmऐसा करने के लिए आसन्न हूँ और मुझे nginxस्थिर गैर-php फ़ाइलों तक पहुँचने की आवश्यकता है।

— ThisIsErico

फाइलें "दूसरे कंटेनर में रहती हैं", न कि नगेंक्स उन्हें देख सकता है, है ना?

— स्टीफन श्मिटेड

यह सही @Stefan है, वे केवल webappकंटेनर में वॉल्यूम के रूप में घुड़सवार होते हैं, nginxएक में नहीं ।

— ThisIsErico

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

हालाँकि, मैं जानना चाहूंगा कि क्या एक ही वॉल्यूम को दो बार साझा करने के बजाय ऐसा करने का बेहतर तरीका है। आपका बहुत बहुत धन्यवाद!

Comments

नगीनेक्स और php को अलग-अलग कंटेनरों में रखने के कारण, मुझे ऐसा नहीं लगता। आपको दो अलग-अलग स्थानों में डेटा की आवश्यकता है, आपको इसे दो बार प्रदान करना होगा। मैं बहुत उत्सुक हूं, अगर कोई बेहतर विचार के साथ आता है।

— स्टीफन श्मिटेड

Answer 2

हो सकता है कि यह NFS का उपयोग करके हासिल किया जा सके

एनएफएस को चलाने वाला एक डॉकटर कंटेनर बनाया जा सकता है जहां कोड रहता है, जिसे नंगेक्स और पीएचपी चलाने वाले कंटेनरों से जोड़ा जा सकता है। फ़ाइलों को केवल एक कंटेनर में संग्रहीत किया जाएगा। यह अलगाव की एक और परत भी प्रदान कर सकता है।

Answer 3

मेरे पास दो सुझाए गए विकल्प हैं: पहला यह है कि अपनी स्थैतिक संपत्ति को जैसे / स्थैतिक में रखें और उन लोगों के लिए एक अलग बैकेंड सेवा को कॉल करने के लिए nginx को निर्देश दें। कदम:

1) किसी स्थिर संपत्ति के लिए / स्थिर / * को इंगित करने के लिए अपनी वेबसाइटों को अपडेट करें, इसलिए जैसे /styles.css /static/styles.css बन जाता है

2) अपनी संपत्ति को या तो किसी अन्य नग्नेक्स द्वारा परोसे गए एक अलग कंटेनर में रखें (ताकि आप कई साइटों के लिए कंटेनर का पुन: उपयोग कर सकें)

3) नए कंटेनर में / स्थिर / * के लिए सभी अनुरोध भेजने के लिए nginx.conf को संपादित करें:

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

दूसरा विकल्प यह है कि आप अपनी स्थैतिक संपत्ति को एक सीडीएन में ले जाएं, इसलिए आपको बस अपनी वेबसाइट को अपडेट करने की जरूरत है ताकि बाहरी यूआरएल ( https: //cdnwebsite/asdsadasda/styles.css) के बजाय / styles या .ss से प्रत्येक स्थिर संपत्ति को लोड किया जा सके। /static/styles.css)

दूसरे विकल्प में दूसरों के ऊपर कई फायदे हैं, मुख्य रूप से प्रदर्शन के आसपास। एक सीडीएन उन तेजी से काम करेगा और आप एक साथ कनेक्शन सीमा के आसपास भी काम कर रहे हैं जो एक ब्राउज़र प्रत्येक FQDN के लिए कर सकता है, इसलिए आपके साइट को लोड करने के लिए उपयोग किए जाने वाले अधिक कनेक्शन के कारण आपका पृष्ठ तेजी से लोड हो सकता है।