التوسّع - بناء القشرة

نظرة عامة على الوحدة

• مراجعة الأهداف في مرحلة التخطيط والمتطلّبات.
• تطبيق منهجية التطبيق ذي العوامل الاثني عشر (Twelve-Factor App) وأفضل ممارسات REST API.
• التعرّف على Kubernetes لتنسيق الحاويات، والحوسبة السحابية (Cloud Computing)، والتطبيقات السحابية الأصلية (Cloud Native Applications).
• استكشاف الرصد (Observability) وركائزه.
• تطبيق أفضل ممارسات التكامل المستمر (Continuous Integration) والتعمّق في حلول التسليم المستمر (Continuous Delivery).
• تنفيذ المشروع العملي التدرّجي، HiveBox المرحلة 4.

4.1 التخطيط - مراجعة الأهداف والمتطلّبات

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• في الوحدة السابقة، كان ينبغي أن تحدّد منهجية أجايل التي ستستخدمها. كما ينبغي أن تنشئ نوعًا من اللوحات لاستخدامها (سنستخدم GitHub Projects).
• في هذه المرحلة، تحتاج إلى مراجعة الأهداف والمتطلّبات. بعبارة أخرى، ما الذي تحقّق وما الذي تريد تحقيقه من هذه المرحلة؟
• أوّل أمر هو تحديد نطاق العمل والمخرجات لتجنّب تضخّم النطاق وضمان تلبية جميع المتطلّبات في الوقت المحدّد.
• بعد ذلك، تضع جدولًا زمنيًّا واقعيًّا للعمل. على سبيل المثال، متى ستعمل على المشروع وكم من الوقت تخصّص له؟
• الآن وبعد أن عرفت ماذا ومتى، فإنّ الخطوة التالية هي إبلاغ الخطّة وكتابتها في منصّة إدارة مشروعك (GitHub Projects في هذه الحالة).
• ينبغي أن يكون من السهل على أيّ قادم جديد فهم الخطّة ومعرفة اتجاهاتها الرئيسية.
• والخطوة التالية هي البدء في العمل على الخطّة.

المصادر

• تحديد أهداف أجايل: كيف تبدأ - Insights for Professionals
• التخطيط الرشيق: دليل خطوة بخطوة مع أمثلة - Businessmap

4.2 البرمجة - منهجية التطبيق ذي العوامل الاثني عشر

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• في عام 2011، ظهر بيان يُسمّى منهجية التطبيق ذي العوامل الاثني عشر (Twelve-Factor App methodology) كمجموعة من أفضل الممارسات لبناء تطبيقات ويب حديثة وقابلة للتوسّع وسهلة الصيانة.
• تهدف منهجية التطبيق ذي العوامل الاثني عشر إلى توحيد طريقة تطوير التطبيقات للاستفادة الكاملة من البيئات السحابية.
• بعد أكثر من عقد على ذلك البيان، يُعتبر الحدّ الأدنى لجميع التطبيقات. قد لا تحتاج إلى تطبيقها كلّها، خصوصًا في قاعدة شيفرة صغيرة، لكن ينبغي أن تبقى في ذهنك دائمًا أثناء التصميم المعماري والتنفيذ.
• سنكتفي هنا بذكر العوامل الاثني عشر، لكن احرص على قراءة صفحة كلّ منها.
  1. قاعدة الشيفرة (Codebase): قاعدة شيفرة واحدة تُتابَع في نظام التحكّم بالإصدارات، مع عمليات نشر كثيرة.
  2. الاعتماديات (Dependencies): صرّح بالاعتماديات واعزلها بشكل صريح.
  3. الإعدادات (Config): خزّن الإعدادات في البيئة.
  4. الخدمات الداعمة (Backing services): عامل الخدمات الداعمة كموارد مرتبطة.
  5. البناء والإصدار والتشغيل (Build, release, run): افصل تمامًا بين مرحلتي البناء والتشغيل.
  6. العمليات (Processes): نفّذ التطبيق كعملية واحدة أو أكثر بلا حالة.
  7. ربط المنافذ (Port binding): صدّر الخدمات عبر ربط المنافذ.
  8. التزامن (Concurrency): توسّع أفقيًّا عبر نموذج العمليات.
  9. القابلية للإهمال (Disposability): حقّق أقصى متانة مع بدء سريع وإيقاف لطيف.
  10. تكافؤ التطوير/الإنتاج (Dev/prod parity): اجعل التطوير والاختبار والإنتاج متشابهين قدر الإمكان.
  11. السجلات (Logs): عامل السجلات كتدفّقات أحداث.
  12. عمليات الإدارة (Admin processes): نفّذ مهام الإدارة/التسيير كعمليات لمرّة واحدة.
• تذكّر أنّ هذه هي الحدّ الأدنى فحسب، وهناك نقاط أخرى كثيرة ينبغي مراعاتها.

المصادر

• منهجية التطبيق ذي العوامل الاثني عشر
• ما بعد العوامل الاثني عشر: تطبيقات Java السحابية الأصلية بعامل 15 - IBM Developer (وهناك أيضًا كتاب صغير بعنوان ما بعد التطبيق ذي العوامل الاثني عشر لمزيد من القراءة).

4.3 البرمجة - أفضل ممارسات REST API

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• في Linux/Unix، سمعت على الأرجح أنّ كل شيء ملفّ (Everything is a file). وفي Kubernetes والكثير من البرمجيات الحديثة الأخرى، كل شيء واجهة برمجية (Everything is an API)!
• بصفتك مهندس DevOps، لن تكتب الشيفرة يوميًّا على الأرجح. لكن من الضروري فهم مفهوم الواجهة البرمجية (API) وكيفية عملها، لأنّه حين تكتب شيفرة، فالأرجح أن تكون واجهة REST API.
• سيُساعدك فهم الواجهات البرمجية والتفكير بمنطق الواجهات (API Thinking) كثيرًا كمهندس DevOps، لأنّ عالم اليوم هو عصر الواجهات البرمجية.
• التفكير بمبدأ الواجهة أولًا (API First) سيساعدك على كتابة شيفرة أفضل. عرّف الواجهة أولًا، ثم طوّر تنفيذها.
• يحتوي قسم المصادر على تفاصيل أكثر عن الواجهات البرمجية، ومشروع الشيفرة في خارطة الطريق كلّه يدور حول الواجهات البرمجية.

المصادر

• أفضل الممارسات في تصميم REST API - Stack Overflow
• أفضل الممارسات في تصميم الواجهات البرمجية - Swagger
• إرشادات واجهات RESTful والأحداث - Zalando (قراءة ممتعة)

4.4 التكامل المستمر - أفضل ممارسات CI

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• غُطّي التكامل المستمر (Continuous Integration) في الوحدة السابقة. والآن حان وقت التعرّف على أفضل ممارساته.
• يهدف التكامل المستمر إلى مساعدتك على إنتاج برمجيات عالية الجودة، لذا ينبغي تنفيذه على نحو صحيح.
• يحتوي قسم المصادر على تفاصيل أكثر عن أفضل الممارسات، لكن إليك بعض النقاط الأساسية التي ينبغي تذكّرها.
  • ينبغي أن يكون التكامل المستمر آليًّا بحكم تصميمه، فلا حاجة إلى إجراءات يدوية لتشغيله.
  • ابدأ بخطّ أنابيب (pipeline) أساسي للتكامل المستمر، ثم وسّعه وفقًا لاحتياجاتك.
  • ينبغي أن تكون خطوط أنابيب التكامل المستمر سريعة! استفد من كل الخيارات مثل التخزين المؤقّت (cache) والتوازي لتسريع التكامل المستمر.
  • أن تكون سريعًا لا يعني بالضرورة أن تكون "مكلفًا"! فهناك خيارات إعداد كثيرة لإبقاء التكاليف تحت السيطرة، مثل استخدام نسخ Cloud Spot/Preemptible (التي قد توفّر حتى 90% من التكاليف).
  • شغّل خطوط أنابيب التكامل المستمر عند كل التزام (commit)، لكن احرص على تحديد نطاق التشغيل بناءً على المسارات في المستودع. على سبيل المثال، إن كان لديك تطبيقات أو أدوات متعدّدة في المستودع نفسه، فلا ينبغي أن تعمل إلّا خطوط الأنابيب المتعلّقة بالتطبيقات التي غيّرها الالتزام.
  • اضمن أن يكون الفرع الرئيسي (main) قابلًا للنشر دائمًا. ينبغي أن تكون قادرًا على النشر من الفرع الرئيسي في أي لحظة.
  • افشل سريعًا، وأصلح سريعًا. من الأفضل إيقاف تنفيذ خط الأنابيب في أسرع وقت ممكن عند وجود مشكلة حرجة أو عندما ستفشل الخطوات التالية بسبب الخطوات الأولى. لكن تذكّر أنّ هذا ليس صحيحًا دائمًا! أحيانًا يكون من الأفضل تشغيل خط الأنابيب حتى النهاية وإصلاح جميع المشكلات دفعة واحدة (يعتمد الأمر على حالة الاستخدام وبيئة العمل).
  • حاول دائمًا جعل بيئة التكامل المستمر (وبيئة الاختبار عمومًا) أقرب ما يمكن إلى الإنتاج. فأنت تريد اختبار برمجياتك كما ستعمل في الإنتاج.
  • راجع عمليات التكامل المستمر وحسّنها بانتظام بناءً على التغيّرات في العمل والمتطلّبات. فإنشاء خطوط أنابيب التكامل المستمر ليس أمرًا لمرّة واحدة.

المصادر

• أفضل ممارسات التكامل المستمر - GitLab
• 11 من أفضل ممارسات CI/CD لنجاح DevOps - Codefresh

4.5 الحاويات - نظرة عامة على Kubernetes ومفاهيمه الأساسية

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

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

• أظهر استبيان CNCF السنوي 2022 زيادة كبيرة عامًا بعد عام (YOY) في استخدام Kubernetes في الإنتاج. وأظهر استبيان CNCF السنوي 2023 تبنّيًا أسرع لـ Kubernetes.

• عندما ظهرت حاوية Docker في عام 2013، وتبنّت شركات كثيرة هذه التقنية الجديدة، تغيّر كل شيء، من تطوير الشيفرة إلى العمل في الحاويات إلى النشر والمراقبة وتشغيل البرمجيات.

• ومن ثمّ ظهرت الحاجة إلى نظام جديد للتعامل مع هذا النظام البيئي الجديد. وهذا بالضبط ما حدث. فقد وُلدت أنظمة كثيرة لحلّ هذه المشكلة... "كيفية إدارة الحاويات [في الإنتاج]؟" وهو ما يعنيه "كيفية إنشاء البرمجيات السحابية الأصلية وإدارتها؟".

• دخلت أنظمة كثيرة السباق، وكان Kubernetes هو الحصان الرابح. ومنذ ذلك الحين، أصبح Kubernetes (المعروف أيضًا بـ K8s) المنصّة الرائدة لإدارة الحاويات.

• يتمتّع Kubernetes بميزات كثيرة مثل كونه مفتوح المصدر، وبلا ارتباط بمورّد واحد (no vendor lock-in)، وناضجًا، وبمجتمع ونظام بيئي واسعين، وبمعمارية قابلة للتوسيع.

• وتُترجم هذه الميزات إلى ما يلي:

  • دعم كثير من الميزات جاهزةً (out-of-the-box).
  • سهولة أتمتة المهام والعمليات اليدوية.
  • المساعدة في إدارة بنية تحتية ضخمة بجهد أقلّ.
  • زيادة الإنتاجية وتسريع دورة التطوير.
  • الكفاءة في إدارة البنية التحتية وخفض التكاليف.
  • دعم القابلية للتوسّع والوحدات (modularity) بكفاءة.

• أصبح Kubernetes المعيار الفعلي (de facto) لتنسيق الحاويات، وقد اعتُمد على نطاق واسع في القطاعين الخاص والعام. وفقًا لاستبيان مؤسسة الحوسبة السحابية الأصلية (CNCF) 2023، كان 66% من المستهلكين يستخدمون Kubernetes في الإنتاج و18% يقيّمونه (84% إجمالًا).

شكل توضيحي: المفاهيم الأساسية في Kubernetes — العنقود (Cluster) والعقدة (Node) والحاضنة (Pod) وعلاقتها ببعضها.

• لنلقِ نظرة سريعة على الحاويات وDocker وحاويات Kubernetes:
  • الحاويات (Containers): تقنية لتغليف تطبيق واعتماديات زمن تشغيل Docker الخاصة به.
  • Docker: معيار فعلي (de facto) لبناء التطبيقات المحزّمة ومشاركتها.
  • Kubernetes: منصّة سحابية أصلية لإدارة أحمال عمل الحاويات وتنسيقها.
• المفاهيم الأساسية في Kubernetes:
  • العنقود (Cluster): مجموعة من العُقد (nodes) مُجمّعة معًا لمشاركة الموارد وموازنة أحمال العمل.
  • العقدة (Node): الوحدة الحاسوبية في Kubernetes، ويسهل تصوّرها كآلة واحدة تشغّل الحاضنات (Pods).
  • الحاضنة (Pod): مضيف منطقي يضمّ مجموعة من حاوية واحدة أو أكثر، وهي أصغر وحدة حاسوبية في Kubernetes.
• في الوحدة التالية، سنتعمّق أكثر في Kubernetes وكيفية استخدامه.

المصادر

• Kubernetes في 5 دقائق - VMware Cloud Native Apps
• تعلّم أساسيات Kubernetes - وثائق Kubernetes
• مقدمة إلى دورة Kubernetes - Linux Foundation.

4.6 الرصد - مراقبة التطبيق والبنية التحتية

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• قال حكيم ذات مرّة: "لا يمكنك إدارة ما لا يمكنك قياسه." ربّما لا يكون هذا صحيحًا دائمًا، لكن في عالم DevOps يلعب الرصد دورًا كبيرًا. ببساطة، إن لم تراقب مواردك المُدارة، فأنت تسير في الظلام!

• في البداية، تحتاج إلى معرفة ركائز الرصد الثلاث وهي السجلات (logs) والمقاييس (metrics) والتتبّعات (traces). كلّ واحدة منها تعمل بشكل مختلف وتخدم غرضًا مختلفًا.

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

• في نهاية المطاف، يساعد الرصد على تقليل زمن التوقّف، وتحسين تجربة المستخدم، وتحسين استخدام الموارد والتكاليف.

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

• أشهر الأدوات مفتوحة المصدر في هذا المجال هي Prometheus وGrafana.

المصادر

• ما هو الرصد؟ - Grafana
• السجلات مقابل المقاييس مقابل التتبّعات - Engineering Fundamentals Playbook
• ركائز الرصد الثلاث - Sematext
• كتاب موثوقية الموقع - الفصل 4 - المراقبة

4.7 التسليم المستمر - مقدمة وحلول في السوق

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• بعبارات بسيطة، التسليم المستمر (Continuous Delivery) ممارسة تُجهَّز فيها تغييرات الشيفرة تلقائيًّا للنشر إلى بيئات متعدّدة، وخاصة الإنتاج. ويشمل ذلك نشر جميع تغييرات الشيفرة إلى بيئة اختبار ثم إلى بيئة شبيهة بالإنتاج بعد اجتياز الاختبارات الآلية، بما يضمن أن تكون البرمجيات دائمًا في حالة قابلة للنشر.
• يسمح اتّباع ممارسات التسليم المستمر للفرق بتقديم ميزات وإصلاحات جديدة بأمان وسرعة أكبر للمستخدمين، مع تقليل خطر أخطاء النشر.
• من المهم معرفة أنّ CD قد يشير إلى أمرين مختلفين: التسليم المستمر (Continuous Delivery) والنشر المستمر (Continuous Deployment). وهما يُستخدمان عادةً بالتبادل، لكنهما في الواقع مرحلتان مختلفتان.
• في حالات كثيرة، يمكن استخدام حلول التكامل المستمر نفسها للتسليم/النشر المستمر؛ ومع ذلك، هناك حلول متخصّصة تعمل بشكل أفضل مع التسليم المستمر.
• لا تهمّ المنظومة ما دمت تفهم مبادئ التسليم المستمر.
• التسليم المستمر ممارسة حرجة لتطوير البرمجيات الحديث من أجل تسليم أسرع. ومع ذلك، يمكن تأجيل استخدام نظام مخصّص حتى ينضج مشروعك أكثر. لذا استخدم حلّ التكامل المستمر كبداية للتسليم المستمر حتى ذلك الحين.

المصادر

• أساسيات النشر المستمر في DevOps - GitHub
• مبادئ التسليم المستمر - Atlassian

4.8 البنية التحتية - الحوسبة السحابية والتطبيقات السحابية الأصلية

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• يشير مصطلح الحوسبة السحابية (Cloud Computing) إلى نموذج تقديم خدمة تُتاح فيه البرمجيات والتخزين والقدرة الحاسوبية للمستخدمين عبر الإنترنت عند الطلب. وفي هذا النموذج، لا يملك المستخدمون البنية التحتية المادية التي تدعم هذه الموارد ولا يديرونها، بل يصلون إليها كخدمة مرفق (utility) يقدّمها مزوّد خدمة خارجي.
• يمكن تصنيف الحوسبة السحابية إلى ثلاث مجموعات:
  • السحابة العامة (Public Cloud) بيئة حاسوبية يملكها ويشغّلها مزوّد خدمات سحابية خارجي، مثل Amazon Web Services (AWS) أو Microsoft Azure أو Google Cloud Platform. صُمّمت السحابات العامة للوصول إليها عبر الإنترنت، وهي متاحة عمومًا لأي مؤسسة أو فرد يريد استخدامها.
  • السحابة الخاصة (Private Cloud) بيئة حاسوبية تملكها وتشغّلها مؤسسة واحدة للاستخدام الحصري. ويمكن تنفيذ السحابات الخاصة داخل المقرّ (on-premises) أو استضافتها لدى مزوّد خارجي. وهي تقدّم مزايا الحوسبة السحابية مثل القابلية للتوسّع والمرونة، مع أمان وتحكّم إضافيين يميّزان البيئة المحلية.
  • السحابة الهجينة (Hybrid Cloud) بيئة حاسوبية تجمع بين السحابات العامة والخاصة. وتتيح للمؤسسات الاستفادة من أفضل ما في العالمين باستخدام السحابات العامة لأحمال عمل محدّدة والخاصة لأخرى.
• للحوسبة السحابية أنماط إدارة مختلفة؛ وهناك ثلاثة أنواع رئيسية:
  • البنية التحتية كخدمة (Infrastructure as a Service - IaaS) تتيح للمستخدمين الوصول إلى موارد حاسوبية مُشكَّلة افتراضيًّا، مثل الأجهزة الافتراضية والتخزين والشبكات.
  • المنصّة كخدمة (Platform as a Service - PaaS) تتيح للمستخدمين الوصول إلى منصّة لتطوير التطبيقات واختبارها ونشرها.
  • البرمجيات كخدمة (Software as a Service - SaaS) تتيح للمستخدمين الوصول إلى تطبيقات برمجية يمكن استخدامها عبر الإنترنت دون الحاجة إلى تثبيت البرمجيات وصيانتها على أجهزتهم.
• يشير مصطلح السحابية الأصلية (Cloud-Native) إلى معمارية وتصميم تطبيق بُني خصيصًا للاستفادة من نموذج الحوسبة السحابية. بعبارة أخرى، صُمّم التطبيق السحابي الأصلي ليكون قابلًا للتوسّع ومرنًا ويستفيد من التزويد التلقائي بالموارد الذي تقدّمه المنصّات السحابية.
• بشكل عام، تعمل البرمجيات السحابية الأصلية على أفضل وجه على المنصّات السحابية الأصلية مثل Kubernetes، وهي منصّة مفتوحة المصدر لأتمتة نشر التطبيقات المحزّمة وتوسيعها وإدارتها.

المصادر

• ما هي الحوسبة السحابية؟ - AWS
• ما هي السحابية الأصلية؟ - AWS
• Floci - محاكي AWS محلي مجاني ومفتوح المصدر للتطوير والاختبار والتكامل المستمر.

اختبار

التطبيق العملي

اتّبع التعليمات في المرحلة 4 من مشروع HiveBox.

أسئلة المقابلات

راجع أسئلة المقابلة المتعلّقة بـ الوحدة 4.