ربط مستودع Docker

أنشئ مستودعاً خاصاً على alawadi.cloud، وارفع حزم Docker من GitHub Actions عبر OIDC، ثم انشرها على تطبيقك.

كل تطبيق على alawadi.cloud يعمل من حزمة Docker (container image) ترفعها إلى مستودع خاص (private registry) على registry.alawadi.cloud. تُنشئ المستودع من لوحة التحكم، وتمنح مستودع GitHub صلاحية الرفع عبر OIDC (دون كلمات مرور ثابتة)، ثم تنشر الحزمة على تطبيق Docker. تشرح هذه الصفحة المسار كاملاً انطلاقاً من البوابة.

1. أنشئ مستودعاً

افتح لوحة التحكم ← Registries (‏/dashboard/registries) واضغط Create registry. املأ النافذة:

Name (مطلوب). مثلاً Production apps.

Slug (اختياري). يُشتَقّ من الاسم تلقائياً ويظهر مباشرةً في معاينة العنوان. عدّله فقط إن أردت مساراً مختلفاً. الـ slug غير قابل للتغيير بعد الإنشاء.

Project (اختياري). اربط المستودع بالمشروع الذي سيُشغّل حزمه. القيمة الافتراضية Link later، ويمكنك ربطه أو تغييره لاحقاً.

Storage (GiB): حصة تخزين الحزم (الافتراضي 1، المدى من 1 إلى 100).

اضغط Create. تتولّى المنصّة تعيين الباقي:

Address وImage namespace على registry.alawadi.cloud/<tenant>/<slug>. لا تكتب أنت المضيف ولا المسار.
تنتقل حالة المستودع (Status) من provisioning إلى ready.

تظهر القيمتان في صفحة تفاصيل المستودع (‏/dashboard/registries/<id>) ضمن بطاقة Overview، ولكلٍّ منهما زر نسخ. استخدم Edit settings هناك لإعادة التسمية أو تغيير حجم التخزين أو ربط مشروع (يبقى الـ slug ثابتاً).

2. امنح صلاحية الرفع (GitHub Actions OIDC)

في صفحة تفاصيل المستودع، اعثر على بطاقة Push setup (GitHub Actions OIDC) واملأ نموذج التفويض:

GitHub repository (مطلوب)، بصيغة owner/repo.

Branch ref (مطلوب). مُعبّأ مسبقاً بـ refs/heads/main، ويجب أن يبدأ بـ refs/.

Environment (اختياري). اتركه فارغاً ما لم تكن تستخدم GitHub Environments. عند تعيينه، يجب أن تتضمّن مهمة workflow السطر environment: <name>.

اضغط Configure trust (يتحوّل بعدها إلى Update trust / Remove trust). تعرض البطاقة قيمة OIDC Audience التي عيّنها المستودع للقراءة فقط. لن تكتبها أنت بيدك.

لا كلمات مرور إطلاقاً

يجري التحقّق عند الرفع برمز قصير العمر مُشتَقّ من هوية OIDC في GitHub (‏docker login registry.alawadi.cloud -u oidc --password-stdin). لا توجد كلمات مرور ثابتة للمستودع، ولا حسابات روبوت، ولا بيانات اعتماد Docker Hub تُنشئها أو تخزّنها.

تعرض البطاقة نفسها مقطع .github/workflows/push.yml جاهزاً، مُعبّأً مسبقاً بالعنوان الحقيقي وقيمة audience وREGISTRY_ID. اضغط Copy وأضِفه إلى مستودعك إن كنت تريد رفع الحزم فقط. الرفع وحده لا يُنفِّذ النشر. للنشر المستمر، استخدم قوالب workflow أدناه.

3. انسخ workflow النشر

انزل إلى بطاقة CI workflow templates. تُولّد ملف .github/workflows/deploy.yml كاملاً يبني تطبيقك، ويرفع الحزمة هنا، ثم ينشرها على تطبيق Docker.

اختر بيئة التشغيل (runtime). تبويبات لـ Node · Express وNext.js · React وPython · FastAPI وPython · Django وGo وPHP · Laravel وJava · Spring Boot وRust وStatic · Vite. تعرض البطاقة لكل بيئة App port (دائماً 8080) وHealth endpoint ومتغيّرات البيئة المتوقّعة (Env vars).

اختر وجهة النشر من قائمة Deploy target. القائمة هي تطبيقاتك، مُرشَّحة حسب المشروع المربوط بالمستودع. إن كانت فارغة، أنشئ تطبيقاً أولاً.

فعّل تفويض النشر. راقب الشارة بجانب القائمة: Deploy trust configured (خضراء) أو Deploy trust required (كهرمانية). إن كانت مطلوبة، اضغط Configure deploy trust. تكفي ضغطة واحدة تعيد استخدام مستودع GitHub وbranch ref والـ environment المعرّفة في المستودع، فلا شيء تعيد كتابته. تتحوّل الشارة إلى configured ويصبح الزر Refresh deploy trust.

اضغط Copy workflow. الملف مُولَّد بالكامل للتطبيق المختار: IMAGE وPUSH_AUDIENCE وCONTAINER_ID وDEPLOY_AUDIENCE (‏alawadi-deploy:container:<CONTAINER_ID>) كلها مُعبّأة. التعديلات الوحيدة المطلوبة هي متغيّرات البناء الخاصة بكل بيئة، المعروضة كتعليقات داخل الملف (وDOCKERFILE إن لم يكن في جذر المستودع).

ضَع الملف في .github/workflows/deploy.yml، عدّل تلك المتغيّرات، ثم نفّذ commit وارفع إلى main.

إن لم يكن في مستودعك ملف Dockerfile بعد، وسّع Supporting Dockerfile واضغط Copy Dockerfile. كل ملف يستمع على 8080، ويعمل بمستخدم غير جذر (non-root)، ويثبّت حزمة الأساس على إصدار رئيسي، جاهزاً لسياسة الأمان المُقيّدة في المنصّة.

يلزم تفويضان

يسمح تفويض الرفع (الخطوة 2) لـ GitHub برفع الحزمة؛ ويسمح تفويض النشر (الخطوة 3) للمستودع نفسه بنشرها على تطبيق واحد. الرفع إلى المستودع لا يُنفِّذ النشر وحده؛ يجب توفّر التفويضين معاً.

ماذا يحدث عند الرفع

عند تنفيذ الـ workflow، فإنه:

يسجّل الدخول إلى registry.alawadi.cloud برمز OIDC (دون كلمة مرور).
يبني ويرفع IMAGE:<commit-sha>. ويضبط BUILDX_NO_DEFAULT_ATTESTATIONS=1 لأنّ المستودع يرفض manifest الـ attestation الافتراضي الذي يضيفه GitHub عند البناء.
يُصدِر رمز نشر قصير العمر من رمز OIDC ثانٍ (بـ audience يساوي DEPLOY_AUDIENCE) ثم يُرسِل الحزمة (POST) إلى تطبيقك.

راقب وسوم الحزم المرفوعة وهي تظهر في بطاقة Images (تتحدّث تلقائياً مع مؤشّر Live، حيث يمكنك نسخ مرجع سحب أو حذف وسوم)، وتابع عملية النشر في بطاقة Deploy history وعلى الخط الزمني للتطبيق.

ثبّت وسوم الحزم

يُوسِم الـ workflow المُولَّد الحزم بـ commit SHA لا بـ :latest. أبقِها هكذا: ترفض المنصّة :latest والحزم بلا وسم، حتى تستخدم إعادةُ النشر دائماً الحزمة نفسها التي بنيتها بالضبط.

متقدّم: ضبط التفويض من CI (عبر الـ API)

النماذج في البوابة أعلاه هي المسار الأساسي. وإن كنت تؤتمِت إعداد المستودع أو التفويض من سكربتاتك الخاصة، فالعمليات نفسها متاحة على الـ API. تفويض رفع المستودع:

# ضبط (أو تحديث) تفويض الرفع لمستودع
curl -sS -X PUT \
  "https://api.alawadi.cloud/v1/registries/$REGISTRY_ID/github-oidc-trust" \
  -H "Authorization: Bearer $PORTAL_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repository":"owner/repo","ref":"refs/heads/main"}'

يتّبع تفويض نشر التطبيق الصيغة نفسها. راجع النشر من GitHub عبر OIDC لتبادُل رمز النشر (deploy token) ولطلب النشر الذي يُرسِله الـ workflow في كل تنفيذ.