البنية التحتية ككود: لماذا يجب أن يكون إعداد خادمك في Git

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

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

هناك طريقة أفضل. اكتب البنية التحتية الخاصة بك ككود.

ما يعنيه البنية التحتية ككود فعليًا

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

التحول الرئيسي هو في كيفية وصف البنية التحتية. بدلاً من كتابة أوامر خطوة بخطوة مثل "اتصل بالخادم عبر SSH، شغّل هذا الأمر لتثبيت Nginx، ثم عدّل ملف الإعداد هذا"، تكتب إعلانًا عما يجب أن تبدو عليه البنية التحتية. على سبيل المثال: "أريد خادمًا يعمل بإصدار Nginx 1.24، يستمع على المنفذ 443، مع شهادة TLS هذه وقواعد الوكيل هذه."

الأداة التي تعالج هذه الملفات تقرأ إعلانك، وتقارنه بالحالة الحالية للبنية التحتية الخاصة بك، وتجري أي تغييرات ضرورية للمطابقة. هذا يسمى إدارة الحالة المرغوبة (Desired State Management).

إليك ما يبدو عليه إعداد تصريحي بسيط في Terraform:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y nginx
              systemctl enable nginx
              systemctl start nginx
              EOF

  tags = {
    Name = "web-server"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP and SSH"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

هذا الملف يعلن بالضبط ما تريده: مثيل EC2 مع تثبيت Nginx ومجموعة أمان تسمح بحركة مرور الويب. يقارن Terraform هذا الإعلان بالحالة الحالية لحساب AWS الخاص بك ويجري فقط التغييرات اللازمة للمطابقة.

كيف يغير ذلك عملك اليومي

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

هذا يحول سير العمل بالكامل:

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

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

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

• التراجع عن التغييرات مباشر. إذا تسبب تغيير في الإعداد في مشاكل، يمكنك التراجع عن الالتزام وإعادة التطبيق. لا تحتاج إلى تذكر التسلسل الدقيق للخطوات اليدوية لإلغاء التغيير.

مفهوم الحالة المرغوبة

أهم فكرة في البنية التحتية ككود هي الحالة المرغوبة. ملفات الإعداد الخاصة بك تصف الحالة المثالية للبنية التحتية الخاصة بك. أداة IaC تضمن باستمرار أن الحالة الفعلية تطابق الحالة المرغوبة.

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

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

ما ليست البنية التحتية ككود

البنية التحتية ككود ليست أداة محددة. Terraform، AWS CloudFormation، Ansible، Pulumi، وغيرها الكثير هي تطبيقات للمفهوم. الأداة أقل أهمية من ممارسة معاملة إعداد البنية التحتية ككود تصريحي مُدار بالإصدارات وقابل للمراجعة.

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

لماذا هذا مهم لـ CI/CD

البنية التحتية ككود هي الأساس لمعاملة تغييرات البنية التحتية بنفس طريقة معاملة تغييرات التطبيق في خط أنابيب CI/CD الخاص بك. عندما تكون البنية التحتية كودًا، يمكنك:

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

بدون البنية التحتية ككود، يمكن لخط أنابيب CI/CD الخاص بك معالجة كود التطبيق فقط. تظل تغييرات البنية التحتية يدوية، عرضة للأخطاء، وغير مرئية لخط الأنابيب. هذا يخلق فجوة حيث يتم أتمتة نشر التطبيقات ولكن البنية التحتية التي تعمل عليها ليست كذلك.

قائمة تحقق عملية للبدء

إذا كنت تفكر في اعتماد البنية التحتية ككود، إليك نقطة بداية عملية:

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

الخلاصة

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

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