نشر تطبيق Docker

في تمرين Dockerfile، قمت ببناء صورة (image) وتشغيل التطبيق باستخدام docker run. إذا أكملت التمرين الاختياري Compose-øvelsen، يمكنك استخدام Compose بدلاً من ذلك. هنا ستقوم بجعل نفس التطبيق يستجيب عبر اسم نطاق DNS ووكيل وسيط متاح. يمكنك استخدام تطبيقك الخاص أو تطبيق الاختبار من تمرين Dockerfile.

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

عند تشغيل تطبيق Flask على خادم مع منفذ محدد، يمكن لـ الوكيل العكسي استقبال طلبات نيابةً عن التطبيق وإرسالها إلى الحاوية الصحيحة. وبالتالي، يمكن للمستخدم استخدام اسم نطاق بدلاً من عنوان IP ورقم المنفذ. تحتاج إلى اسم DNS ووكيل وسيط لديك صلاحية تكوينه، وشهادة إن كان يجب أن يستخدم الخدمة HTTPS.

يعيد DNS الإجابات بالعنوان ولا ينقل صفحات الويب. في الشكل، يُنهي الوكيل اتصال HTTPS ويستخدم HTTP لاحقًا داخل شبكة داخلية محدودة النطاق. يستلم المتصفح الاستجابة عبر الوكيل.

قبل أن تبدأ

تحتاج إلى حاوية تعمل من تمرين ملف Dockerfile (أو تمرين Compose) والمعلومات التالية من بيئة الاختبار:

• عنوان IP لآلة افتراضية للتطبيق (APP-VM-IP): عنوان الآلة الافتراضية التي يعمل عليها التطبيق؛ يُستخدم هنا المنفذ 5000.
• عنوان الوكيل (PROXY-IP): العنوان الذي يجب على العميل الوصول إليه عبر الوكيل، مع استخدام بروتوكول HTTP على المنفذ 80.
• اسم التطبيق (APP-NAVN): اسم نطاق DNS يشير إلى الوكيل. يمكن أن يكون التطبيق والوكيل على آلات افتراضية مختلفة.

يُعدّ الوصول لإنشاء ضيف وكيل (Proxy Host) في مدير وكلاء Nginx والسماح بالاتصال من الوكيل إلى التطبيق ضروريًا. يجب استبدال القيم الموضحة أعلاه بقيمك الخاصة. إذا لم يكن الوصول إلى DNS أو الوكيل متاحًا، قم بإجراء الاختبار المحلي وشرح الشكل التوضيحي. لن يؤدي ذلك إلى إكمال اختبار النشر.

1. اختبر التطبيق محليًا

اعمل في مجلد المشروع على جهاز افتراضي للتطبيق. تستخدم الأوامر أدناه اسم الحاوية min-app من تمرين ملف Dockerfile. مع ربط المنفذ من هناك، يجب أن يعطي هذا الاختبار الصفحة الرئيسية:

docker ps
curl --fail --show-error http://127.0.0.1:5000/

يمكنك استخدام /status كنقطة تحكم ثابتة. إذا لم تكن هذه المسار موجودة مسبقًا، أضفها بعد دوال المسارات الكاملة الأخرى وقبل if __name__ == "__main__": في app.py:

No translation needed

البناء، بدء التشغيل واختبار مرة أخرى:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

إذا كنت تستخدم Compose، استبدل أوامر الثلاثة الأولى بـ docker compose up -d --build.

توقّع استجابة HTTP 200 مع كائن JSON يحتوي على "status": "ok". إذا كانت التطبيق لديه بالفعل مسار /status، استخدم الاستجابة الموثقة الموجودة هناك بدلاً من إنشاء مسار جديد بنفس الاسم. هذا يتحقق من المسار فقط وليس جميع وظائف التطبيق.

2. اجعل التطبيق متاحًا للوسيط (Proxy)

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

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

إذا كنت تستخدم Compose، استبدل بدلاً من ذلك سطر المنفذ تحت app في compose.yaml بـ "APP-VM-IP:5000:5000" وشغّل الأمر docker compose up -d.

شغّل الاختبار على جهاز افتراضي التطبيق ومن بيئة شبكة الوكيل (proxy)، أو من عميل اختبار مع نفس الوصول المسموح به. يتم التحقق أيضاً من اتصال الوكيل الفعلي باستخدام الاسم في القسم التالي. بعد تغيير الربط، اختبر عنوان الجهاز الافتراضي وليس 127.0.0.1. لا تفتح المنفذ أمام الإنترنت بالكامل. يوفر الترتيب [التجزئة المستوى 1 - VLAN وتجزئة الشبكة | التجزئة] دعماً لقاعدة الوصول.

من النطاق إلى الحاوية

تحدث عدة أشياء عندما يفتح المستخدم اسمًا مثل https://app.example.test. هذا مثال على الاسم؛ استبدله بالاسم الفعلي المُعد في بيئة الاختبار لديك:

sequenceDiagram
    participant B as متصفح الويب
    participant D as DNS
    participant P as مدير بروكسي Nginx
    participant F as حاوية Flask

    B->>D: ابحث عن عنوان IP للنطاق
    D-->>B: عنوان IP للبروكسي
    B->>P: طلب إلى النطاق
    P->>P: حدد مضيف البروكسي الصحيح
    P->>F: إعادة التوجيه إلى المنفذ الداخلي 5000
    F-->>P: إرجاع صفحة HTML
    P-->>B: إرجاع الاستجابة

لذلك من الحكمة اختبار طبقة واحدة في كل مرة، بدلاً من محاولة تصحيح أخطاء نظام أسماء النطاقات (DNS) والخادم الوسيط وFlask في نفس الوقت.

مدير وكيل نينكس (Nginx Proxy Manager)

مدير وكيل نينكس هو واجهة ويب لنينكس. هنا، تستخدم تثبيتًا متاحًا وتُنشئ مضيف وكيل واحد (Proxy Host). لا تحتاج إلى تثبيت وكيل جديد لكل تطبيق.

أنشئ مضيف وكيل:

1. اكتب اسم التطبيق، وهو الاسم الفعلي المُضبط للخدمة.
2. اختر http كبروتوكول للاتصال من مدير وكيل نينكس إلى الحاوية.
3. اكتب عنوان IP لحاوية التطبيق كمضيف إعادة التوجيه. يعني 127.0.0.1 داخل حاوية الوكيل حاوية الوكيل نفسها.
4. اكتب المنفذ المنشور للحاوية، على سبيل المثال 5000.
5. احفظ وافتح http://اسم التطبيق/status من العميل.

يجب أن يُحلّ اسم المضيف إلى عنوان IP للوكيل. يمكنك التحقق من عملية الحل باستخدام nslookup اسم التطبيق على جهاز العميل. يجب أن تعطي اختبار HTTP نفس رد الحالة الذي يعطيه الاختبار المباشر. ظهور الصفحة الافتراضية للوكيل لا يدل على أن الطلب وصل إلى التطبيق.

إعادة الانتخاب: HTTPS

عندما يعمل بروتوكول HTTP ولديك شهادة صالحة للاسم، افتح تبويب SSL، واختر الشهادة واختبر https://APP-NAVN/status. لا يمكن لاسم مثال داخلي مثل app.example.test الحصول على شهادة عامة من Let’s Encrypt؛ في هذه الحالة تحتاج إلى شهادة من جهة إصدار داخلية تثق بها العميل. رفع سجلات نظام أسماء النطاقات (DNS) وحدها لا يُعدّل إعدادات HTTPS. المسار الأساسي لـ HTTP هو تدريب محلي؛ عند معالجة تسجيل الدخول أو أي بيانات أخرى تستحق الحماية، ستحتاج إلى HTTPS.

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

إعادة انتخاب وكيل: وكيل خاص

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

استكشاف الأخطاء وإصلاحها

docker ps
docker logs -f min-app
ss -tulpn

إذا كنت تستخدم Compose، فإن أول أمرين هما docker compose ps و docker compose logs -f. نفّذ الأوامر واحدًا تلو الآخر على جهاز افتراضي للتطبيق (app-VM). أنهِ الأمر logs -f باستخدام Ctrl+C. يُظهر الأمر ps حالة الحاويات، بينما تُعرض رسائل التطبيق في السجلات، ويمكن لـ ss تقديم دعم لفحص المنافذ المستمعة إليها. استخدم نتيجة الاختبار المحدد عبر بروتوكول HTTP للتحقق من الوصول.

اختبر بالترتيب التالي:

1. على جهاز تطبيق VM بعد تغيير الربط: curl --fail --show-error http://APP-VM-IP:5000/status.
2. من بيئة شبكة الوكيل: نفس العنوان والمنفذ والمسار. قد تكون لدى عميل عشوائي قواعد وصول مختلفة.
3. من العميل من خلال الاسم: nslookup APP-NAVN، ثم http://APP-NAVN/status. اختبر HTTPS بشكل منفصل إذا كان مُهيأً.

إذا فشل البند 1، افحص التطبيق وحالة الحاضنة والعنوان وربط المنفذ. إذا عمل البند 1 وفشل البند 2، افحص الاتصال وقواعد الوصول من الوكيل. إذا عمل البند 2 وفشل البند 3، افحص DNS ومضيف الوكيل والبروتوكول المختار. يعني خطأ HTTP 404 أن خادم HTTP استجاب لكن المسار قد يكون خاطئًا؛ أما الخطأ 502 من الوكيل فيشير إلى مشكلة في الاتصال أو الاستجابة من التطبيق. دوّن ما يحدده الاختبار قبل إجراء أي تعديلات.

الخطوات التالية

اعرض استجابة الحالة من خلال الاسم، ووضّح الفرق بين الاستعلام عن نظام أسماء النطاقات (DNS) وإعادة التوجيه عبر الوكيل (Proxy). يُشار أيضاً إلى العميل والوكيل والتطبيق في الشكل أو رسم توضيحي منفصل. يمكنك الشرح شفهياً أو كتابياً. حدّد عنوان الاختبار والاستجابة المتوقعة/الفعليّة وما إذا كنت قد جرّبت بروتوكول HTTP أم HTTPS. عند وجود انحراف، استخدم ترتيب الاختبارات المذكور أعلاه قبل المتابعة.

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

المصادر: Docker: ربط المنفذ، وNginx Proxy Manager، وFlask: المسارات والاستجابات.