من سيرفرات “الدلال” إلى جيش من المستنسخات: كيف أنقذتنا البنية التحتية كشيفرة (IaC)؟

أذكرها وكأنها البارحة. ليلة ثلاثاء شتوية باردة، وأنا أغط في نوم عميق بعد يوم عمل طويل. فجأة، يصدح صوت الهاتف بنغمته المزعجة. على الطرف الآخر كان صوت زميلي يوسف، يملؤه التوتر: “أبو عمر، الحق! سيرفر العميل ‘س’ وقع، والموقع كله معطّل!”.

يا ويلي! قفزت من السرير وكأن أفعى لدغتني. فتحت اللابتوب وبدأنا رحلة العذاب. ما هي آخر نسخة من الكود على السيرفر؟ أي نسخة PHP كنّا نستخدم؟ هل Apache أم Nginx؟ ما هي الإعدادات المخصصة التي أضافها زميلنا السابق الذي ترك الشركة قبل ستة أشهر؟ لم يكن لدينا أي إجابات واضحة. كان هذا الخادم قطعة فريدة من نوعها، تحفة فنية صنعها شخص ما يدوياً، ولم يترك خلفه أي دليل أو خريطة.

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

ما هي مشكلة “الخوادم المدللة” (Pet Servers)؟

في عالم إدارة الأنظمة، هناك تشبيه شهير يقسم الخوادم إلى نوعين: الحيوانات الأليفة (Pets) والماشية (Cattle).

• الخوادم الأليفة (Pets): هي خوادم فريدة من نوعها، تُعطى أسماءً (مثل `db-master-01` أو `web-prod-main`). إذا مرض أحدها، فإنك تبذل قصارى جهدك لعلاجه ورعايته وإعادته إلى صحته. هي خوادم لا يمكن الاستغناء عنها، وإذا ماتت، فهي كارثة. هذا بالضبط ما كان لدينا.
• خوادم الماشية (Cattle): هي خوادم متطابقة، تُعطى أرقاماً أو مُعرّفات عشوائية (مثل `web-172a3f`, `web-9b4d1e`). إذا مرض أحدها، لا تضيّع وقتك في علاجه. ببساطة، “تُطلِق عليه النار” وتستبدله بآخر جديد وصحي ومطابق تماماً في دقائق.

المشكلة في نموذج “الحيوانات الأليفة” أنه لا يتناسب مع متطلبات العصر الرقمي السريع. فهو يؤدي إلى:

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

الحل السحري: البنية التحتية كشيفرة (Infrastructure as Code – IaC)

البنية التحتية كشيفرة (IaC) هي الممارسة التي تسمح لك بإدارة وتوفير البنية التحتية لتكنولوجيا المعلومات (خوادم، شبكات، قواعد بيانات، جدران حماية، إلخ) من خلال ملفات تكوين قابلة للقراءة الآلية، بدلاً من الإعداد اليدوي أو الأدوات التفاعلية. ببساطة، أنت تكتب “كوداً” يصف البنية التحتية التي تريدها.

عندما تتبنى هذا النهج، تصبح بنيتك التحتية مثل كود تطبيقك تماماً، وهذا يمنحك قوى خارقة:

الفكرة الأساسية هي أن تتعامل مع بنيتك التحتية بنفس الصرامة والانضباط الذي تتعامل به مع كود تطبيقك. ضعها في Git، اختبرها، وأتمِت عملية نشرها.

• الأتمتة والسرعة: يمكنك إنشاء بيئة تطوير أو اختبار أو إنتاج كاملة ومعقدة في دقائق معدودة بتنفيذ أمر واحد.
• الاتساق والتكرارية: وداعاً لمشكلة “لكنها تعمل على جهازي!”. الكود يضمن أن كل بيئة يتم إنشاؤها تكون متطابقة 100%.
• التوثيق الحي: ملفات الكود نفسها هي أفضل وأحدث توثيق لبنيتك التحتية. لا حاجة لكتابة مستندات Word تنتهي صلاحيتها بعد أسبوع.
• التحكم في الإصدارات: باستخدام نظام مثل Git، يمكنك تتبع كل تغيير يتم على بنيتك التحتية، ومعرفة من قام به ومتى ولماذا، والأهم من ذلك، يمكنك التراجع عن أي تغيير بسهولة.
• توفير التكاليف: يمكنك بسهولة تدمير بيئات التطوير والاختبار في نهاية اليوم أو عطلة نهاية الأسبوع وإعادة إنشائها عند الحاجة، مما يوفر الكثير من المال.

تيرافورم (Terraform): الأداة اللي غيّرت اللعبة

هناك العديد من الأدوات لتطبيق IaC (مثل Ansible, Chef, Puppet, CloudFormation)، ولكن الأداة التي أصبحت المفضلة لدي ولدى الكثيرين في هذا المجال هي Terraform من شركة HashiCorp.

ما يميز Terraform هو أنه “إعلاني” (Declarative) و “غير مرتبط بسحابة معينة” (Cloud-Agnostic). دعنا نفكك هذه المصطلحات:

• إعلاني: أنت تصف الحالة النهائية التي تريدها لبنيتك التحتية (أريد سيرفرًا بهذه المواصفات، وقاعدة بيانات بهذا الحجم، وشبكة بهذه القواعد)، وTerraform يتكفل بمعرفة كيفية الوصول إلى هذه الحالة. هذا عكس النهج “الأمري” (Imperative) الذي يتطلب منك كتابة الخطوات بالتفصيل.
• غير مرتبط بسحابة معينة: يمكنك استخدام نفس الأداة ونفس المبادئ لإدارة مواردك على AWS, Azure, Google Cloud, DigitalOcean، وحتى على خوادمك الخاصة (On-premise).

مثال عملي: لنبني سيرفر بسيط على AWS

دعونا نرى كيف يمكننا تحويل فكرة “أريد خادماً” إلى كود. هذا مثال بسيط لإنشاء خادم (EC2 instance) على Amazon Web Services باستخدام Terraform. أنشئ ملفًا باسم `main.tf` وضع فيه الكود التالي:

# 1. تحديد مزود الخدمة السحابية (Provider)
# هنا بنقول لتيرافورم إنّا رح نشتغل مع أمازون في منطقة أيرلندا
provider "aws" {
  region = "eu-west-1"
}

# 2. تعريف المورد (Resource) الذي نريد إنشاءه
# وهو في هذه الحالة خادم EC2
resource "aws_instance" "my_first_server" {
  # Amazon Machine Image (AMI) - هذا هو قالب نظام التشغيل
  # هنا نستخدم نسخة أوبونتو 20.04
  ami           = "ami-0427090fd1714168b" 
  
  # نوع الخادم (حجم المعالج والذاكرة)
  instance_type = "t2.micro"

  # إضافة "وسم" أو اسم لتمييز الخادم
  tags = {
    Name = "MyFirstTerraformServer"
  }
}

هذا كل شيء! هذا الكود البسيط هو وصف كامل لخادم. الآن، لتطبيق هذا على أرض الواقع، كل ما عليك فعله هو فتح الطرفية (Terminal) في نفس المجلد وتنفيذ ثلاثة أوامر بسيطة:

1. terraform init: يقوم بتهيئة المشروع وتنزيل الإضافات اللازمة لمزود الخدمة (AWS في حالتنا).
2. terraform plan: يقرأ الكود ويقارنه بالبنية التحتية الحالية ويُظهر لك خطة العمل (ماذا سيتم إنشاؤه أو تغييره أو حذفه). هذه خطوة مهمة جداً للمراجعة.
3. terraform apply: بعد موافقتك على الخطة، يقوم بتنفيذها وإنشاء الموارد على السحابة.

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

نصائح من خبرة أبو عمر

الانتقال إلى IaC رحلة، وليس وجهة. وهذه بعض النصائح التي تعلمتها بالطريقة الصعبة، وأقدمها لك لتسهيل رحلتك:

• ابدأ صغيراً: لا تحاول تحويل كل بنيتك التحتية الحالية إلى كود دفعة واحدة. ابدأ بمشروع جديد، أو بمكون صغير غير حرج. جرب، تعلم، ثم توسع تدريجياً.
• لا تكرر نفسك (DRY – Don’t Repeat Yourself): إذا وجدت نفسك تنسخ وتلصق كود إنشاء خادم ويب مراراً وتكراراً، فهذا هو الوقت المناسب لتعلم “الوحدات” (Modules) في Terraform. الوحدات تسمح لك بتغليف أجزاء من البنية التحتية وإعادة استخدامها بسهولة.
• خزّن “ملف الحالة” عن بعد وبشكل آمن: يقوم Terraform بتتبع الموارد التي أنشأها في ملف يسمى `terraform.tfstate`. بشكل افتراضي، يتم تخزين هذا الملف محلياً، وهو أمر سيء جداً عند العمل في فريق. تعلم كيفية تكوين “الواجهة الخلفية عن بعد” (Remote Backend) لتخزين هذا الملف في مكان مشترك (مثل AWS S3 bucket) مع تفعيل القفل (State Locking) لمنع شخصين من تعديل البنية التحتية في نفس الوقت. هاي الشغلة أساسية يا جماعة!
• الكود ليس كل شيء: تذكر أن IaC لا يغنيك عن فهم أساسيات الشبكات، الأمان، وأنظمة التشغيل. هو أداة لتطبيق هذه المعرفة بشكل فعال ومتسق، وليس بديلاً عنها.
• اجعلها جزءاً من دورة حياة التطوير (CI/CD): القوة الحقيقية لـ IaC تظهر عندما تدمجها في خطوط الأنابيب الخاصة بك. اجعل `terraform plan` يعمل تلقائياً عند كل Pull Request، واجعل `terraform apply` جزءاً من عملية النشر للبيئات المختلفة.

الخلاصة: ودّع أيام السهر والقلق 😌

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

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