تعلّم نشر 12 تطبيقًا على AWS وAzure وGoogle Cloud باستخدام Docker

مقدمة: لماذا يُعد Docker خيارًا ذكيًا للنشر السحابي؟

يساعد Docker على توحيد بيئة التشغيل، بحيث يعمل التطبيق بالطريقة نفسها على جهاز المطور أو الخادم أو المنصة السحابية. وهذا يقلّل مشاكل التوافق، ويجعل عملية النشر أسرع وأكثر موثوقية، خاصة عند التعامل مع خدمات مثل AWS وAzure وGoogle Cloud.

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

ما الذي ستتعلمه في هذه الدورة؟

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

أنواع التطبيقات التي تشملها الدورة

• تطبيق React
• تطبيق Node.js
• تطبيق Vue.js
• تطبيق NestJS
• تطبيق Angular
• تطبيق Golang
• تطبيق Svelte
• تطبيق Django
• تطبيق Laravel
• تطبيق .NET Core
• تطبيق Spring Boot مع Kotlin
• تطبيق Deno

المنصات السحابية المستهدفة

• AWS
• Azure
• Google Cloud

الفكرة الجوهرية: من بناء التطبيق إلى نشر الحاوية

يركّز الشرح على مسار متكرر يمكن تطبيقه على معظم المشاريع:

1. إنشاء ملف Dockerfile.
2. اختيار صورة أساسية مناسبة مثل node أو python أو golang.
3. نسخ ملفات الاعتماديات أولًا مثل package.json أو requirements.txt.
4. تثبيت الحزم المطلوبة.
5. نسخ بقية ملفات المشروع.
6. تنفيذ أمر البناء مثل npm run build أو dotnet publish.
7. تشغيل التطبيق محليًا عبر الحاوية.
8. رفع الصورة إلى سجل حاويات سحابي.
9. إنشاء خدمة تشغيل على المنصة المختارة.

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

لماذا يُفضَّل استخدام البناء متعدد المراحل؟

في كثير من التطبيقات، لا تحتاج في بيئة الإنتاج إلى كل ملفات المصدر وأدوات البناء. لذلك يُستخدم أسلوب Multi-stage Build داخل Dockerfile لبناء التطبيق في مرحلة أولى، ثم نسخ الملفات النهائية فقط إلى صورة أخف وأسرع.

فوائد هذا الأسلوب

• تقليل حجم صورة Docker.
• تحسين سرعة الرفع والتنزيل.
• تقليل سطح الهجوم الأمني.
• تسريع الإقلاع في بيئات الإنتاج.
• فصل مرحلة البناء عن مرحلة التشغيل.

تطبيقات الواجهة الأمامية: React وVue وAngular وSvelte

في تطبيقات الواجهة الأمامية، يكون النمط الشائع هو بناء ملفات ثابتة مثل HTML وCSS وJavaScript، ثم تقديمها عبر خادم خفيف مثل nginx.

كيف تتم العملية عادة؟

1. استخدام صورة node لتثبيت الاعتماديات.
2. تشغيل أمر البناء مثل npm run build.
3. نسخ مجلد الإخراج مثل build أو dist.
4. وضع الملفات داخل خادم nginx.

هذا الأسلوب مناسب جدًا لتطبيقات SPA لأنه يفصل بين أدوات التطوير وبيئة العرض النهائية.

أهمية ملف إعداد nginx

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

تطبيقات الخلفية: Node.js وNestJS وDjango وLaravel وDeno

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

• ضبط المنفذ مثل 80 أو أي منفذ آخر.
• السماح للتطبيق بالاستماع على العنوان 0.0.0.0.
• تثبيت اعتمادات الإنتاج فقط عند الإمكان.
• تقليل المكونات غير الضرورية داخل الصورة.

مثال منطقي على تطبيق Node.js

يمكن إنشاء تطبيق بسيط باستخدام Express يعيد رسالة Hello World، ثم تشغيله داخل حاوية عبر أمر مثل node index.js. ورغم بساطة المثال، فإنه يوضّح الهيكل الأساسي لأي خدمة خلفية قابلة للنشر.

مثال منطقي على NestJS

في حالة NestJS، غالبًا يتم بناء المشروع إلى مجلد dist، ثم تشغيل نسخة إنتاج أخف تحتوي فقط على ملفات التنفيذ واعتماديات الإنتاج. وهذه من أفضل الحالات التي يظهر فيها أثر Multi-stage Build.

تطبيقات Django وLaravel

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

تطبيق Deno

يمتاز Deno ببنية تشغيل مبسطة، إذ يمكن تشغيل الملف مباشرة مع الأذونات المناسبة مثل --allow-net. وهذا يجعله خيارًا واضحًا في المشاريع الصغيرة أو الأدوات السريعة.

التطبيقات المترجمة: Golang و.NET Core وSpring Boot مع Kotlin

هذا النوع من التطبيقات يستفيد كثيرًا من الحاويات لأن الناتج النهائي غالبًا يكون ملفًا تنفيذيًا أو حزمة جاهزة للتشغيل.

تطبيق Golang

بعد تحميل الاعتماديات عبر go mod download، يمكن بناء التطبيق بأمر go build ثم تشغيل الملف الناتج مباشرة. ويُعد هذا المسار من أكثر المسارات كفاءة من حيث الأداء والحجم.

تطبيق .NET Core

في مشاريع .NET، يُستخدم غالبًا أمر dotnet publish لإنتاج ملفات قابلة للتشغيل في بيئة الإنتاج. ثم تُنقل مخرجات النشر فقط إلى صورة التشغيل النهائية لتقليل الحجم.

تطبيق Spring Boot مع Kotlin

يعتمد النشر عادة على بناء ملف JAR عبر Gradle أو Maven، ثم تشغيله بأمر java -jar. والميزة هنا أن الحاوية النهائية يمكن أن تكون بسيطة نسبيًا إذا احتوت فقط على بيئة JDK والملف الناتج.

اختبار الحاوية محليًا قبل النشر

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

ما الذي يجب التحقق منه؟

• أن الصورة بُنيت بنجاح عبر docker build.
• أن الحاوية تعمل عبر docker run.
• أن ربط المنافذ تم بشكل صحيح.
• أن التطبيق يستجيب من المتصفح أو عبر طلب HTTP.
• أن ملفات الإنتاج موجودة في المسار الصحيح.

النشر على AWS: من السجل إلى الخدمة

يعتمد المسار المعروض على رفع الصورة إلى Elastic Container Registry ثم تشغيلها عبر ECS Fargate. وهذه طريقة مناسبة لمن يريد تشغيل الحاويات دون إدارة خوادم بشكل مباشر.

الخطوات الأساسية على AWS

1. تثبيت AWS CLI.
2. تسجيل الدخول إلى ECR.
3. إنشاء مستودع للصورة.
4. تنفيذ docker tag ثم docker push.
5. إنشاء Cluster في ECS.
6. إنشاء Task Definition وربط المنفذ الصحيح.
7. إنشاء خدمة Fargate.
8. الوصول إلى عنوان الحاوية عبر Public IP.

الميزة الرئيسية هنا أن Fargate يخفف العبء التشغيلي، لأنه يدير الطبقة الأساسية للبنية بدلًا منك.

النشر على Azure: رفع الصورة وتشغيلها سريعًا

في Azure، تم استخدام Azure Container Registry لحفظ الصورة، ثم Container Instances لتشغيلها. وهذه طريقة مباشرة وسهلة للتطبيقات التي لا تحتاج بنية معقدة.

خطوات النشر على Azure

1. تثبيت Azure CLI.
2. إنشاء Container Registry.
3. تسجيل الدخول إلى السجل.
4. رفع الصورة باستخدام docker push.
5. إنشاء Container Instance.
6. ضبط المنفذ مثل 80.
7. الوصول إلى التطبيق عبر Public IP.

هذا المسار مناسب للتجارب السريعة، والعروض التوضيحية، وبعض التطبيقات الصغيرة والمتوسطة.

النشر على Google Cloud: مرونة جيدة بخطوات واضحة

في Google Cloud، يبدأ المسار برفع الصورة إلى Container Registry أو ما يعادله، ثم نشرها عبر Cloud Run. وتُعد هذه الخدمة من أسهل خدمات تشغيل الحاويات للمطورين.

خطوات العمل على Google Cloud

1. تثبيت Google Cloud SDK.
2. تسجيل الدخول باستخدام gcloud auth login.
3. تنفيذ docker tag باستخدام gcr.io.
4. رفع الصورة عبر docker push.
5. إنشاء خدمة داخل Cloud Run.
6. ضبط منفذ الحاوية بالشكل الصحيح.
7. السماح بالوصول العام إذا كان التطبيق عامًا.

يمتاز Cloud Run بسهولة النشر، وسرعة الإعداد، والقدرة على تشغيل الحاويات دون إدارة بنية تحتية تقليدية.

أفضل الممارسات عند نشر التطبيقات بالحاويات

1) قلّل حجم الصورة قدر الإمكان

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

2) افصل اعتمادات التطوير عن الإنتاج

لا تضع أدوات الاختبار والبناء داخل الصورة النهائية إن لم تكن ضرورية، خصوصًا في مشاريع Node.js وNestJS و.NET.

3) اضبط المنافذ والعناوين بعناية

يجب أن يستمع التطبيق داخل الحاوية على العنوان 0.0.0.0، لا على localhost فقط، وإلا فلن تتمكن المنصة السحابية من الوصول إليه.

4) اختبر محليًا قبل أي رفع

كثير من مشاكل النشر لا تكون من المنصة نفسها، بل من إعدادات الصورة أو أوامر التشغيل أو مسارات الملفات.

5) انتبه لإعدادات التوجيه في تطبيقات الواجهة

إذا كان التطبيق مبنيًا بأسلوب Single Page Application، فتأكد من ضبط nginx أو الخادم الأمامي لإعادة التوجيه إلى index.html.

لمن هذه الدورة مناسبة؟

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

ما القيمة الحقيقية لهذا النوع من المحتوى؟

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

الخلاصة التقنية

يوضح هذا المحتوى أن Docker ليس مجرد أداة تغليف، بل طبقة توحيد عملية بين التطوير والنشر والإنتاج. كما أن الجمع بين Docker وموفري السحابة مثل AWS وAzure وGoogle Cloud يمنح المطور مرونة كبيرة في نقل التطبيقات وتشغيلها بكفاءة. ومن الناحية التقنية، فإن أهم ما ينبغي التركيز عليه هو تقليل حجم الصورة، واستخدام Multi-stage Build، وضبط المنفذ والتوجيه بشكل صحيح، لأن هذه العناصر تصنع الفرق الحقيقي بين حاوية تعمل محليًا وحاوية جاهزة للإنتاج.