التحوّل - إتمام البنية

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

• صقل الأهداف والمتطلّبات.
• دمج الشيفرة مع الأنظمة الخارجية وكتابة اختبارات التكامل.
• استخدام البنية التحتية كشيفرة (Infrastructure as Code)، وتعلّم أساسيات Terraform وإدارة إعدادات Kubernetes مثل Helm وKustomize.
• تطبيق أفضل ممارسات التسليم المستمر (Continuous Delivery).
• تنفيذ المشروع العملي التدرّجي، HiveBox المرحلة 5.

5.1 التخطيط - صقل الأهداف والمتطلّبات

الجمهور

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

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

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

المصادر

• دليل صقل قائمة المهام المتراكمة: كيف ومتى ونصائح للنجاح - Atlassian
• 5 استراتيجيات لصقل قائمة مهام المنتج المتراكمة - Scrum.org

5.2 البرمجة - العمل مع الأنظمة الخارجية

الجمهور

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

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

• بصفتك مهندس DevOps، ستعمل مع أنظمة خارجية أو تدمجها باستخدام شيفرة أو أدوات. وقد تكون هذه الأنظمة الخارجية واجهات برمجية خارجية (third-party APIs) أو قواعد بيانات أو خدمات سحابية أو خدمات مصغّرة (microservices).
• ستستخدم في الغالب واجهات REST API للتفاعل مع هذه الخدمات، لكن هناك طرقًا كثيرة للتواصل مع تلك الأنظمة وفقًا لكل حالة استخدام.
• سنغطّي هنا بعض النقاط الأساسية عند العمل مع الأنظمة الخارجية برمجيًّا.
  • إن كان نظامًا معروفًا، فمن الأفضل عادةً استخدام مكتبة أو حزمة تطوير (SDK) خاصة به. لا تكتب كل شيء من الصفر.
  • احرص على معالجة الأخطاء وحدود المعدّل (rate limits). واعرف كيف تنفّذ استراتيجيات تحديد المعدّل (مثل التباطؤ الأُسّي exponential backoff).
  • احرص على معالجة الاستجابات المُقسّمة إلى صفحات (paginated responses)، مثل جلب البيانات على دفعات، خصوصًا إن كنت تتوقّع حجمًا كبيرًا من البيانات.
  • استخدم التخزين المؤقّت (cache) كلما أمكن. لا تُثقل الأنظمة بنداءات غير ضرورية.
  • استخدم دائمًا اتصالًا آمنًا مع الأنظمة الخارجية حتى لو كانت حالة الاستخدام بسيطة.
  • ليس كل اتصال بحاجة إلى أن يكون متزامنًا؛ يمكنك استخدام تواصل غير متزامن (async) عبر طوابير الرسائل (message queues) للتعامل مع التأخّر والزمن المستغرق تحت الضغط.

المصادر

• تكامل الأنظمة: الأنواع والمقاربات وخطوات التنفيذ - AltexSoft
• تكامل الأنظمة مقابل تطوير البرمجيات - Budibase

5.3 البرمجة - كتابة اختبارات التكامل

الجمهور

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

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

• المستوى الثاني من الاختبارات هو اختبار التكامل (Integration Test). ودوره الأساسي هو ضمان أن تعمل مكوّنات أو وحدات نظامك المختلفة جيدًا معًا. ولكي تحصل على اختبار تكامل جيّد، عليك تذكّر بضع نقاط.
• كالمعتاد، ابدأ باختبارات أساسية، ثم وسّع سيناريوهات الاختبار تدريجيًّا.
• ينبغي أن تكون الاختبارات بسيطة قدر الإمكان؛ وإلا فستنتهي بشيفرة اختبار معقّدة تحتاج إلى اختبار آخر لتأكيد أنها تعمل كما هو متوقّع!
• اضمن القابلية للصيانة والقراءة باستخدام أدوات وأُطر عمل معروفة، وتجنّب كتابة شيفرتك الخاصة كإطار اختبار.
• حاول دائمًا استخدام أنظمة حقيقية وتجنّب المحاكاة (mocking) المفرطة. على سبيل المثال، إن كنت تختبر تفاعلات مع قاعدة بيانات، فشغّل نسخة قاعدة بيانات فعلية واكتب الاختبار مقابلها.
• تحقّق دائمًا من مساري النجاح والفشل معًا! لا تختبر المسار السعيد فقط.
• حاول تشغيل اختبارات التكامل في بيئة أقرب ما يمكن إلى الإنتاج، على الأقل بيئة تستخدم التقنية نفسها المستخدمة في الإنتاج. على سبيل المثال، إن كنت تستخدم الحاويات في الإنتاج، فينبغي أن تُشغَّل اختبارات التكامل في الحاويات أيضًا.
• حاول استخدام بيانات اختبار واقعية (لكنها قليلة) لتغطية تنوّع من الحالات مثل مستخدميك الحقيقيين (مثل استخدام المصانع factories و/أو البيانات الجاهزة fixtures).
• اعزل الاختبارات عن بعضها قدر الإمكان لتحصل على نتائج دقيقة. ينبغي أن تكون كل مجموعة اختبار مستقلّة وألّا تعتمد على إجراءات مجموعات اختبار أخرى.
• تذكّر الخدمات الخارجية (واجهات خارجية) عند كتابة اختبارات التكامل. استخدم بيئات تجريبية (sandbox) أو اختبارية تقدّمها هذه الخدمات، أو حاكِها ببدائل API (API stubs) (راجع القسم السابق عن العمل مع الأنظمة الخارجية).
• افتراضيًّا، ينبغي أن تُدمج الاختبارات مع خطوط أنابيب CI/CD وتُشغَّل تلقائيًّا بعد كل التزام أو قبل الدمج. لكن فكّر أيضًا في توفير طريقة سهلة لتشغيلها محليًّا.

المصادر

• ما هو اختبار التكامل - BrowserStack
• الدليل الكامل لاختبار التكامل - HubSpot

5.4 البنية التحتية - البنية التحتية كشيفرة وإدارة الإعدادات

الجمهور

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

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

• بصفتك مهندس DevOps، ستسمع (وتستخدم) مصطلح "البنية التحتية كشيفرة" (Infrastructure as Code - IaC) كثيرًا. ولهذا سبب وجيه، إذ يُعتبر أحد جوهر DevOps. وستسمع أيضًا عن أدوات مثل Terraform وCrossplane وPulumi.

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

• لذا، بدلًا من توفير البنية التحتية يدويًّا (سواء عبر CLI أو واجهة المستخدم)، تستخدم ملفات تعريف مقروءة آليًّا (مثل YAML أو JSON أو ملفات DSL أخرى مثل HCL) لإنشاء البنية التحتية وإعدادها.

• في الغالب، تُخزَّن البنية التحتية كشيفرة في نظام إدارة الشيفرة المصدرية مثل Git. ومع ذلك، فإنّ البنية التحتية كشيفرة أقلّ ارتباطًا باستخدام Git وأكثر ارتباطًا بما يلي:

  • متطابقة النتيجة (Idempotent): تعمل البنية التحتية كشيفرة على نحو أفضل عندما تكون متطابقة النتيجة، أي أنها تُنتج النتيجة نفسها في كل تشغيل. وهذا يقلّل خطر الأخطاء في كل تشغيل، ويجعل النتيجة متوقّعة دائمًا، ويتجنّب الآثار الجانبية.
  • تصريحية (Declarative): تعمل البنية التحتية كشيفرة على نحو أفضل عندما تكون تصريحية (عكس الأمرية imperative) لأنّ هذه المقاربة تبسّط استخدام البنية التحتية كشيفرة وتنقل منطق تدفّق التحكّم إلى أداة البنية التحتية كشيفرة بدلًا من التعامل معه في كل مرة.
  • لغة خاصة بالمجال (DSL): هناك مقاربتان لكتابة البنية التحتية كشيفرة: إمّا استخدام أدوات تعتمد لغات خاصة بالمجال مثل Terraform وCrossplane، أو استخدام أدوات تعتمد لغات برمجة مثل Pulumi و AWS CDK.

• من دون الخوض كثيرًا في ما هو تصريحي وما ليس كذلك ... ينبغي أن تبحث عن أدوات تتيح لك تحديد الشكل الذي تريد أن تبدو عليه بنيتك التحتية مثل Terraform أو Crossplane واستخدام لغة خاصة بالمجال (DSL) للتبسيط.

• في كل الحالات، لا يُوصى باستخدام سكربتات أمرية (imperative) بأي لغة (Bash أو Python وغيرها)؛ فهذه ليست البنية التحتية كشيفرة المثالية وستؤذيك بشدّة مستقبلًا عندما تحاول أتمتة البنية التحتية كشيفرة عبر GitOps (سيُغطّى ذلك في الوحدات التالية).

• أخيرًا، في عصر الحاويات الحالي، أصبحت أدوات إدارة الإعدادات مثل Ansible وSaltStack تُستخدم أقلّ وأقلّ لصالح منظومة الحاويات. ولن نغطّيها في خارطة الطريق هذه؛ تعلّم إحداها عند حاجتك إليها (يُوصى بشدّة بـ Ansible).

المصادر

• ما هي البنية التحتية كشيفرة؟ - IaC مشروحة - AWS
• ما هي البنية التحتية كشيفرة مع Terraform؟ | HashiCorp

5.5 البنية التحتية - أساسيات Terraform

الجمهور

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

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

• Terraform من اللاعبين الرئيسيين في سوق البنية التحتية كشيفرة. ويمكن القول إنه أكثر أدوات IaC شيوعًا مع دعم السحابات المتعدّدة (multi-cloud).
• يُعرف Terraform بما يلي:
  • قابل للتوسيع (Extensible): يستخدم المزوّدات (Providers) (فكّر فيها كإضافات plugins)، التي تتيح لـ Terraform العمل مع أنظمة مختلفة، مثل مزوّدي السحابة أو تطبيقات مثل PostgreSQL.
  • تصريحي (Declarative): يستخدم مقاربة تصريحية عبر لغته الخاصة بالمجال المسماة لغة إعداد HashiCorp (HCL) (HashiCorp Configuration Language) (يدعم JSON أيضًا)، حيث تعرّف الشكل المطلوب للبنية التحتية (مثل "أنشئ ثلاث نسخ AWS EC2") بدلًا من وصف كيفية تحقيقه.
  • ذو حالة (Stateful): له مصدر حقيقة يتمثّل في ملف حالة terraform.tfstate لتتبّع البنية التحتية الحالية. يقارن Terraform الحالة الفعلية للبنية التحتية بالحالة المطلوبة المعرّفة في ملفات الإعداد.
  • معياري (Modular): يدعم ويوصي باستخدام الوحدات (modules)، التي تتيح لك تجريد أنماط البنية التحتية وإعادة استخدامها عبر مشاريع متعدّدة وتقليل تكرار الشيفرة.
• لن نتعمّق في التطبيق العملي؛ ستجده في قسم المصادر. لكن ينبغي أن تتذكّر بضع نقاط عند بدء استخدام Terraform.
• أولًا، إن أنشأت أي بيئة عمل، فلا تستخدم ملفات الحالة المحلية أبدًا؛ خزّن الحالة دائمًا على خدمة متوافقة مع S3 (AWS S3 أو GCP Cloud Storage أو Azure Blob Storage وغيرها).
• لا تكرّر نفسك (DRY)! لا تكتب شيفرة HCL الخاصة بـ Terraform إلا عند الحاجة! يحتوي سجل Terraform على وحدات كثيرة، ولدى أشهر مزوّدي السحابة وحدات رسمية هناك. على سبيل المثال، استخدم وحدة AWS EKS لإنشاء عنقود EKS.
• مع نموّ منظومة الحاويات، صار استخدام Terraform محصورًا في البنية التحتية البحتة، مثل إنشاء عنقود Kubernetes وقاعدة بيانات سحابية. لكن متى أصبح لديك عنقود Kubernetes، استخدم أدوات Kubernetes (أي لا تُعدّ تطبيقات Kubernetes باستخدام Terraform!).
• تذكّر تطبيق أفضل ممارسات Terraform وفرضها في خطوط أنابيب CI، مثل التحقّق من صحة شيفرة Terraform وتنسيقها وفحصها وتأمينها.
• Terraform موضوع كبير، لكن هذه نقطة البداية. وكالمعتاد، ابدأ صغيرًا وتوسّع.

المصادر

• درس Terraform – البدء مع Terraform - Spacelift
• درس Terraform للمبتدئين مع مختبرات: دليل كامل خطوة بخطوة! - KodeKloud
• تحقّق من صحة ونسّق وافحص وأمّن واختبر بنية Terraform التحتية كشيفرة - Ahmed AbouZaid

5.6 الحاويات - إدارة إعدادات Kubernetes

الجمهور

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

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

• مع نموّ منظومة الحاويات، أصبح Kubernetes هو المنصّة الجديدة. ومن ثمّ، متى أصبح لديك عنقود Kubernetes يعمل، ينبغي أن تفعل كل شيء بالطريقة التي يريدها Kubernetes.
• هناك أدوات كثيرة لإدارة إعدادات Kubernetes، لكن أشهرها:
  • Plain-Kubectl: أداة CLI الرسمية التي تتواصل مع لوحة تحكّم عنقود Kubernetes عبر واجهة Kubernetes البرمجية.
  • Kustomize-Kubectl: جزء من Kubectl يستخدم مقاربة بلا قوالب حيث يرقّع ملفات Kubernetes التعريفية (manifests) ويدمجها.
  • Helm: ليس جزءًا من مشروع Kubernetes، لكنه أداة معيارية فعلية (de facto) تستخدم مقاربة قوالب. تحتوي الحزمة (chart) على قوالب بها عناصر نائبة (placeholders) تُستبدل عند العرض (render).
• ستستخدم على الأرجح أكثر من أداة لإدارة إعدادات Kubernetes.
• تذكّر دائمًا أنّ إعدادات Kubernetes ما زالت بنية تحتية كشيفرة، وينبغي أن تتّبع الممارسات نفسها المذكورة في الأقسام السابقة، مثل استخدام مقاربة تصريحية وإبقاء الأتمتة في الحسبان دائمًا، حتى لو لم تستخدم أي أتمتة بعد.

المصادر

• إدارة إعدادات التطبيقات في Kubernetes - Giant Swarm
• إدارة موارد Kubernetes عبر Kustomize - INNOQ
• مقدمة إلى Helm - وثائق Helm
• 3 طرق لتخصيص مخططات Helm الجاهزة عبر Kustomize - Ahmed AbouZaid

5.7 الرصد - أنظمة تجميع السجلات

الجمهور

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

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

• التسجيل هو الركيزة الثانية للرصد (السجلات والمقاييس والتتبّعات). وكما ذُكر آنفًا، كلّ واحدة تعمل بشكل مختلف وتخدم غرضًا مختلفًا.

• مع تزايد تعقيد البنية التحتية الحديثة، صار من الضروري وجود نظام تسجيل مركزي لمراقبة الأنظمة قيد التشغيل وتحليلها.

• الأنظمة قيد التشغيل.

• سجلات التطبيقات مصدر غنيّ بالمعلومات يمكن أن يفيد في التنقيح (debugging) واستكشاف المشكلات وحتى الموثوقية (مثل مراقبة معدّل الأخطاء في السجلات).

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

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

• هناك أنواع مختلفة من السجلات: المنظّمة (Structured) وغير المنظّمة (Unstructured) وشبه المنظّمة (Semi-Structured)، تعلّم عن كلّ منها.

• فيما يلي بعض النقاط الأساسية التي ينبغي تذكّرها عند العمل بالسجلات:

  • استخدم السجلات المنظّمة دائمًا كلما كان ذلك مدعومًا لأنها تجعل كل شيء أسهل (التخزين والاستعلام والتحليل).
  • تجنّب تحليل السجلات (parsing) بالتعبيرات النمطية (regex) قدر الإمكان. تحقّق أولًا مما إذا كان نوع السجل يملك محلّلًا (parser) بالفعل.
  • أثرِ السجلات بكل البيانات الوصفية (metadata) اللازمة لتكون مستقلّة، بحيث يمكن فهمها في أي لحظة بخلفية معدومة أو قليلة عن مُنتِج السجلات.
  • اضمن إخفاء هوية المعلومات الحسّاسة (مثل البيانات الشخصية وبيانات الاعتماد) قبل تخزينها، وأن تتّبع الأنظمة المتعلّقة بالامتثال مثل GDPR.
  • التقط السجلات ذات الصلة فقط؛ وإلا فستنتهي بمستنقع سجلات. وهذا سيقلّل التكاليف ويجعل البحث في السجلات أكثر كفاءة.

• هناك حلول تسجيل كثيرة في السوق، لكن إن كان لديك الخيار، فالتزم بخدمة تسجيل مزوّد السحابة أو Grafana Loki.

المصادر

• ركائز الرصد الثلاث - Sematext
• تجميع السجلات: كل ما تحتاج إلى معرفته لتجميع بيانات السجلات - Splunk
• ما هي أنواع البيانات غير المنظّمة والمنظّمة وشبه المنظّمة؟ - Matillion

5.8 التسليم المستمر - أفضل ممارسات CD

الجمهور

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

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

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

المصادر

• كيف تواكب أفضل ممارسات CI/CD - أفضل ممارسات التسليم المستمر - GitLab
• ما هو التسليم المستمر؟ الأدوات وأفضل الممارسات - XenonStack

اختبار

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

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

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

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