DevOps والبنية التحتية ككود

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

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

ما الذي تغيّره DevOps فعلياً

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

التكامل المستمر والتسليم المستمر: ماذا يحدث فعلياً في كل مرحلة

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

name: ci
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t checkout-service:${{ github.sha }} .
      - run: docker run checkout-service:${{ github.sha }} npm test

البنية التحتية ككود: الفكرة نفسها، موجَّهة إلى البنية التحتية

يُؤتمت CI/CD شحن كود التطبيق. تطبّق البنية التحتية ككود الانضباط نفسه على الخوادم والشبكات والخدمات التي يعمل عليها ذلك الكود: توفير البنية التحتية وإدارتها بالكود بدل العمليات اليدوية ونقرات لوحة التحكم. سلة تخزين أُنشئت بالنقر عبر لوحة تحكم لا تترك أي سجل بمن أنشأها أو لماذا أو كيفية إعادة إنشائها. السلة نفسها، مُعلَنة في ملف، تترك ذلك السجل.

resource "aws_s3_bucket" "uploads" {
  bucket = "my-app-uploads"
}

تعمل أدوات مثل Terraform عبر 3 خطوات: كتابة الإعداد، ثم التخطيط (معاينة بالضبط ما سيُنشأ أو يتغيّر أو يُحذف لمطابقته)، ثم التطبيق (تنفيذ تلك التغييرات بترتيب التبعيات الصحيح). ذلك الإعداد تصريحي: يصف الحالة النهائية التي تريدها، لا الأوامر الفردية للوصول إليها، وتتولى الأداة الباقي.

الالتباس: "إصلاح يدوي سريع في لوحة التحكم أمر لا بأس به"

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

مفاتيح الاختبار: التقاط الملاءمة في سيناريو

إلى أين يقودك هذا

DevOps وCI/CD والبنية التحتية ككود هي ما يجعل كل شيء غطاه الدرسان السابقان مستداماً عند النطاق الفعلي: دالة بلا خوادم أو صورة حاوية موثوقة بقدر خط الأنابيب الذي يبنيها ويختبرها ويشحنها، والبنية التحتية التي تعمل عليها متسقة بقدر الكود الذي يصفها. ينتقل المجال التالي في هذا المقرر إلى ما يُبقي الأنظمة آمنة ومتاحة بمجرد أن تعمل، نموذج المسؤولية المشتركة، والهوية، والتشفير، والتعافي من الكوارث، ممارسات تجعلها البنية التحتية ككود أسهل بكثير في تطبيقها بالطريقة نفسها عبر كل بيئة يملكها فريق.