چرا Django در Production با Development فرق دارد؟

اگر با Django کار کرده باشید، احتمالاً پروژه‌تان را در محیط توسعه با دستور زیر اجرا کرده‌اید:

python manage.py runserver

در این حالت همه‌چیز ساده است؛ سرور اجرا می‌شود، خطاها را به‌راحتی می‌بینید و می‌توانید سریع کدهای خود را تغییر دهید و نتیجه را بررسی کنید.

اما زمانی که همین پروژه را روی یک سرور واقعی قرار می‌دهید، شرایط متفاوت می‌شود. دیگر فقط اجرای Django کافی نیست و مواردی مثل امنیت، HTTPS، Web Server، Static Files، Database، Logging و مدیریت خطا اهمیت پیدا می‌کنند.

در این مقاله می‌خواهیم ببینیم چرا Django در محیط Development و Production به شکل متفاوتی اجرا می‌شود.

Development چیست؟

Development محیطی است که برنامه را در آن توسعه و آزمایش می‌کنیم. هدف اصلی در این محیط، سرعت و راحتی برنامه‌نویس است.

برای مثال:

python manage.py runserver

با اجرای این دستور، Django یک Development Server در اختیار ما قرار می‌دهد که معمولاً روی آدرس زیر اجرا می‌شود:

http://127.0.0.1:8000

در این محیط معمولاً DEBUG فعال است تا هنگام بروز خطا، اطلاعات کاملی درباره مشکل نمایش داده شود.

این رفتار برای برنامه‌نویس بسیار مفید است، اما برای یک سایت واقعی مناسب نیست.

Production چیست؟

Production محیطی است که کاربران واقعی از برنامه استفاده می‌کنند.

در این محیط دیگر هدف اصلی Debug کردن نیست، بلکه باید برنامه تا حد ممکن امن، پایدار و قابل اعتماد باشد.

به همین دلیل معماری یک پروژه Django در Production معمولاً با Development متفاوت است.

یک معماری رایج می‌تواند شامل این بخش‌ها باشد:

Nginx → Gunicorn → Django → Database

هر کدام از این بخش‌ها وظیفه مشخصی دارند و در ادامه آن‌ها را بررسی می‌کنیم.

چرا runserver برای Production مناسب نیست؟

یکی از اشتباهات رایج این است که تصور کنیم اگر Django را روی VPS اجرا کنیم، پروژه آماده Production است.

مثلاً ممکن است روی سرور این دستور را اجرا کنیم:

python manage.py runserver 0.0.0.0:8000

با این کار برنامه از شبکه قابل دسترسی می‌شود، اما runserver همچنان یک Development Server است.

هدف این Server فراهم کردن محیطی ساده برای توسعه است، نه سرویس‌دهی حرفه‌ای به کاربران اینترنت.

برای Production معمولاً از Application Serverهایی مانند Gunicorn، Uvicorn یا ابزارهای مشابه استفاده می‌شود.

debug در Production

یکی از مهم‌ترین تفاوت‌های Development و Production مربوط به DEBUG است.

در Development ممکن است داشته باشیم:

DEBUG = True

در این حالت اگر خطایی در برنامه رخ دهد، Django اطلاعات زیادی درباره خطا، فایل، خط کد و Traceback نمایش می‌دهد.

این اطلاعات برای برنامه‌نویس مفید هستند، اما نباید در اختیار کاربران قرار بگیرند؛ زیرا ممکن است اطلاعاتی درباره ساختار داخلی برنامه فاش شود.

به همین دلیل در Production باید:

DEBUG = False

باشد.

ALLOWES_HOSTS

وقتی پروژه را در Production اجرا می‌کنیم، باید دامنه‌هایی که اجازه دسترسی به برنامه دارند را نیز مشخص کنیم.

برای مثال:

ALLOWED_HOSTS = [
    "example.com",
    "www.example.com",
]

این تنظیم به Django کمک می‌کند درخواست‌هایی که Host نامعتبر دارند را رد کند.

Nginx چه کاری انجام می‌دهد؟

در بسیاری از پروژه‌های Django، Nginx در جلوی برنامه قرار می‌گیرد.

Nginx یک Web Server و Reverse Proxy است و می‌تواند وظایفی مانند دریافت درخواست‌های HTTP و HTTPS، سرو کردن فایل‌های Static و ارسال درخواست‌های مربوط به Django به Application Server را انجام دهد.

به عنوان مثال، کاربر درخواست صفحه‌ای از سایت را ارسال می‌کند. درخواست ابتدا به Nginx می‌رسد و Nginx آن را به Application Server، مثلاً Gunicorn، منتقل می‌کند.

این ساختار باعث می‌شود Django مستقیماً در معرض تمام درخواست‌های اینترنت قرار نگیرد و هر بخش مسئولیت مشخصی داشته باشد.

Gunicorn چیست؟

Gunicorn یکی از Application Serverهای رایج برای اجرای پروژه‌های Django در Production است.

برای مثال می‌توان Application مربوط به WSGI را با دستور زیر اجرا کرد:

gunicorn myproject.wsgi:application

در این معماری، Nginx درخواست را دریافت می‌کند و آن را به Gunicorn می‌دهد. Gunicorn نیز درخواست را به Django منتقل می‌کند.

بنابراین به جای اینکه کاربر مستقیماً با Development Server ارتباط داشته باشد، درخواست از یک مسیر کنترل‌شده‌تر به برنامه می‌رسد.

Static Files در Production

در Development، Django می‌تواند Static Files را برای ما مدیریت کند. اما در Production معمولاً بهتر است فایل‌هایی مانند CSS، JavaScript و تصاویر ثابت توسط Web Server سرو شوند.

برای جمع‌آوری Static Files معمولاً از دستور زیر استفاده می‌شود:

python manage.py collectstatic

و Django فایل‌های Static پروژه را در مسیری که با STATIC_ROOT مشخص کرده‌ایم قرار می‌دهد.

سپس Nginx می‌تواند این فایل‌ها را مستقیماً به کاربر ارائه کند.

این کار هم معماری را ساده‌تر می‌کند و هم باعث می‌شود Django مجبور نباشد برای هر فایل Static درگیر پردازش درخواست شود.

Static و Media چه تفاوتی دارند؟

این دو مفهوم گاهی با هم اشتباه گرفته می‌شوند.

Static Files فایل‌هایی هستند که همراه پروژه قرار دارند؛ مانند:

• CSS
• JavaScript
• Font
• Icon

اما Media Files معمولاً فایل‌هایی هستند که توسط کاربران آپلود می‌شوند؛ مانند تصویر پروفایل یا تصویر یک محصول.

به همین دلیل بهتر است این دو مسیر را از یکدیگر جدا نگه داریم.

Database در Development و Production

در محیط Development استفاده از SQLite بسیار رایج است، چون راه‌اندازی آن ساده است و برای بسیاری از پروژه‌های کوچک و آزمایشی مناسب است.

اما در Production معمولاً از Databaseهای Server-based مانند PostgreSQL یا MySQL استفاده می‌شود.

البته این به معنی آن نیست که استفاده از PostgreSQL در تمام پروژه‌ها اجباری است. انتخاب Database به نیازها و معماری پروژه بستگی دارد.

مدیریت Secretها

در Production نباید اطلاعات حساسی مانند Secret Key، رمز Database یا API Key را مستقیماً داخل کد قرار دهیم.

مثلاً این کار مناسب نیست:

SECRET_KEY = "my-secret-key"

زیرا اگر کد پروژه وارد Git شود، ممکن است این اطلاعات نیز در Repository قرار بگیرند.

راه بهتر استفاده از Environment Variables است:

import os

SECRET_KEY = os.environ["SECRET_KEY"]

به این ترتیب Secretها از کد اصلی پروژه جدا می‌شوند.

همین روش برای اطلاعاتی مانند رمز Database، API Key و Tokenهای سرویس‌های مختلف نیز کاربرد دارد.

HTTPS در Production

در Development معمولاً با آدرسی مانند زیر کار می‌کنیم:

http://127.0.0.1:8000

اما یک سایت واقعی باید از HTTPS استفاده کند:

https://example.com

HTTPS ارتباط بین مرورگر و سرور را رمزنگاری می‌کند و برای امنیت اطلاعات کاربران اهمیت زیادی دارد.

در بسیاری از معماری‌های Django، مدیریت HTTPS در Nginx انجام می‌شود و سپس درخواست به Application Server منتقل می‌شود.

Logging و مدیریت خطا

در Development معمولاً کافی است خطا را در Terminal ببینیم و آن را برطرف کنیم.

اما در Production ممکن است صدها یا هزاران کاربر هم‌زمان از برنامه استفاده کنند. بنابراین باید بتوانیم خطاها و اتفاقات مهم سیستم را ثبت و بررسی کنیم.

Logging به ما کمک می‌کند بفهمیم چه اتفاقی افتاده، چه زمانی رخ داده و مشکل مربوط به کدام بخش از برنامه بوده است.

این موضوع مخصوصاً زمانی اهمیت پیدا می‌کند که خطایی برای کاربر اتفاق افتاده اما توسعه‌دهنده نمی‌تواند آن را روی سیستم خودش بازتولید کند.

تنظیمات Development و Production

در پروژه‌های بزرگ‌تر معمولاً بهتر است تنظیمات مربوط به Development و Production از یکدیگر جدا شوند.

برای مثال می‌توان ساختاری مانند زیر داشت:

settings/
├── base.py
├── development.py
└── production.py

تنظیمات مشترک در base.py قرار می‌گیرند و تنظیمات مخصوص هر محیط در فایل مربوط به خودش.

برای مثال:

# development.py

DEBUG = True

و:

# production.py

DEBUG = False

این کار باعث می‌شود مدیریت تنظیمات پروژه در محیط‌های مختلف ساده‌تر و قابل کنترل‌تر باشد.

تفاوت Development و Production در یک نگاه

یک مثال واقعی

فرض کنید پروژه Django شما روی لپ‌تاپتان به این شکل اجرا می‌شود:

python manage.py runserver

در این حالت تقریباً همه‌چیز توسط خود Django مدیریت می‌شود.

اما وقتی پروژه را روی یک VPS قرار می‌دهید، معماری می‌تواند به شکل زیر باشد:

Browser → Nginx → Gunicorn → Django → Database

در این معماری:

• Nginx درخواست‌های HTTP و HTTPS را دریافت می‌کند.
• Gunicorn برنامه Django را اجرا می‌کند.
• Django منطق اصلی برنامه را پردازش می‌کند.
• Database اطلاعات برنامه را ذخیره می‌کند.

این جداسازی باعث می‌شود هر بخش وظیفه مشخصی داشته باشد و مدیریت سیستم در Production راحت‌تر شود.

جمع‌بندی

Development و Production دو محیط با اهداف متفاوت هستند.

در Development، اولویت اصلی سرعت توسعه، تست و Debug کردن است. به همین دلیل استفاده از runserver و فعال بودن DEBUG کاملاً منطقی است.

اما در Production، برنامه باید برای امنیت، پایداری، Performance و استفاده کاربران واقعی آماده باشد.

به همین دلیل در یک پروژه Django واقعی ممکن است از ترکیبی مانند Nginx، Gunicorn، Django و PostgreSQL استفاده کنیم.

بنابراین وقتی یک پروژه Django را از لپ‌تاپ خود به سرور منتقل می‌کنیم، صرفاً کد را روی یک کامپیوتر دیگر اجرا نکرده‌ایم؛ بلکه برنامه را وارد محیطی با نیازها و محدودیت‌های متفاوت کرده‌ایم.