Django/PHP के साथ Apache

यह आखिरी lesson course को दो complete, realistic setups से जोड़ता है: एक PHP application सीधे serve करना, और Gunicorn के पीछे चल रही एक Django application को reverse-proxy करना।

In this page:

PHP-FPM (mod_proxy_fcgi) के जरिए PHP
एक Complete PHP VirtualHost
Gunicorn को एक Reverse Proxy के जरिए Django
दोनों तरह से Static Files सीधे Serve करना

PHP-FPM (mod_proxy_fcgi) के जरिए PHP

Apache के under PHP चलाने का modern तरीका PHP-FPM को अपना अलग process pool की तरह चलाता है और Apache को mod_proxy_fcgi से इससे connect करता है, पुराने mod_php से PHP को सीधे Apache में embed करने की बजाय। इसे sudo a2enmod proxy_fcgi setenvif plus PHP का अपना FPM Apache config (अक्सर distro के libapache2-mod-fcgid/php-fpm packages से already मिल जाता है) से enable करें, फिर .php files की requests को FPM socket पर point करें।

एक Complete PHP VirtualHost

DocumentRoot हमेशा की तरह PHP application के public folder पर point करता है। एक <FilesMatch \.php$> block .php file की किसी भी request को SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost" के जरिए FPM socket को सौंप देता है (socket path/PHP version को installed चीज़ से match करते हुए) -- Apache फिर भी application के static assets (CSS, JS, images) खुद सीधे serve करता है, सिर्फ .php requests को FPM को सौंपते हुए।

Gunicorn को एक Reverse Proxy के जरिए Django

Django Apache के अंदर उस तरह नहीं चलता जैसे PHP चल सकता है -- यह अपना खुद का Python process चलाता है, आमतौर पर Gunicorn से managed और systemd से started/kept alive। Apache का काम बस वही है जो Reverse Proxy lesson में covered था: सब कुछ Gunicorn के address पर ProxyPass/ProxyPassReverse करना (आमतौर पर एक Unix socket या 127.0.0.1:8000), जबकि Django की collected static और media files खुद सीधे एक Alias से serve करना, क्योंकि Django का अपना development server production में उन्हें serve करने के लिए नहीं बना।

दोनों तरह से Static Files सीधे Serve करना

PHP और Django दोनों के लिए, same principle apply होता है: static files (CSS, JS, images) को एक Alias और <Directory> block से disk से सीधे Apache को serve करने दें, और सिर्फ dynamic requests को PHP-FPM या Gunicorn को सौंपें। बिना बदले disk से पढ़ने के लिए इसे application layer से route करने से Apache एक static file को serve करने में काफी ज़्यादा efficient है।

Note: आप कोई भी backend चला रहे हों, pattern same रखें: Apache static files सीधे serve करता है, और सिर्फ उन requests को proxy (या FPM से हैंडऑफ) करता है जिन्हें actually application code चलाने की ज़रूरत है।

उदाहरण: PHP-FPM and Django/Gunicorn VirtualHosts side by side

apacheconf

# PHP application via PHP-FPM
<VirtualHost *:80>
    ServerName php-app.example.com
    DocumentRoot /var/www/php-app/public

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

# Django application via Gunicorn
<VirtualHost *:80>
    ServerName django-app.example.com

    Alias /static/ /var/www/django-app/static/
    <Directory /var/www/django-app/static>
        Require all granted
    </Directory>

    ProxyPreserveHost On
    ProxyPass /static/ !
    ProxyPass "/" "http://127.0.0.1:8000/"
    ProxyPassReverse "/" "http://127.0.0.1:8000/"
</VirtualHost>

{# Flagged by hand after confirming a runner can't handle this example (a shell command / go.mod file stored as a TopicExample, a language feature the configured runner version doesn't support, or output that blows a runner's sandbox limit) -- see TopicExample.norun. Never render the run button for these, regardless of language, since it would just fail at execute_code (or worse, hang the Judge0 queue on a submission that can never finish cleanly). #}

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}

आम गलतियां

static files समेत हर request को Gunicorn/PHP-FPM को proxy करना, जब Apache का इन्हें सीधे serve करना simpler और काफी तेज़ दोनों है।
SetHandler directive में PHP-FPM socket path या PHP version को actually installed चीज़ से mismatch करना, हर .php request के लिए एक 502/503 error produce करते हुए।
production में Gunicorn जैसे असली WSGI server की बजाय Apache के पीछे Django का manage.py runserver चलाना -- development server उसके लिए designed या hardened नहीं है।

चैप्टर सारांश

एक reverse proxy Apache को एक या ज़्यादा backend application servers के लिए single public-facing entry point बनने देता है, TLS/static files/logging handle करते हुए dynamic requests को आगे forward करते हुए -- और load balancing same idea को कई backend instances में extend करता है।
Practice में URL rewriting ज़्यादातर तीन ज़रूरतें serve करता है -- एक framework के front controller में clean URLs, एक पुरानी site के URLs को उनकी नई locations पर redirect करना, और एक canonical domain/protocol enforce करना -- और असली PHP और Django deployments इस course की हर चीज़ combine करती हैं: VirtualHosts, TLS, proxying, और static assets को सीधे serve करना।

🔒

Chapter Quiz — Complete all 4 topics to unlock

0/4 topics done

Complete these topics first:

← Previous Lesson URL Rewriting