النشر¶

تستخدم جميع خدمات المنظومة نموذج نشر واحدًا، وتصفه هذه الصفحة.

لا تفاصيل خاصة بالمضيفات هنا

التفاصيل التشغيلية — عناوين الخوادم وأسماء المستخدمين والإعدادات السرّية — ليست جزءًا من هذا الموقع العام، بل توجد في دليل تشغيل مغلق داخل المستودع المعني.

النموذج العام¶

        Internet
            │
            ▼
   ┌─────────────────┐
   │   edge nginx    │  TLS termination · HSTS · rate limit
   │   (container)   │  each vhost → an internal service
   └────────┬────────┘
            │  shared Docker network
   ┌────────┴──────────────────────────────┐
   │                                       │
   ▼                ▼                      ▼
 app A            app B                 static site
 (Go + Next)     (Go + Next)            (nginx)
   │                │
   └────────┬───────┘
            ▼
   PostgreSQL · Redis  (shared)

المبادئ الأساسية:

حافّة واحدة وعدّة مضيفات افتراضية. في الخارج تملك حاوية nginx واحدة المنفذين 80/443. ولكل نطاق كتلة server خاصة به تُمرّر الطلب إلى خدمة داخلية.
الخدمات الداخلية غير مكشوفة للخارج. فالتطبيقات لا تستمع إلّا على شبكة Docker المشتركة، أو ترتبط بـ 127.0.0.1. ولا سبيل إلى بلوغها من الخارج مباشرةً.
بنية تحتية مشتركة. نسخة واحدة من PostgreSQL وأخرى من Redis تخدمان عدّة تطبيقات؛ ولكل تطبيق قاعدته أو مخطّطه الخاص.
Docker Compose — لكل تطبيق حزمة compose خاصة به، موصولة بالشبكة المشتركة.

حافّة nginx¶

تتولّى الحافّة ما يلي:

الدور	التفصيل
إنهاء TLS	شهادات Let's Encrypt مع تجديد تلقائي
HSTS	`max-age=63072000; includeSubDomains`
تحديد المعدّل	بحسب النطاق: `auth` (صارم) · `app` (مرن) · `api`
وكيل عكسي	مضيف افتراضي ← خدمة داخلية
رفض المضيفات المجهولة	خادم افتراضي ← قطع الاتصال

إعدادات الحافّة تُدار عبر git

يُزامَن مجلّد conf.d الخاص بـ edge nginx من مستودع محدَّد عبر git. وأي تعديل يدوي على المضيف سيُطمَس بأمر git reset --hard عند النشر التالي.

ولذلك تتمّ إضافة أي مضيف افتراضي أو تعديله بـإيداع تغيير في المستودع، ويتولّى التكامل المستمر توزيعه.

نموذج ثانٍ — أن تملك الخدمة مضيفها الافتراضي

ثمّة نموذج آخر يوضع فيه المضيف الافتراضي الذي يخصّ خدمةً واحدة في مستودع تلك الخدمة لا في ملف مركزي، ويتولّى نشرُها تثبيتَ الإعداد في conf.d الخاص بالحافّة بوصفه ملفًّا مستقلًّا.

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

وهذا الموقع يعمل بهذا النموذج بالضبط — راجع منصّة هذه الوثائق.

الشهادات¶

Let's Encrypt عبر certbot بوضع webroot.
ويُخدَم تحدّي ACME على المنفذ 80 عبر المسار /.well-known/acme-challenge/.
والتجديد تلقائي أسبوعيًا عبر cron؛ وعند نجاحه يُعاد تحميل nginx.

ولإضافة نطاق جديد:

وجّه سجلّ DNS إلى الخادم.
أضف النطاق إلى كتلة ACME على المنفذ 80.
احصل على الشهادة عبر certbot.
أضف المضيف الافتراضي لـ HTTPS وأشِر فيه إلى الشهادة.
نفّذ nginx -t ثم أعد التحميل.

المواقع الساكنة (بوابات الوثائق)¶

مواقع الوثائق هي HTML ساكن مبنيّ مسبقًا. وأبسط نموذج لتشغيلها:

بناء site/ بـ MkDocs،
نسخ الناتج إلى الخادم،
تقديمه بحاوية صغيرة من nginx:alpine،
وتمرير الطلبات إليها من edge nginx.

ولمّا لم يكن ثمّة زمن تشغيل للتطبيق، قلّت الموارد وقلّ ما يمكن أن يتعطّل.

وهذا الموقع يعمل على هذا النحو تمامًا — للتفاصيل راجع منصّة هذه الوثائق.

نشر التطبيقات¶

يُستعمل نموذجان في التطبيقات:

النموذج	التفصيل
البناء على المضيف	يُزامن التكامل المستمر المستودعَ إلى المضيف ويشغّل `docker compose build && up -d`
عبر سجل الصور	يبني التكاملُ المستمر الصورةَ ويدفعها إلى registry، ثم ينفّذ المضيف `pull && up -d`

والاتّجاه العام نحو تقليص الاعتمادات — إذ انتقلت بعض الحالات من سجل صور خارجي إلى البناء على المضيف مباشرةً.

النشر الجزئي: يحدّد التكامل المستمر الخدماتِ الواجب إعادة بنائها انطلاقًا من المسارات المتغيّرة (paths-filter). فتغييرٌ في تطبيقٍ لا يمسّ سواه.

التراجع¶

الموقع الساكن — فكّ أرشيف البناء السابق واستعادته.
التطبيق — العودة إلى وسم الصورة السابق (ويمكن تثبيته بمتغيّر <SVC>_IMAGE_TAG).

فحوص السلامة¶

لكل خدمة نقطة نهاية /health. وتتحقّق تعريفات healthcheck في compose من جهوزية البنية التحتية مثل PostgreSQL وRedis، ولا تُشغّل التطبيق إلّا بعد جهوزيتها.

قائمة تحقّق النشر¶

[ ] توجيه DNS صحيح
[ ] الشهادة صادرة ومشمولة بالتجديد التلقائي
[ ] إضافة المضيف الافتراضي للحافّة وإيداعه في المستودع
[ ] نجاح nginx -t
[ ] عدم كشف الخدمات الداخلية للخارج
[ ] استجابة /health
[ ] الأسرار عبر متغيّرات البيئة وغيابها عن المستودع
[ ] وضوح طريقة التراجع

ولتفاصيل الأتمتة راجع CI/CD.