نشر مشروع ويب جامعي وتجهيزه للعرض على الإنترنت

لتشغيل Django خارج بيئة التطوير، تحتاج إلى اعتماديات مثبتة وإعدادات منفصلة وقاعدة بيانات وخادم WSGI، ثم فحوص تخبرك أن التطبيق يعمل. ننفذ هذه الخطوات باستخدام Django 5.2 وSQLite وWaitress. اختُبر التشغيل محلياً على Windows؛ أما ربط نطاق عام وTLS وإدارة العملية باستمرار فيحتاج إلى ضبط وفحص على الاستضافة المستهدفة.

ابدأ ببيئة نظيفة وإصدارات معلومة

الإصدارات التي نُفذت عند إعداد المثال: Python 3.12.10 وDjango 5.2.18 وWaitress 3.0.2 وSQLite 3.49.1. هذه نقطة إعادة تجربة وليست وعداً بأن الإصدارات ستظل الأحدث؛ راجع التحديثات قبل الاستخدام. للمشروع الموجود، حافظ على ملف اعتمادياته واختبر الترقية منفصلة، ولا تستبدله بالأرقام التالية عشوائياً.

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install Django==5.2.18 waitress==3.0.2
.\.venv\Scripts\python.exe -m django startproject demo .
.\.venv\Scripts\python.exe -m pip freeze > requirements.txt

نفذ startproject في مجلد تجربة جديد فقط؛ لا ينطبق على مستودع يحتوي مشروع Django أصلاً. وفي سير نشر المشروع القائم، تستنسخ النسخة المحددة وتثبت requirements ثم تستخدم manage.py الموجود. تأكد أن خطة الاستضافة تستطيع تشغيل Python وWSGI وحفظ قاعدة البيانات؛ رفع ملفات Python إلى استضافة صفحات ثابتة لا يشغّلها.

افصل قيم البيئة عن المصدر

في demo/settings.py أضف import os، واستبدل قيم SECRET_KEY وDEBUG وALLOWED_HOSTS بالقيم التالية، ثم أضف STATIC_ROOT وتعديل مسار القاعدة بعد تعريف DATABASES. يجب ألا يبقى تعريف آخر لاحق يعيد القيم القديمة. لا تضع سراً فعلياً داخل Git، ولا تستخدم المضيف العام * لتجاوز خطأ النطاق.

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]
DEBUG = False
ALLOWED_HOSTS = os.environ["DJANGO_ALLOWED_HOSTS"].split(",")
STATIC_ROOT = BASE_DIR / "staticfiles"
DATABASES["default"]["NAME"] = os.environ.get(
    "DJANGO_DB_PATH", str(BASE_DIR / "db.sqlite3")
)

للتجربة المحلية، عيّن مضيفي localhost و127.0.0.1 وسراً مولداً في بيئة العملية. في الاستضافة، ضع المضيف الحقيقي والسّر في إعداداتها الآمنة، واجعل DJANGO_DB_PATH يشير إلى مسار دائم خارج مجلد إصدار قد يُستبدل بالنشر. لا تعرض ملف القاعدة ضمن ملفات الويب العامة.

$env:DJANGO_SECRET_KEY = .\.venv\Scripts\python.exe -c "import secrets; print(secrets.token_urlsafe(50))"
$env:DJANGO_ALLOWED_HOSTS = "127.0.0.1,localhost"
.\.venv\Scripts\python.exe manage.py migrate --noinput
.\.venv\Scripts\python.exe manage.py collectstatic --noinput
.\.venv\Scripts\python.exe manage.py check

الترحيلات تنشئ مخطط القاعدة الذي يحتاجه التطبيق، ولا تعني إدخال بيانات عرض تلقائياً. أضف بيانات تجربة مسموحة بطريقة موثقة منفصلة. وقبل ترحيل قاعدة قائمة، جهّز نسخة احتياطية قابلة للاستعادة، وافهم أثر الترحيل على إصدار التطبيق السابق؛ الرجوع بالكود وحده لا يعكس كل تغيير بيانات.

أضف فحص تشغيل محدوداً

للمشروع التجريبي، يمكن أن يحتوي demo/urls.py على المقطع التالي. الفحص يتحقق من الاتصال بقاعدة البيانات، ولا يعرض إعدادات أو أسماء مستخدمين أو سراً. لا يعتبر استعلام SELECT 1 إثباتاً لكل وظيفة؛ أكمل لاحقاً مسار المستخدم الحقيقي واختبارات نماذجك.

from django.db import connection
from django.http import JsonResponse
from django.urls import path

def health(request):
    with connection.cursor() as cursor:
        cursor.execute("SELECT 1")
        database_ok = cursor.fetchone()[0] == 1
    return JsonResponse({"status": "ok", "database": database_ok})

urlpatterns = [path("health/", health)]

شغّل WSGI بدلاً من خادم التطوير

توضح قائمة نشر Django أن runserver ليس خادم إنتاج. ينشئ startproject كائن WSGI في demo.wsgi:application، ويمكن لـWaitress تشغيله بالأمر التالي. ربطه بـ127.0.0.1 مقصود للتجربة أو للعمل خلف وسيط محلي، ولا يجعله متاحاً مباشرة من الإنترنت.

.\.venv\Scripts\waitress-serve.exe --listen=127.0.0.1:8000 demo.wsgi:application
# In another local terminal:
Invoke-RestMethod http://127.0.0.1:8000/health/

في بيئة عامة، تحتاج إدارة عملية تعيد التشغيل وفق خطة واضحة، وReverse Proxy يربط النطاق ويُنهي TLS، وخدمة للملفات الثابتة والمرفوعة بسياسات منفصلة. لا تفترض أن Waitress سيقدم ملفات collectstatic وحده. ولا تثق برؤوس Proxy إلا من وسيط معروف وبإعداد متطابق بين الطبقات.

ماذا تراجع قبل فتح النطاق؟

• ضبط النطاق الفعلي وHTTPS والتحويلات دون حلقات، وحفظ المسارات.
• تشغيل manage.py check --deploy على إعدادات الإنتاج ومراجعة كل تحذير في سياقه.
• إعداد Cookies وCSRF والأصل الموثوق وفق طريقة استخدام التطبيق.
• صلاحية كتابة مسار القاعدة أو استخدام قاعدة إنتاج مناسبة لمتطلبات التزامن.
• فصل السجلات والأسرار والنسخ الاحتياطية عن المجلد العام.
• اختبار إعادة التشغيل واستمرار البيانات، ثم وظيفة حقيقية من حساب تجربة.

ما الذي اختُبر وما الذي بقي؟

إذا ظهر 502، افحص عملية التطبيق والوسيط. وعند رفض المضيف راجع ALLOWED_HOSTS، وعند فشل القاعدة راجع المسار والترحيلات وصلاحيات الكتابة دون نشر قيم الاتصال. يفيدك دليل تشخيص API وفحص نسخة التسليم في متابعة المشكلة. ولطلب المساعدة في تشغيل موقع أو نظام ونشره، حدّد التقنية وخطة الاستضافة وأمر التشغيل ورسالة الخطأ المنقحة.