CONTAINER APPS · دليل
النشر من Git
أشر إلى مستودع git يحتوي على docker-compose.yml. نقوم باستنساخه، ونبني صورة كل خدمة على بنيتنا التحتية الخاصة — لا تحتاج إلى سجل حاويات (container registry) — ثم ننشر المكدس بالكامل، متصلاً ببعضه، على منصة الحاويات المُدارة CDN.com.tr. إنه أسرع طريق من «مستودعي» إلى «يعمل في الإنتاج (production)».
مستودع يحتوي على docker-compose.yml. الخدمات التي تحتوي على قسم build: تُبنى من ملف Dockerfile الخاص بها؛ أما الخدمات التي تشير إلى image: عام (قواعد بيانات، ذواكر تخزين مؤقت، طوابير) فتُستخدم كما هي وتُربط كإضافات أو تطبيقات مُدارة. هذا كل شيء — لا حاجة لحساب سجل، ولا رفع صور (image push)، ولا إعداد CI.
1 · افتح "Deploy from Git"
في حسابك على CDN افتح المنصات → Container Apps، وسّع App creation، ثم انقر على Deploy from Git (بجانب Import from Docker Compose).
2 · أدخل بيانات مستودعك
- رابط المستودع — رابط الاستنساخ
https://، مثلhttps://github.com/your-org/your-app.git. - الفرع (Branch) — الفرع المراد نشره (الافتراضي
main). - ملف Compose — مسار ملف compose داخل المستودع (الافتراضي
docker-compose.yml). تُحلَّل سياقات البناء (build contexts) نسبةً إلى هذا الملف، لذا فإن وجود ملف compose في مجلد فرعي يعمل بشكل جيد.
3 · المستودعات الخاصة والوصول إليها
GitHub (موصى به): انقر على "Connect GitHub". يتيح لك تثبيت GitHub App بنقرة واحدة اختيار المستودعات من قائمة منسدلة — دون الحاجة لإنشاء رموز أو نسخها أو تدويرها، كما يشغّل هذا webhooks النشر التلقائي (الخطوة 5). تختار بنفسك أي المستودعات يمكن لهذا التطبيق رؤيتها، ويمكنك إلغاء صلاحيته من GitHub في أي وقت.
كبديل — أو لاستخدام GitLab — فعّل خيار This is a private repository والصق رمز وصول (access token). امنحه أقل الصلاحيات التي يحتاجها فقط:
- GitHub — رمز وصول شخصي (Personal Access Token) دقيق النطاق (fine-grained) محصور بهذا المستودع فقط مع صلاحية Contents: Read-only.
- GitLab — رمز وصول للمشروع أو رمز وصول شخصي بنطاق read_repository.
يُستخدم الرمز الملصق فقط لاستنساخ مستودعك أثناء عملية البناء. يُخزَّن كقيمة تُكتب فقط طوال مدة البناء ولا يُعرض مجددًا أو يُعاد استخدامه أبدًا — يمكنك إلغاءه في أي وقت.
4 · ابنِ وانشر (Build & deploy)
انقر على Build & deploy. يعرض شريط تقدم مباشر كل خطوة:
- قراءة compose — نستنسخ مستودعك ونحلل ملف compose.
- بناء <الخدمة> — تُبنى صورة كل خدمة تحتوي على
build:من ملف Dockerfile الخاص بها في بيئة بناء معزولة (sandboxed builder)، ثم تُدفع إلى سجلنا الخاص. - النشر (Deploying) — تتحول كل خدمة إلى تطبيق حاوية (container app)، متصلة بالأخريات باسم الخدمة (تمامًا مثل
docker-compose)، مع ربط قواعد البيانات/ذواكر التخزين المؤقت.
عند الانتهاء، تُنشر الخدمات التي تواجه الويب تلقائيًا على نطاق فرعي فوري <uid>.cdn.com.tr (يمكنك ربط نطاقك الخاص في أي وقت) — افتح Your apps لرؤيتها وهي تعمل.
5 · ابقَ متصلاً — النشر التلقائي وخط الأنابيب النشري
فعّل خيار "Keep connected — auto-deploy on every push to this branch" قبل النشر. من تلك اللحظة، كل دفعة (push) إلى الفرع تعيد البناء والنشر تلقائيًا — وتظهر بطاقة خط الأنابيب النشري (Deployment pipeline) في Container Apps:
- فعّل بيئة الاختبار (Enable staging) على البطاقة، فتقوم عمليات الدفع بنشر نسخة اختبار Staging (على رابط اختبار خاص بها) بدلاً من الإنتاج — لا يتغير الإنتاج إلا عند نقرك على الترقية (Promote)، مع إمكانية التراجع بنقرة واحدة.
- هذه هي الطريقة الموصى بها لتشغيل مستودع متصل: لا مزيد من «كل commit يعيد نشر الإنتاج».
شرح كامل: خط الأنابيب النشري — دفع (push) → Staging، الترقية (Promote) → Production.
كيف يعمل (ولماذا هو آمن)
- نبني صورك من ملفات Dockerfile الخاصة بك — دون الحاجة لحساب سجل. تُحترم عمليات البناء متعددة المراحل (multi-stage builds) و
target:وbuild.args. - بناء وتشغيل معزولان. يعمل كل من البناء والحاويات قيد التشغيل ضمن بيئة معزولة (sandbox) مُحصّنة بتقنية gVisor، معزولة عن المستأجرين الآخرين وعن المضيف.
- اكتشاف الخدمات (Service discovery) — تصل التطبيقات في حسابك إلى بعضها باسم الخدمة، تمامًا مثل compose. تُوفَّر قواعد البيانات وRedis وNATS كإضافات مُدارة.
- انشر بأمان. ادمج هذا مع Blue/Green preprod لاختبار نسخة على رابطها الخاص قبل تفعيلها فعليًا.