تطبيق عملي لتعلم جانغو - الجزء 10: نشر تطبيق جانغو في بيئة الإنتاج - Django

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

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

يجب استضافة موقعك بعد الانتهاء منه (أو الانتهاء منه "بما يكفي" لبدء الاختبار العام) في مكان أعم ويمكن الوصول إليه من أجهزة أخرى غير حاسوبك الشخصي الخاص بالتطوير.

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

إجراء بعض التغييرات على إعدادات مشروعك.
اختيار بيئة لاستضافة تطبيق جانغو.
اختيار بيئة لاستضافة أيّ ملفات ثابتة.
إعداد بنية تحتية على مستوى بيئة الإنتاج لتخديم موقع الويب.

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

تتألف هذه السلسلة الفرعية من السلسلة الأشمل تعلم تطوير الويب من المقالات التالية:

ما هي بيئة الإنتاج؟

بيئة الإنتاج هي البيئة التي يوفّرها حاسوب الخادم إذ ستشغّل موقعك للاستخدام الخارجي، وتشمل هذه البيئة ما يلي:

عتاد الحاسوب الذي يعمل عليه الموقع.
نظام التشغيل، مثل لينكس وويندوز.
وقت التشغيل الخاص بلغة البرمجة ومكتبات أطر العمل التي كُتِب عليها موقعك.
خادم الويب المُستخدَم لتخديم الصفحات والمحتويات الأخرى، مثل خادم Nginx وأباتشي Apache.
خادم التطبيق الذي يمرّر الطلبات "الديناميكية" بين موقع جانغو وخادم الويب.
قواعد البيانات التي يعتمد عليها موقعك.

ملاحظة: يمكن أن يكون لديك أيضًا وكيل عكسي Reverse Proxy وموازن حِمل Load Balancer وغير ذلك بناءً على كيفية ضبط بيئتك الإنتاجية. يمكنك الاطلاع على المقالين التاليين الموجودين على موقع أكاديمية حسوب لمزيد من المعلومات حول الوكيل العكسي، وهي: كيفيّة ضبط Nginx للعمل كخادم ويب وكوسيط عكسي لـ Apache على خادم Ubuntu 18.04 وكيف تستخدم Apache ليعمل وسيطًا عكسيًّا Reverse Proxy على Ubuntu 16.04.

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

يُشار إلى هذا النوع من عتاد المعالجة والتشبيك الذي يمكن الوصول إليه عن بُعد باسم البنية التحتية مثل خدمة Infrastructure as a Service -أو IaaS اختصارًا. يوفّر العديد من بائعي خدمة IaaS خيارات التثبيت المُسبَق لنظام تشغيل معين، والذي يجب تثبيت مكونات بيئتك الإنتاجية الأخرى عليه، ويسمح لك البائعون الآخرون باختيار بيئات كاملة الميزات، ويمكن أن يتضمن ذلك الإعداد الكامل لجانغو وخادم الويب.

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

يدعم مزوّدو الاستضافة الآخرون إطار عمل جانغو بوصفه جزءًا من استضافة المنصة مثل خدمة Platform as a Service -أو PaaS اختصارًا، فلا داعٍ للقلق في هذا النوع من الاستضافة بشأن معظم أجزاء بيئتك الإنتاجية، أي خادم الويب وخادم التطبيق وموازن الحِمل لأن المنصة المضيفة تهتم بهذه الأشياء نيابةً عنك، إضافةً إلى أنها تهتم بمعظم ما يجب تطبيقه لتوسيع نطاق تطبيقك، مما يجعل النشر سهلًا جدًا، لأنك تحتاج فقط إلى التركيز على تطبيق الويب وليس على كامل بنية الخادم التحتية الأخرى.

سيختار بعض المطورين المرونة المتزايدة التي توفرها استضافة IaaS على حساب استضافة PaaS، بينما سيقدّر المطورون الآخرون تقليل تكاليف الصيانة وسهولة توسيع نطاق استضافة PaaS. يكون إعداد موقعك على نظام PaaS أسهل بكثير في البداية، وهذا ما سنفعله في هذا المقال.

ملاحظة: إذا اخترت مزوّد استضافة متوافق مع بايثون/جانغو، فيجب أن يقدّم إرشادات حول كيفية إعداد موقع جانغو باستخدام عمليات ضبط مختلفة لخادم الويب وخادم التطبيق والوكيل العكسي وغير ذلك، ولكن لا يتطابق ذلك مع اختيارك لاستضافة PaaS.

اختيار مزود الاستضافة

يوجد أكثر من 100 مزوّد استضافة معروفين يدعمون جانغو بنشاط أو يعملون بصورة جيدة معه، ويمكنك العثور على قائمة كبيرة إلى حدٍ ما في مضيفي DjangoFriendly، ويوفّر هؤلاء البائعون أنواعًا مختلفة من البيئات IaaS و PaaS، ومستويات مختلفة من موارد المعالجة والشبكات بأسعار مختلفة.

إليك بعض الأشياء التي يجب مراعاتها عند اختيار مضيف:

مدى انشغال موقعك وتكلفة البيانات وموارد المعالجة المطلوبة لتلبية هذا المطلب.
مستوى الدعم للتوسّع أفقيًا (إضافة المزيد من الأجهزة) وعموديًا (الترقية إلى أجهزة أقوى) وتكاليف ذلك.
مكان مراكز بيانات المزوّد، أي المكان الذي يكون الوصول إليه أسرع.
أداء وقت التشغيل ووقت التعطل السابقين للمضيف.
الأدوات المتوفرة لإدارة الموقع، لمعرفة إذا كانت سهلة الاستخدام وآمنة، مثل استخدام بروتوكول SFTP أو استخدام بروتوكول FTP.
أطر العمل المبنية مسبقًا لمراقبة خادمك.
القيود المعروفة، إذ سيوقِف بعض المضيفين عمدًا خدمات معينة مثل البريد الإلكتروني، ويقدّم البعض الآخر فقط عددًا معينًا من ساعات "النشاط" في بعض مستويات الأسعار، أو يقدّم فقط قدرًا صغيرًا من التخزين.
الفوائد الإضافية، إذ ستقدّم بعض المزوّدات أسماء نطاقات مجانية ودعمًا لشهادات SSL التي يمكن أن يتعيّن عليك دفع ثمنها.
معرفة ما إذا كان المستوى "المجاني" الذي تعتمد عليه تنتهي صلاحيته بمرور الوقت، وما إذا كانت تكلفة التهجير Migrating إلى مستوًى أغلى تعني أنه كان من الأفضل استخدام بعض الخدمات الأخرى من البداية.

هناك عددٌ قليل جدًا من المواقع التي توفر بيئات معالجة "مجانية" مخصصة للتقييم والاختبار في البداية، وتكون عادةً بيئات مُقيَّدة أو محدودة الموارد إلى حدٍ ما، ويجب أن تدرك أنه يمكن أن تنتهي صلاحيتها بعد فترة أولية أو يكون لديها قيود أخرى، ولكنها رائعة لاختبار المواقع ذات حركة المرور المنخفضة في بيئة مُستضافة، ويمكن أن توفر تهجيرًا سهل الدفع مقابل المزيد من الموارد عندما يصبح موقعك أكثر انشغالًا. تشمل الخيارات الشائعة في هذه الفئة Railway و Python Anywhere و Amazon Web Services و Microsoft Azure وغير ذلك.

تقدّم معظم المزوّدات مستوًى أساسيًا مخصصًا لمواقع الإنتاج الصغيرة، والذي يوفّر مستويات أكثر فائدة من قدرة المعالجة وقيودًا أقل. يُعَد Heroku و Digital Ocean و Python Anywhere أمثلةً على مزودات الاستضافة المشهورة التي لديها مستوى معالجة أساسي غير مكلف نسبيًا (في نطاق يتراوح بين 5 و 10 دولارات أمريكية شهريًا).

ملاحظة: تذكّر أن السعر ليس معيار الاختيار الوحيد، فإذا كان موقعك ناجحًا، فيمكن أن تكون قابلية التوسع هي الأهم.

تجهيز موقعك للنشر

ضُبِط موقع جانغو الهيكلي الذي أنشأناه باستخدام أدوات "django-admin" و "manage.py" لتسهيل عملية التطوير، ويجب أن تكون العديد من إعدادات مشروع جانغو المُحدَّدة في الملف "settings.py" مختلفةً لعملية الإنتاج لأسباب تتعلق بالأمان أو الأداء.

ملاحظة: من الشائع أن يكون لديك ملف "settings.py" منفصل لعملية الإنتاج و/أو أن تستورد إعدادات حساسة استيرادًا مشروطًا من ملف منفصل أو متغير بيئة، ويجب بعد ذلك حماية هذا الملف، حتى ولو كانت بقية الشيفرة المصدرية متاحةً في مستودع عام.

الإعدادات الأساسية التي يجب التحقق منها هي:

DEBUG: ينبغي ضبطه على القيمة False في مرحلة الإنتاج، أي DEBUG = False، مما يؤدي إلى إيقاف عرض تعقّب تنقيح الأخطاء ومعلومات المتغيرات الحساسة أو السرية.
SECRET_KEY: هو قيمة عشوائية كبيرة تُستخدَم للحماية من هجمات CSRF وغير ذلك. من المهم ألّا يكون المفتاح المستخدم في عملية الإنتاج تحت سيطرة المصدر أو يمكن الوصول إليه خارج خادم الإنتاج، إذ يشير توثيق جانغو إلى أنه من الأفضل تحميله من متغير بيئة أو قراءته من ملف خادم فقط.

# اقرأ‫ المفتاح السري SECRET_KEY من متغير البيئة
import os
SECRET_KEY = os.environ['SECRET_KEY']

# أو

# اقرأ المفتاح السري من ملف
with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()

لنعدّل تطبيق المكتبة المحلية LocalLibrary حتى نقرأ متغيرات SECRET_KEY و DEBUG من متغيرات البيئة إذا كانت مُعرَّفة، وإلّا فاستخدم القيم الافتراضية في ملف الضبط.

افتح الملف "‎/locallibrary/settings.py" وعطّل ضبط SECRET_KEY الأصلي وضِف الأسطر الجديدة الموضحة فيما يلي. لن تُحدَّد متغيرات بيئة للمفتاح أثناء عملية التطوير، لذلك ستُستخدَم القيمة الافتراضية. لا يهم ما هو المفتاح الذي تستخدمه هنا أو إذا تسرّب المفتاح، لأنك لن تستخدمه في عملية الإنتاج.

# تحذير أمني: حافظ على سرية المفتاح السري المُستخدَم في عملية الإنتاج
# SECRET_KEY = "cg#p$g+j9tax!#a3cup@1$8obt2_+&k3q+pmu)5%asj6yjpkag"
import os
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'cg#p$g+j9tax!#a3cup@1$8obt2_+&k3q+pmu)5%asj6yjpkag')

علّق بعد ذلك إعداد DEBUG الحالي وضِف السطر الجديد التالي:

# تحذير أمني: لا تنفّذ أثناء تشغيل تنقيح الأخطاء في عملية الإنتاج
# DEBUG = True
DEBUG = os.environ.get('DJANGO_DEBUG', '') != 'False'

سيكون DEBUG له القيمة True افتراضيًا، ولكنه سيكون False فقط عند ضبط قيمة متغير البيئة DJANGO_DEBUG على القيمة False.

لاحظ أن متغيرات البيئة هي سلاسل نصية وليست من أنواع بايثون، لذلك يجب موازنة السلاسل النصية، والطريقة الوحيدة لضبط المتغير DEBUG على القيمة False هي ضبطه على السلسلة النصية False.

يمكنك ضبط متغير البيئة على القيمة "False" على نظام لينكس باستخدام الأمر التالي:

export DJANGO_DEBUG=False

توفّر قائمة النشر في توثيق جانغو قائمة كاملة من الإعدادات التي يمكن أن ترغب في تغييرها، ويمكنك سرد عددٍ منها باستخدام أمر الطرفية التالي:

python3 manage.py check --deploy

تطبيق عملي: تثبيت موقع المكتبة المحلية LocalLibrary على منصة Railway

يقدّم هذا القسم شرحًا عمليًا لكيفية تثبيت موقع المكتبة المحلية LocalLibrary على منصة Railway.

سبب استخدام Railway

اخترنا استخدام منصة Railway لعدة أسباب هي:

تمتلك Railway مستوًى مجانيًا لخطة بداية مع بعض القيود، إذ من المهم أن تكون بأسعار مقبولة لجميع المطورين.
تهتم Railway بمعظم البنية التحتية، فلا حاجة للقلق بشأن الخوادم وموازني الحِمل والوكلاء العكسيين وغير ذلك، مما يجعل البدء أسهل بكثير.
تركّز Railway على تجربة المطور للتطوير والنشر، مما يؤدي إلى وجود منحنى تعليمي أسرع وأسلس من العديد من البدائل الأخرى.
تُعَد المهارات والمفاهيم التي ستتعلمها عند استخدام Railway قابلة للتحويل، إذ تمتلك Railway بعض الميزات الجديدة الممتازة، ولكن تستخدم خدماتُ الاستضافة الشائعة الأخرى العديد من الأفكار والأساليب نفسها.
لا تؤثر قيود الخدمات والخطط على استخدامنا لمنصة Railway في مثالنا، فمثلًا:
- تقدّم خطة البداية 500 ساعة فقط من وقت النشر المستمر كل شهر و5 دولارات من الرصيد الذي يُستهلَك بناءً على الاستخدام، ويُعاد ضبط الساعات والرصيد ويجب إعادة نشر المشاريع في نهاية كل شهر. تعني هذه القيود أنه يمكنك تشغيل مثالنا بصورة مستمرة لمدة 21 يومًا تقريبًا، ويُعَد ذلك أكثر من كافٍ للتطوير والاختبار، ولكن لن تتمكّن من استخدام هذه الخطة لموقع حقيقي للإنتاج.
- تحتوي بيئة خطة البداية على 512 ميجابايت فقط من الذاكرة RAM و1 جيجابايت من ذاكرة التخزين، وهذا أكثر من كافٍ لمثالنا.
- لا توجد سوى منطقة واحدة مدعومة وهي الولايات المتحدة الأمريكية حاليًا، إذ يمكن أن تكون الخدمة خارج هذه المنطقة أبطأ أو تحظرها القوانين المحلية.
- يمكن العثور على قيود أخرى في توثيق خطط Railway للدفع.
تبدو الخدمة موثوقة جدًا، وإذا كانت مناسبة لك، فإن الأسعار يمكن التنبؤ بها، ويكون توسيع تطبيقك سهلًا جدًا.

تعَد Railway مناسبةً لاستضافة مثالنا، ولكن يجب أن تأخذ الوقت الكافي لتحديد ما إذا كانت مناسبة لموقعك.

كيفية عمل Railway

يُشغَّل كل تطبيق ويب في حاوية افتراضية virtualized container معزولة ومستقلة خاصة به، لذا يجب أن تكون Railway قادرة على إعداد البيئة والاعتماديات المناسبة، وفهم كيفية إطلاقها من أجل تنفيذ تطبيقك. نقدّم هذه المعلومات في عددٍ من الملفات النصية بالنسبة لتطبيقات جانغو، وهي:

runtime.txt: يوضح لغة البرمجة والنسخة المُراد استخدامها.
requirements.txt: يسرد اعتماديات بايثون اللازمة لموقعك بما في ذلك جانغو.
Procfile: قائمة العمليات التي ستُنفَّذ لبدء تطبيق الويب. سيكون هذا الملف عادةً في تطبيقات جانغو خادم تطبيق ويب Gunicorn مع سكربت ‎.wsgi.
wsgi.py: ضبط واجهة WSGI لاستدعاء تطبيق جانغو في بيئة Railway.

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

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

يجب وضع تطبيق جانغو الخاص بنا في مستودع غيت git وإضافة الملفات السابقة والتكامل مع إضافة قاعدة البيانات وإجراء تغييرات للتعامل بصورة صحيحة مع الملفات الثابتة ليعمل تطبيقنا على Railway، ثم يمكننا إعداد حساب على Railway والحصول على عميل Railway وتثبيت موقعنا.

وهذا هو كل ما تحتاجه من معلومات في البداية.

إنشاء مستودع للتطبيق على غيت هب GitHub

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

ملاحظة: يُعَد استخدام نظام إدارة الشيفرة المصدرية مثل غيت هب ممارسةً جيدةً لتطوير البرمجيات، فإذا كنت تستخدم غيت هب لإدارة شيفرتك المصدرية مسبقًا، فتخطى هذه الخطوة.

هناك العديد من الطرق للعمل مع غيت، ولكن من أسهل هذه الطرق إعداد حساب على غيت هب GitHub أولًا وإنشاء المستودع عليه، ثم المزامنة معه محليًا كما يلي:

انتقل إلى موقع GitHub الرسمي وأنشئ حسابًا عليه.
انقر على رابط "+" في شريط الأدوات العلوي وحدّد خيار "مستودع جديد New repository" بعد تسجيل الدخول.
املأ جميع الحقول في هذه الاستمارة، إذ يمكن أن تكون هذه الحقول غير إلزامية، ولكن يُوصَى بها بشدة.
- أدخِل اسم المستودع الجديد والوصف، فمثلًا يمكنك استخدام الاسم "djangolocallibrary" والوصف "Local Library website written in Django" -أي موقع المكتبة المحلية المكتوب باستخدام جانغو.
- اختر الخيار Python في قائمة الاختيار "Add .gitignore".
- اختر الترخيص المفضل لديك في قائمة الاختيار "Add license".
- تحقّق من تهيئة المستودع باستخدام README.
اضغط على إنشاء مستودع Create repository.
انقر فوق الزر الأخضر نسخ Clone أو تنزيل Download في صفحة مستودعك الجديد.
انسخ قيمة URL من حقل النص الموجود في مربع الحوار الذي يظهر. إذا استخدمت اسم المستودع "djangolocallibrary"، فيجب أن يكون عنوان URL مثل العنوان: "https://github.com//django_local_library.git".

انتهينا من إنشاء المستودع، ويجب الآن نسخه على الحاسوب المحلي باتباع الخطوات التالية:

ثبّت غيت git على حاسوبك المحلي، إذ يمكنك العثور على نسخ لأنظمة مختلفة.
افتح موجه الأوامر أو الطرفية وانسخ مستودعك باستخدام عنوان URL الذي نسخته سابقًا كما في الأمر التالي:

git clone https://github.com/<your_git_user_id>/django_local_library.git

سيؤدي هذا الأمر إلى إنشاء المستودع في مجلد جديد في مجلد العمل الحالي.

انتقل إلى المستودع الجديد باستخدام الأمر التالي:

cd django_local_library

أخيرًا، انسخ تطبيقك في مجلد المشروع المحلي ثم ضِف -أو "ادفع push" حسب مصطلحات غيت- المستودع المحلي إلى مستودع غيت هب البعيد باتباع الخطوات التالية:

أولًا، انسخ تطبيق جانغو في هذا المجلد. جميع الملفات موجودة في مستوى الملف manager.py نفسه وأدنى منه، وليست بمستوى المجلد locallibrary الذي يحتوي عليها.

ثانيًا، افتح ملف "‎.gitignore" وانسخ الأسطر التالية في نهايته، ثم احفظه، إذ يُستخدم هذا الملف لتحديد الملفات التي لا يجب تحميلها إلى غيت افتراضيًا.

# الملفات النصية الاحتياطية
*.bak

# قاعدة البيانات
*.sqlite3

ثالثًا، افتح موجه الأوامر أو الطرفية واستخدم الأمر add لإضافة جميع الملفات إلى غيت، مما يؤدي إلى إضافة الملفات التي لا يتجاهلها ملف "‎.gitignore" إلى "منطقة مرحلة التحضير Staging Area".

git add -A

رابعًا، استخدم الأمر status للتحقق من صحة جميع الملفات التي تريد تثبيتها commit، إذ نريد تضمين الملفات المصدرية، وليس الملفات الثنائية والمؤقتة وما إلى ذلك، إذ يجب أن تبدو كما يلي:

> git status
On branch main
Your branch is up-to-date with 'origin/main'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   .gitignore
        new file:   catalog/__init__.py
        ...
        new file:   catalog/migrations/0001_initial.py
        ...
        new file:   templates/registration/password_reset_form.html

خامسًا، ثبّت باستخدام commit الملفات في مستودعك المحلي عندما تكون راضيًا عن النتيجة، إذ يكافئ ذلك الإقرار بالتغييرات وجعلها جزءًا رسميًا من المستودع المحلي.

git commit -m "First version of application moved into GitHub"

سادسًا، لم يتغيّر المستودع البعيد حتى الآن، لذا يجب مزامنة مستودعك المحلي مع مستودع غيت هب البعيد باستخدام الأمر push:

git push origin main

يجب أن تكون قادرًا عند اكتمال هذه العملية على العودة إلى صفحة غيت هب، حيث أنشأتَ مستودعك، وتحديث الصفحة، وملاحظة رفع التطبيق بالكامل. يمكنك الاستمرار في تحديث مستودعك مع تغير الملفات باستخدام دورة أوامر الإضافة add والتثبيت commit والدفع push.

ملاحظة: يمكنك الآن إنشاء نسخة احتياطية من شيفرة مشروعك البرمجية، إذ يمكن أن تكون بعض التغييرات التي سنجريها في الأقسام التالية مفيدة للنشر أو التطوير على أيّ نظام، ويمكن أن تكون بعض التغييرات الأخرى غير مفيدة. أفضل طريقة لذلك هي استخدام غيت لإدارة الإصدارات، إذ يمكنك باستخدامه الرجوع إلى إصدار قديم معين، ويمكنك الاحتفاظ به في فرع منفصل عن التغييرات الإنتاجية واختيار أيّ تغييرات للتنقل بين فروع الإنتاج والتطوير. يستحق تعلم غيت الجهد المبذول، لذا اطلع على مجموعة مقالات Git في أكاديمية حسوب لمزيدٍ من المعلومات حول ذلك. يُعَد نسخ ملفاتك في موقع آخر الطريقة الأسهل، ولكن يمكنك استخدام أيّ طريقة تتناسب مع معرفتك لنظام غيت.

تحديث التطبيق ليعمل على Railway

سنشرح في هذا القسم التغييرات التي يجب إجراؤها على تطبيق المكتبة المحلية LocalLibrary ليعمل على Railway، ولكن لن تمنعك هذه التغييرات من استخدام الاختبار وسير العمل المحلي الذي تعلمناه مسبقًا.

الملف Procfile

يُعَد الملف Procfile "نقطة الدخول" إلى تطبيق الويب، فهو يسرد الأوامر التي ستنفّذها Railway لبدء موقعك. لذا أنشئ ملف Procfile دون امتداد في جذر مستودع غيت هب وضع فيه النص التالي:

web: python manage.py migrate && python manage.py collectstatic --no-input && gunicorn locallibrary.wsgi

تخبر البادئة web:‎ منصة Railway أن هذه عملية ويب ويمكن إرسالها عبر حمولة HTTP، ثم نستدعي أمر تهجير جانغو python manage.py migrate لإعداد جداول قاعدة البيانات، ثم نستدعي أمر جانغو python manage.py collectstatic لتجميع الملفات الثابتة في المجلد الذي حدّده إعداد مشروع STATIC_ROOT الذي سنتعرّف عليه لاحقًا. أخيرًا، نبدأ عملية gunicorn الذي هو خادم تطبيقات ويب شائع، ونمرّر له معلومات الضبط في الوحدة locallibrary.wsgi التي أُنشئت باستخدام تطبيقنا الهيكلي: "‎/locallibrary/wsgi.py".

لاحظ أنه يمكنك أيضًا استخدام الملف Procfile لبدء العمليات العاملة أو لتشغيل مهام أخرى غير تفاعلية قبل نشر الإصدار.

خادم Gunicorn

Gunicorn هو خادم HTTP من بايثون يُستخدَم بصورة شائعة لتخديم تطبيقات جانغو WSGI على Railway كما أشرنا في فقرة ملف Procfile السابقة.

لسنا بحاجة خادم Gunicorn لتخديم تطبيق المكتبة المحلية LocalLibrary أثناء عملية التطوير، ولكننا سنثبّته محليًا، بحيث يصبح جزءًا من متطلباتنا التي تعِدّها Railway على الخادم البعيد.

تأكّد أولًا من أنك في بيئة بايثون الافتراضية التي أُنشِئت عند إعداد بيئة التطوير. استخدم الأمر workon [name-of-virtual-environment]‎، ثم ثبّت الخادم Gunicorn محليًا في سطر الأوامر باستخدام الأداة pip كما يلي:

pip3 install gunicorn

ضبط قاعدة البيانات

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

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

سنوفّر معلومات اتصال قاعدة البيانات لجانغو باستخدام متغير البيئة DATABASE_URL، إذ سنستخدم حزمة dj-database-url بدلًا من تثبيت هذه المعلومات في جانغو لتحليل متغير البيئة DATABASE_URL وتحويله تلقائيًا إلى تنسيق ضبط جانغو المطلوب، ويجب أيضًا تثبيت psycopg2 الذي يحتاجه جانغو للتفاعل مع قواعد بيانات Postgres.

حزمة dj-database-url

تُستخدَم حزمة dj-database-url لاستخراج ضبط قاعدة بيانات جانغو من متغير البيئة. ثبّت هذه الحزمة محليًا بحيث تصبح جزءًا من متطلباتنا التي تُعِّدها Railway على الخادم البعيد كما يلي:

pip3 install dj-database-url

الملف settings.py

افتح الملف ‎/locallibrary/settings.py وانسخ الضبط التالي وضعه في نهاية الملف:

# ‫تحديث ضبط قاعدة البيانات من ‎$DATABASE_URL
import dj_database_url
db_from_env = dj_database_url.config(conn_max_age=500)
DATABASES['default'].update(db_from_env)

سيستخدم جانغو الآن ضبط قاعدة البيانات الموجود في DATABASE_URL إذا كان متغير البيئة مضبوطًا، وإلّا فإنه يستخدم قاعدة بيانات SQLite الافتراضية. تجعل القيمة conn_max_age=500 الاتصال مستمرًا، وهو أكثر كفاءة بكثير من إعادة إنشاء الاتصال في كل دورة طلب، ويُعَد ذلك اختياريًا ويمكن إزالته عند الحاجة.

psycopg2

يحتاج جانغو إلى psycopg2 للعمل مع قواعد بيانات Postgres، لذا ثبّته محليًا بحيث يصبح جزءًا من متطلباتنا التي تُعِّدها Railway على الخادم البعيد كما يلي:

pip3 install psycopg2-binary

لاحظ أن جانغو سيستخدم قاعدة بيانات SQLite أثناء عملية التطوير افتراضيًا إذا لم يُضبَط متغير البيئة DATABASE_URL، ولكن يمكنك التبديل إلى قاعدة بيانات Postgres واستخدام قاعدة البيانات المُستضافة نفسها لعمليتي التطوير والإنتاج من خلال ضبط متغير البيئة نفسه في بيئة التطوير، إذ تسهّل Railway استخدام البيئة نفسها للإنتاج والتطوير. يمكنك بدلًا من ذلك تثبيت واستخدام قاعدة بيانات Postgres ذاتية الاستضافة على حاسوبك المحلي.

تخديم الملفات الثابتة في عملية الإنتاج

نستخدم أثناء عملية التطوير جانغو وخادم ويب تطوير جانغو لتخديم كلٍّ من ملفات HTML الديناميكية والملفات الثابتة، مثل ملفات CSS وجافا سكريبت JavaScript وغيرها، ولكن يُعَد ذلك غير فعال للملفات الثابتة، لأن الطلبات يجب أن تمر عبر جانغو بالرغم من أن جانغو لا يفعل أيّ شيء بها. لا يُعَد ذلك مهمًا أثناء عملية التطوير، إلّا أنه سيكون له تأثير كبير على الأداء إذا استخدمنا الطريقة نفسها في عملية الإنتاج.

نفصل عادةً الملفات الثابتة عن تطبيق جانغو في بيئة الإنتاج، مما يسهل تخديمها مباشرةً من خادم الويب أو من شبكة توصيل المحتوى Content Delivery Network -أو CDN اختصارًا.

إليك متغيرات الإعداد المهمة التي يجب تضعها في حساباتك:

STATIC_URL: موقع عنوان URL الأساسي الذي ستُخدَّم منه الملفات الثابتة مثل شبكة توصيل المحتوى CDN.
STATIC_ROOT: المسار المطلق للمجلد الذي ستجمِّع فيه أداة جانغو collectstatic الملفات الثابتة المشار إليها في قوالبنا، ثم يمكن رفعها على أنها مجموعة إلى مكان استضافة الملفات.
STATICFILES_DIRS: يسرد المجلدات الإضافية التي يجب أن تبحث فيها أداة جانغو collectstatic عن الملفات الثابتة.

تشير قوالب جانغو إلى مواقع الملفات الثابتة المتعلقة بالوسم static (يمكنك رؤيتها في القالب الأساسي المُعَّرف في مقال إنشاء صفحتنا الرئيسية)، والتي بدورها تربطها بإعداد STATIC_URL، وبالتالي يمكن رفع الملفات الثابتة إلى أيّ مضيف ويمكنك تحديث تطبيقك للعثور عليها باستخدام هذا الإعداد.

تُستخدَم الأداة collectstatic لتجميع الملفات الثابتة في المجلد الذي يحدّده إعداد المشروع STATIC_ROOT، إذ تُستدعَى باستخدام الأمر التالي:

python3 manage.py collectstatic

تشغِّل Railway أداة collectstatic في هذا المقال قبل رفع التطبيق، مما يؤدي إلى نسخ جميع الملفات الثابتة في التطبيق إلى الموقع المُحدَّد في STATIC_ROOT، ثم تجد مكتبة Whitenoise الملفات في الموقع الذي يحدّده STATIC_ROOT افتراضيًا وتخدّمها في عنوان URL الأساسي الذي يحدّده STATIC_URL.

الملف settings.py

افتح الملف "‎/locallibrary/settings.py" وانسخ الضبط الآتي في نهاية الملف، إذ يجب أن يكون BASE_DIR مُعرَّفًا مسبقًا في ملفك، ويمكن أن يكون STATIC_URL معرَّفًا ضمن الملف عند إنشائه، ويمكنك أيضًا حذف الإشارة إليه السابقة المكررة بالرغم من أنها لن تسبب أيّ ضرر.

# ‫الملفات الثابتة (ملفات CSS و JavaScript والصور)
# https://docs.djangoproject.com/en/4.0/howto/static-files/

# ‫مسار المجلد المطلق حيث ستجمع أداة collectstatic الملفات الثابتة للنشر.
STATIC_ROOT = BASE_DIR / 'staticfiles'

# ‫عنوان URL المراد استخدامه عند الإشارة إلى الملفات الثابتة (أي من حيث ستُخدَّم)
STATIC_URL = '/static/'

سنخدّم الملف باستخدام المكتبة WhiteNoise، والتي سنثبّتها ونضبطها في القسم التالي.

مكتبة Whitenoise

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

تستدعي Railway أداة collectstatic لتحضير ملفاتك الثابتة لتستخدمها المكتبة WhiteNoise بعد رفع تطبيقك. اطّلع على توثيق المكتبة WhiteNoise للحصول على شرح لكيفية عملها وسبب عَدّ عملية التقديم Implementation هذه طريقةً فعالة نسبيًا لتخديم هذه الملفات.

سنوضح فيما يلي خطوات إعداد المكتبة WhiteNoise لاستخدامها مع المشروع.

تثبيت المكتبة whitenoise

ثبّت المكتبة whitenoise محليًا باستخدام الأمر التالي:

pip3 install whitenoise

الملف settings.py

افتح الملف "‎/locallibrary/settings.py"، وابحث عن الإعداد MIDDLEWARE وضف WhiteNoiseMiddleware بالقرب من أعلى القائمة وبعد SecurityMiddleware مباشرةً لتثبيت مكتبة WhiteNoise في تطبيق جانغو كما يلي:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

يمكنك اختياريًا تقليل حجم الملفات الثابتة عند تخديمها، إذ يُعَد ذلك فعّالًا أكثر، فما عليك سوى إضافة ما يلي في نهاية الملف "‎/locallibrary/settings.py":

# تخديم ملف ثابت مبسط
# https://pypi.org/project/whitenoise/
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

لست بحاجة إلى إجراء أيّ شيء آخر لضبط مكتبة WhiteNoise لأنها تستخدم إعدادات مشروعك لكل من STATIC_ROOT و STATIC_URL افتراضيًا.

ملف المتطلبات Requirements

يجب تخزين متطلبات بايثون لتطبيقك في الملف "requirements.txt" ضمن جذر مستودعك، ثم ستثبّت Railway بعد ذلك هذه المتطلبات تلقائيًا عندما تعيد بناء بيئتك، إذ يمكنك إنشاء هذا الملف باستخدام الأداة pip في سطر الأوامر.

شغّل الأمر التالي في جذر المستودع:

pip3 freeze > requirements.txt

يجب أن يحتوي الملف "requirements.txt" على العناصر الآتية على الأقل بعد تثبيت جميع الاعتماديات السابقة (يمكن أن تكون أرقام النسخ مختلفة)، لذا احذف أيّ اعتماديات أخرى ليست موجودة فيما يلي، إن لم تضِفها صراحةً لتطبيقك:

dj-database-url==0.5.0
Django==4.0.2
gunicorn==20.1.0
psycopg2-binary==2.9.3
wheel==0.37.1
whitenoise==6.0.0

ملف وقت التشغيل Runtime

يخبر الملف runtime.txt -إذا كان مُعرَّفًا مسبقًا- منصةَ Railway بنسخة بايثون التي يجب استخدامها. أنشئ هذا الملف في جذر المستودع وضِف إليه النص التالي:

python-3.10.2

ملاحظة: لا يدعم مزوّدو الاستضافة بالضرورة جميع النسخ الثانوية لوقت تشغيل بايثون، إذ سيستخدمون أقرب نسخة مدعومة للقيمة التي تحددها.

إعادة الاختبار وحفظ التغييرات في غيت هب

اختبر الموقع أولًا محليًا مرةً أخرى قبل المتابعة وتأكّد من عدم تعطله بسبب أيِّ من التغييرات التي ذكرناها سابقًا، لذا شغّل خادم الويب الخاص بالتطوير كما هو معتاد، ثم تحقق من أن الموقع لا يزال يعمل كما هو متوقع على متصفحك كما يلي:

python3 manage.py runserver

لندفع باستخدام الأمر push بعد ذلك التغييرات إلى غيت هب، لذا أدخِل الأوامر التالية في الطرفية بعد الانتقال إلى مستودعنا المحلي:

git add -A
git commit -m "Added files and changes required for deployment"
git push origin main

يجب أن نكون جاهزين الآن لبدء نشر موقع المكتبة المحلية LocalLibrary على Railway.

الحصول على حساب على Railway

يجب أولًا إنشاء حساب لبدء استخدام Railway باتباع الخطوات التالية:

اذهب إلى موقع Railway الرسمي وانقر على رابط تسجيل الدخول Login في شريط الأدوات العلوي.
اختر "GitHub" في النافذة المنبثقة لتسجيل الدخول باستخدام اعتماديات غيت هب الخاصة بك.
يمكن أن تحتاج بعد ذلك إلى الانتقال إلى بريدك الإلكتروني والتحقق من حسابك.
ستسجل بعد ذلك الدخول إلى لوحة تحكم Railway.

النشر على Railway من غيت هب

يجب الآن إعداد Railway لنشر موقع مكتبتنا من غيت هب، لذا اختر أولًا خيار لوحة التحكم Dashboard من القائمة العلوية للموقع، ثم حدّد زر مشروع جديد New Project:

ستعرض Railway قائمةً بالخيارات الخاصة بالمشروع الجديد، بما في ذلك خيار نشر مشروع من قالب أنشأته لأول مرة في حسابك على غيت هب، وعددًا من قواعد البيانات، لذا حدّد خيار النشر "Deploy from GitHub repo".

ستُعرَض جميع المشاريع في مستودعات غيت هب التي شاركتها مع Railway أثناء عملية الإعداد، ولكنك ستختار مستودع غيت هب الخاص بموقع المكتبة المحلية: ‎<user-name>/django-locallibrary-tutorial.

أكّد النشر من خلال تحديد خيار النشر حالًا "Deploy Now".

ستحمّل Railway بعد ذلك مشروعك وتنشره، مع عرض التقدم في تبويب عمليات النشر Deployments، ثم سترى شيئًا يشبه ما يلي عند اكتمال النشر بنجاح:

يمكنك النقر على عنوان URL الخاص بالموقع (المُحدَّد في الشكل السابق) لفتح الموقع في المتصفح. لن يعمل الموقع حاليًا، لأن الإعداد لم يكتمل بعد.

ضبط ALLOWED_HOSTS و CSRF_TRUSTED_ORIGINS

سترى الآن شاشة تنقيح أخطاء كما يلي عند فتح الموقع، وهذا خطأ أمان جانغو الذي ظهر بسبب أن شيفرتك المصدرية لا تعمل على مضيف مسموح به "allowed host":

ملاحظة: يُعَد هذا النوع من معلومات تنقيح الأخطاء مفيدًا جدًا في عملية الإعداد، ولكنه يمثل خطرًا أمنيًا عند نشر موقع، لذا سنوضح كيفية تعطيل تنقيح الأخطاء عند رفع وتشغيل الموقع.

افتح الملف "‎/locallibrary/settings.py" في مشروع غيت هب وعدّل الإعداد ALLOWED_HOSTS لتضمين عنوان URL لموقعك على Railway كما يلي:

## مثلًا ‫لعنوان URL لموقع على 'web-production-3640.up.railway.app'
## ‏(ض‫ع عنوان URL الخاص بموقعك بدلًا من السلسلة النصية التالية):
ALLOWED_HOSTS = ['web-production-3640.up.railway.app', '127.0.0.1']

# يمكنك بدلًا من ذلك ضبط‫ عنوان URL الأساسي أثناء التطوير
# (يمكن أن تقرر تغيير الموقع عدة مرات)
# ALLOWED_HOSTS = ['.railway.com','127.0.0.1']

تستخدم التطبيقات الحماية ضد هجمات CSRF، لذا يجب أيضًا ضبط مفتاح CSRF_TRUSTED_ORIGINS.

افتح الملف "/locallibrary/settings.py" وضِف سطرًا مثل السطر التالي:

## مثلًا ‫لعنوان URL لموقع على 'web-production-3640.up.railway.app'
## ‏(ض‫ع عنوان URL الخاص بموقعك بدلًا من السلسلة النصية التالية):
CSRF_TRUSTED_ORIGINS = ['https://web-production-3640.up.railway.app']

# يمكنك بدلًا من ذلك ضبط‫ عنوان URL الأساسي أثناء التطوير في هذا المقال
# CSRF_TRUSTED_ORIGINS = ['https://*.railway.app']

احفظ بعد ذلك إعداداتك وثبّتها في مستودع غيت هب. ستحدّث Railway تطبيقَك وتعيد نشره تلقائيًا.

git add -A
git commit -m 'Update ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS with site URL'
git push origin main

تجهيز وتوصيل قاعدة بيانات Postgres SQL

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

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

اختر قاعدة البيانات Database عندما يُطلَب منك تحديد نوع الخدمة المراد إضافتها كما يلي:

اختر بعد ذلك خيار الإضافة Add PostgreSQL لبدء إضافة قاعدة البيانات:

ستجهز Railway بعد ذلك خدمةً تحتوي على قاعدة بيانات فارغة في المشروع نفسه، وسترى عند الانتهاء كلًا من خدمات التطبيق وقاعدة البيانات في عرض المشروع كما يلي:

اختر خدمة PostgreSQL لعرض معلومات حول قاعدة البيانات، ثم افتح نافذة "الاتصال Connect" وانسخ "عنوان URL لاتصال Postgres"، وهو العنوان الذي ضبطنا موقع المكتبة المحلية locallibrary لقراءته بوصفه متغير بيئة.

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

أدخِل اسم المتغير DATABASE_URL وعنوان URL للاتصال الذي نسخته لقاعدة البيانات، وسيظهر لديك ما يلي:

حدّد زر الإضافة Add لإضافة المتغير، ثم سيُعاد نشر المشروع.

إذا فتحت المشروع الآن، فسيُعرَض تمامًا كما عُرِض محليًا، ولكن لاحظ أنه لا توجد طريقة لملء المكتبة بالبيانات حتى الآن، لأننا لم ننشئ حساب مستخدم مميز Superuser بعد، إذ سنفعّل ذلك باستخدام أداة CLI على حاسوبنا المحلي.

تثبيت العميل

نزّل وثبّت عميل Railway لنظام تشغيلك المحلي باتباع التعليمات الواردة في توثيق Railway.

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

يمكنك الحصول على قائمة بجميع الأوامر من خلال إدخال الأمر التالي في الطرفية:

railway help

ملاحظة: سنستخدم في القسم التالي الأمرين railway login و railway link لربط المشروع الحالي بمجلدٍ ما، وإذا سجّل النظام خروجك، فيجب استدعاء كلا الأمرين مرةً أخرى لإعادة ربط المشروع.

ضبط مستخدم مميز

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

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

railway login

اربط مجلد locallibrary الحالي بمشروع Railway المرتبط به باستخدام الأمر التالي بعد تسجيل الدخول. لاحظ أنه يجب تحديد أو إدخال مشروع معين عندما يُطلَب منك ذلك:

railway link

ربطنا المجلد المحلي والمشروع، ويمكنك الآن تشغيل مشروع جانغو المحلي مع إعدادات من بيئة الإنتاج، ولكن تأكّد أولًا من أن بيئة تطوير جانغو العادية جاهزة، ثم استدعِ الأمر التالي مع إدخال الاسم والبريد الإلكتروني وكلمة المرور المطلوبة:

railway run python manage.py createsuperuser

ينبغي أن تكون الآن قادرًا على فتح منطقة مدير موقعك https://[your-url].railway.app/admin/‎ وملء قاعدة البيانات كما تعلمنا في مقال موقع مدير جانغو.

إعداد متغيرات الضبط

يجب الآن أن نجعل الموقع آمنًا، إذ يجب تعطيل تسجيل تنقيح الأخطاء وضبط مفتاح CSRF السري، إذ عملنا مسبقًا في هذا المقال على قراءة القيم المطلوبة من متغيرات البيئة DJANGO_DEBUG و DJANGO_SECRET_KEY.

افتح شاشة المعلومات الخاصة بالمشروع، وحدّد نافذة المتغيرات Variables التي يجب أن تحتوي على DATABASE_URL كما يلي:

هناك العديد من الطرق لتوليد مفتاح سري مُعمَّى، ولكن توجد طريقة بسيطة وهي تشغيل أمر بايثون التالي على حاسوبك الخاص بالتطوير:

python -c "import secrets; print(secrets.token_urlsafe())"

حدّد زر متغير جديد New Variable وأدخِل المفتاح DJANGO_SECRET_KEY مع قيمتك السرية، ثم اضغط إضافة Add. أدخِل بعد ذلك المفتاح DJANGO_DEBUG مع القيمة False، إذ يجب أن يبدو الضبط النهائي للمتغيرات كما يلي:

تنقيح الأخطاء Debugging

يوفّر عميل Railway الأمر logs لإظهار السجلات الأخيرة (يتوفر سجل كامل على الموقع لكل مشروع):

railway logs

اطلع على توثيق جانغو لمعلومات أكثر.

الخلاصة

وصلنا إلى نهاية مقالنا حول إعداد تطبيقات جانغو في بيئة الإنتاج، وكذلك إلى نهاية سلسلة مقالات إطار عمل جانغو، لذا نأمل أنها كانت مفيدة لك، ولا تنسَ أنه يمكنك التحقق من النسخة الكاملة من الشيفرة المصدرية على غيت هب GitHub.

ترجمة -وبتصرُّف- للمقال Django Tutorial Part 11: Deploying Django to production.