چگونه پروژه جنگو را بدون Dockerfile دیپلوی کنیم؟

پروژه روی لپ‌تاپت اجرا می‌شود، ولی موقع استقرار باید پورت، دستور اجرا، متغیرهای محیطی و فرایند بیلد را مشخص کنی. اگر سراغ Dockerfile بروی، انتخاب Base Image و مدیریت Layer ها هم به این فهرست اضافه می‌شود.

در پاستا می‌توانی پروژه ات را بدون نوشتن Dockerfile مستقر کنی. این قابلیت فقط ساخت Image را از دوش تو برمی‌دارد؛ dependency ها، تنظیمات production، Gunicorn، دیتابیس، Migration و Static File ها همچنان مسئولیت خودت هستند.

پاسخ سریع: چطور جنگو را بدون Dockerfile مستقر کنی؟

برای استقرار این مسیر را طی کن:

1. تمام dependency ها را در requirements.txt ثبت کن.

2. تنظیمات حساس را از کد بیرون بکش.

3. DEBUG را خاموش و ALLOWED_HOSTS را تنظیم کن.

4. Gunicorn را به پروژه اضافه کن.

5. Build Command و Start Command را در Paastafile مشخص کن.

6. مقادیر حساس را به‌صورت Secret و تنظیمات عادی را به‌صورت Environment Variable تعریف کن.

7. پروژه را با Paasta CLI یا از طریق کنسول بیلد و مستقر کن.

8. در صورت نیاز دیتابیس مدیریت شده و فضای ذخیره سازی را تنظیم کن.

 

قبل از استقرار چه چیزهایی باید در Repository باشد؟

فرض کنیم ساختار پروژه چنین است:  

shop/
├── manage.py
├── requirements.txt
├── shop/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── products/
    ├── admin.py
    ├── models.py
    └── views.py

چون wsgi.py داخل package با نام shop قرار دارد، مسیر اپلیکیشن برای Gunicorn برابر shop.wsgi:application است.

Dependency ها را نصب و ثبت کن:

python -m pip install Django gunicorn
python -m pip freeze > requirements.txt

اگر از قبل requirements.txt داری، فقط Gunicorn را با نسخه سازگار پروژه به آن اضافه کن. اجرای دوباره pip freeze ممکن است ابزارهای تست و packageهای محیط توسعه را وارد فایل production کند.

نمونه حداقلی:

Django
gunicorn

برای پروژه واقعی بهتر است نسخه‌های آزموده‌شده خودت را Pin کنی. اینجا شماره نسخه مشخصی پیشنهاد نمی‌کنیم، چون انتخاب آن به نسخه Python و dependencyهای پروژه وابسته است.

حالا نصب تمیز را در یک Virtual Environment آزمایش کن:

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python manage.py check

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

تنظیمات production جنگو را چطور آماده کنی؟

مقادیر حساس را داخل settings.py یا Git نگذار. SECRET_KEY را از Environment Variable بخوان و DEBUG را با مقدار پیش‌فرض خاموش تنظیم کن:

import os

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]

DEBUG = os.getenv("DJANGO_DEBUG", "false").lower() == "true"

ALLOWED_HOSTS = [
    host.strip()
    for host in os.getenv("DJANGO_ALLOWED_HOSTS", "").split(",")
    if host.strip()
]

در پاستا این مقادیر را تعریف کن:

DJANGO_SECRET_KEY=<یک مقدار تصادفی و محرمانه>
DJANGO_DEBUG=false
DJANGO_ALLOWED_HOSTS=<دامنه یا دامنه‌های اپلیکیشن>

DJANGO_SECRET_KEY را به‌صورت Secret ثبت کن. DJANGO_DEBUG و DJANGO_ALLOWED_HOSTS می‌توانند Environment Variable باشند؛ پاستا از Secret و متغیر محیطی پشتیبانی می‌کند.

مستندات Django می‌گوید SECRET_KEY نباید وارد Source Control شود. هنگام DEBUG=False نیز باید ALLOWED_HOSTS مقدار معتبری داشته باشد. پیش از استقرار این بررسی را اجرا کن:

python manage.py check --deploy

این دستور بخشی از خطاهای تنظیمات production را پیدا می‌کند، ولی جای تست واقعی اپلیکیشن را نمی‌گیرد. جزئیات هشدارها در Deployment checklist رسمی Django آمده است.

از runserver برای production استفاده نکن. Django این دستور را Development Server می‌داند و برای production استفاده از WSGI یا ASGI Server را توصیه می‌کند.

برای پروژه نمونه، Gunicorn را محلی اجرا کن:

gunicorn shop.wsgi:application \
  --bind 0.0.0.0:8000

در ترمینال دیگری درخواست آزمایشی بفرست:

curl -I http://127.0.0.1:8000/

خروجی به View، Middleware و تنظیمات پروژه بستگی دارد:

 

در محیط استقرار می‌توانی پورت را از Environment Variable بخوانی و برای آزمایش محلی مقدار پیش‌فرض داشته باشی:

gunicorn shop.wsgi:application \
  --bind 0.0.0.0:${PORT:-8000}

این دستور در صورت تعریف PORT از همان مقدار استفاده می‌کند؛ در غیر این صورت روی پورت 8000 گوش می‌دهد.

تعداد Worker و Timeout را عمداً در نمونه نگذاشته‌ایم. مقدار مناسب به حافظه در دسترس، زمان پاسخ Viewها و الگوی ترافیک پروژه بستگی دارد و باید با اجرای واقعی تعیین شود.

راهنمای رسمی اجرای Django با Gunicorn مسیر ماژول WSGI را ورودی Gunicorn معرفی می‌کند.

Static File و Migration را کجا مدیریت کنی؟

برای جمع‌آوری فایل‌های Static باید STATIC_ROOT را تعریف کنی:

STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"

سپس این دستور را اجرا کن:

python manage.py collectstatic --noinput

Django فایل‌ها را در STATIC_ROOT جمع می‌کند. 

Migration را بدون بررسی به Start Command اپلیکیشن اضافه نکن. اگر چند پاد هم‌زمان شروع شوند، چند فرایند ممکن است برای اجرای یک Migration رقابت کنند.

 

فرمان Migration این است:

python manage.py migrate --noinput

پیش از اجرای آن روی دیتابیس production، وضعیت Migration ها و روش بازگشت را بررسی کن. تغییر schema یا Migration طولانی ممکن است درخواست‌های فعال را مختل کند.

برای آماده‌سازی دیتابیس، مطلب «راه‌اندازی PostgreSQL و اتصال امن آن به اپلیکیشن» را بخوان. اطلاعات اتصال را در Secret نگه دار.

دیپلوی جنگو بدون Dockerfile دقیقاً چه مزیت و محدودیتی دارد؟

مزیت اصلی، حذف نگهداری Dockerfile از Repository است. برای پروژه‌ای با فرایند ساخت استاندارد Python لازم نیست دستورهای COPY، ترتیب Layer ها و Entrypoint را خودت تعریف کنی. پاستا بیلد و استقرار را بر اساس کد شما و بدون پیش نیاز خاصی هوشمندانه انجام می دهد.

اگر Base Image اختصاصی یا کنترل دقیق Layerها می‌خواهی، این روش لزوماً مناسب نیست. مطلب «Dockerfile چیست و چگونه بنویسیم — با نمونه‌های آماده» برای چنین پروژه‌ای مفیدتر است.

پاستا مبتنی بر Kubernetes  و چندابری است. این زیرساخت مسئولیت تنظیم مصرف حافظه، تعداد Workerها، Migration و نگهداری داده را از پروژه حذف نمی‌کند.

خطاهای رایج هنگام اجرای Django روی سرور را چطور رفع کنی؟

خطای ModuleNotFoundError: No module named 'shop'

نمونه پیام:

ModuleNotFoundError: No module named 'shop'

Gunicorn نمی‌تواند ماژول معرفی‌شده را import کند. نام پروژه در Start Command اشتباه است یا دستور را از مسیری اجرا می‌کنی که package پروژه در Python Path نیست.

وجود فایل و امکان Import را بررسی کن:

test -f shop/wsgi.py
python -c "import shop.wsgi"

اگر package اصلی نام دیگری دارد، دستور را اصلاح کن:

gunicorn actual_project_name.wsgi:application --bind 0.0.0.0:8000

خطای DisallowedHost: Invalid HTTP_HOST header

نمونه پیام:

django.core.exceptions.DisallowedHost: Invalid HTTP_HOST header: 'example.com'

دامنه درخواست در ALLOWED_HOSTS نیست. دامنه Ingress را به متغیر مربوط اضافه کن:

DJANGO_ALLOWED_HOSTS=example.com,www.example.com

مقدار * خطا را پنهان می‌کند، ولی اعتبارسنجی Host را ضعیف می‌کند. دامنه‌های production را مشخص بنویس.

خطای ImproperlyConfigured: The SECRET_KEY setting must not be empty

پیام متداول:

django.core.exceptions.ImproperlyConfigured:
The SECRET_KEY setting must not be empty.

متغیر محیطی تنظیم نشده، نام آن با settings.py فرق دارد یا Secret به پردازش اپلیکیشن نرسیده است. بدون چاپ مقدار Secret، وجودش را بررسی کن:

python -c "import os; print(bool(os.getenv('DJANGO_SECRET_KEY')))"

نام متغیر در کد و تنظیمات پاستا باید یکسان باشد.

خطای You're using the staticfiles app without having set the STATIC_ROOT setting

نمونه پیام:

django.core.exceptions.ImproperlyConfigured:
You're using the staticfiles app without having set the STATIC_ROOT
setting to a filesystem path.

فرمان collectstatic اجرا شده، ولی STATIC_ROOT تعریف نشده است. آن را به settings.py اضافه کن:

STATIC_ROOT = BASE_DIR / "staticfiles"

بعد فرمان را دوباره اجرا کن:

python manage.py collectstatic --noinput

اگر فایل‌های این مسیر باید پس از جایگزینی پاد باقی بمانند، درباره Persistent Volume یا روش دیگری برای سرو Static تصمیم بگیر. پاستا از Persistent Volume پشتیبانی می‌کند، ولی مناسب‌بودن آن برای Static Fileهای این پروژه به طراحی فنی بستگی دارد.

خطای connection refused هنگام اتصال به PostgreSQL

بسته به Driver، بخشی از پیام می‌تواند چنین باشد:

connection refused
Is the server running on that host and accepting TCP/IP connections?

این پیام یعنی اتصال TCP به Host و Port دیتابیس برقرار نشده است. Host و Port را بررسی کن، سپس دسترسی از محیط اپلیکیشن تا دیتابیس را بسنج.

Password نادرست معمولاً خطای Authentication جداگانه ایجاد می‌کند. بنابراین تعویض Password پاسخ هر خطای اتصال نیست.

چک‌لیست عملی قبل از استقرار چیست؟

• requirements.txt در یک محیط تازه نصب می‌شود.

• Gunicorn در dependency ها ثبت شده است.

• مسیر project_name.wsgi:application واقعاً Import می‌شود.

• DEBUG در production برابر False است.

• SECRET_KEY از Secret خوانده می‌شود و داخل Git نیست.

• دامنه Ingress در ALLOWED_HOSTS قرار دارد.

• خروجی python manage.py check --deploy بررسی شده است.

• STATIC_ROOT تعریف شده و محل اجرای collectstatic مشخص است.

• روش یک‌باره اجرای Migration تعیین شده است.

• اطلاعات دیتابیس در Secret قرار گرفته‌اند.

• Start Command به پورت محیط گوش می‌دهد.

• نیاز پروژه به Persistent Volume بررسی شده است.

• تنظیم Health Check تایید شده است:
  [[نیاز به تایید تیم فنی: قابلیت و روش تنظیم Health Check در پاستا]]

• Worker هایی پس‌زمینه از Web Process جدا طراحی شده‌اند.

اگر Celery داری، آن را داخل فرایند Gunicorn اجرا نکن. برای طراحی این بخش، مطلب «اجرای Worker و Celery در کنار اپلیکیشن اصلی» را ببین.

جمع‌بندی: از کجا استقرار را شروع کنی؟

برای دیپلوی django بدون Dockerfile، ابتدا Repository را مستقل از لپ‌تاپت قابل اجرا کن: dependencyها، تنظیمات production، Gunicorn، Static File و Migration را مشخص کن. سپس Secretها، Environment Variable ها، Ingress و منابع ماندگار را در پاستا تعریف کن و بیلد را به پاستا بسپار.

این روش برای پروژه‌ای مناسب است که فرایند ساخت استانداردی دارد و نمی‌خواهد Dockerfile نگه دارد. اگر Build به کنترل سطح پایین Image وابسته است، میتوانید Dockerfile بنویسید تا پاستا آن را بیلد کند.