كانت خوادمنا كائنات أليفة: كيف أنقذتنا ‘البنية التحتية كشيفرة’ (IaC) من جحيم التكوينات اليدوية؟

يا جماعة الخير، السلام عليكم ورحمة الله.

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

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

بعد ما رجعت الأمور لمجراها بشق الأنفس، قعدت مع حالي الصبح وأنا بشرب فنجان القهوة، وطلّعت على دفتر ملاحظاتي المليان “خربشات” عن إعدادات “صامد”. وقتها أدركت الحقيقة المُرّة: خوادمنا كانت كائنات أليفة (Pets)، مش قطيع ماشية (Cattle).

وهون يا جماعة كانت نقطة التحول اللي ودّتنا لعالم جديد اسمه “البنية التحتية كشيفرة” أو Infrastructure as Code (IaC).

ما قصة “الحيوانات الأليفة” و “الماشية”؟

قبل ما نخوض في التفاصيل التقنية، خلوني أبسّط هالمفهوم اللي هو أساس كل القصة. في عالم إدارة الخوادم، في فلسفتين:

• نموذج الحيوانات الأليفة (Pets): كل سيرفر له اسم (زي “صامد” تبعنا)، بنعتني فيه بشكل فردي، بنحدّثه يدويًا، وإذا “مرض” أو تعطل، بنعمل المستحيل عشان “نعالجه” ونرجعه للحياة. مشكلته؟ لو مات، المصيبة بتكون كبيرة جدًا.
• نموذج قطيع الماشية (Cattle): كل الخوادم عبارة عن نسخ متطابقة من بعضها، ما الها أسماء مميزة، مجرد أرقام (web-server-01, web-server-02). إذا تعطل واحد منها، ما “بنعالجه”، ببساطة “بنتخلص” منه وبنجيب واحد جديد مطابق تمامًا مكانهبكبسة زر.

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

مرحبًا بك في عالم البنية التحتية كشيفرة (IaC)

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

تخيل إنك بتبني بيت. الطريقة القديمة (اليدوية) هي إنك تجيب العمّال وتبلش تحكيلهم: “ابنوا هون حيط، حطوا هون شباك، مدّدوا هون ماسورة…”، وكل بيت رح يطلع شكل مختلف شوي. أما طريقة الـ IaC، هي إنك تعطي المهندس مخططات هندسية دقيقة (الشيفرة)، وهو بيعطيها للعمّال (الأداة)، والنتيجة؟ بتقدر تبني 100 بيت متطابقين تمامًا بنفس المخططات وبسرعة خيالية.

ليش الـ IaC غيرت حياتنا كفريق؟

1. الاتساق (Consistency): كل الخوادم اللي بنبنيها صارت شبه بعض 100%. ما في إعداد “منسي” أو مكتبة ناقصة. المخطط واحد والنتيجة واحدة.
2. السرعة والكفاءة: بدل ما أقضي ساعات في إعداد سيرفر جديد يدويًا، صرت أقدر أبني بنية تحتية كاملة لتطبيق جديد في دقائق عن طريق تشغيل سكربت بسيط.
3. إدارة الإصدارات (Version Control): بما إنه البنية التحتية صارت مجرد كود، صرنا نقدر نحفظها على Git مثلًا. هاد معناه إنه بنقدر نشوف مين غيّر إيش ومتى، ونقدر نرجع لإصدار أقدم بسهولة لو صارت مشكلة. وداعًا لسؤال “مين آخر واحد لمس السيرفر؟”.
4. التعافي من الكوارث (Disaster Recovery): لو السيرفر “صامد” الجديد تعطل اليوم (لا سمح الله)، ما رح نسهر للصبح. بكبسة زر، بنحذفه وبنبني واحد جديد مطابق له تمامًا في دقائق معدودة.
5. تقليل التكاليف: الأتمتة قللت الوقت والجهد اليدوي، وسمحت لنا نبني ونهدّم بيئات التطوير والاختبار بسهولة، فصرنا ندفع فقط مقابل الموارد اللي بنستخدمها فعليًا.

Terraform: الأداة التي اخترناها لهذه المهمة

هناك العديد من أدوات الـ IaC مثل AWS CloudFormation, Azure ARM Templates, Ansible, Pulumi. لكننا في النهاية استقرينا على Terraform من شركة HashiCorp، والسبب بسيط: هي الأداة الأشهر، تدعم معظم مزودي الخدمات السحابية (AWS, Azure, Google Cloud, وغيرهم كثير)، ومجتمعها ضخم جدًا.

Terraform بتستخدم لغة بسيطة اسمها HCL (HashiCorp Configuration Language). الفكرة منها إنك بتوصف “الحالة النهائية” اللي بدك ياها للبنية التحتية، و Terraform بتتكفل بمعرفة كيفية الوصول لهي الحالة.

مثال عملي: بناء أول سيرفر “ماشية” لنا

خلونا نشوف مثال بسيط جدًا لكيفية بناء سيرفر (EC2 instance) على AWS باستخدام Terraform. هذا هو تقريبًا أول كود كتبناه في رحلتنا.

أول شيء، بنعمل ملف اسمه main.tf:

# 1. تحديد مزود الخدمة السحابية (هنا AWS) والمنطقة
provider "aws" {
  region = "eu-west-1" # منطقة أيرلندا على سبيل المثال
}

# 2. تحديد مصدر البيانات: هنا نبحث عن آخر نسخة من نظام Ubuntu
data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # هذا رقم حساب Canonical الرسمي لأوبنتو
}

# 3. تعريف المورد: هذا هو السيرفر الفعلي
resource "aws_instance" "my_first_cattle" {
  ami           = data.aws_ami.ubuntu.id # استخدم النسخة اللي لقيناها فوق
  instance_type = "t2.micro"            # أصغر حجم سيرفر للتجربة

  tags = {
    Name = "MyFirstCattleServer" # مجرد اسم وصفي، مش زي اسم "صامد"
  }
}

شرح الكود ببساطة:

• Provider: بنحكي لـ Terraform إنه رح نشتغل مع AWS.
• Data: بنطلب من Terraform يبحث عن معلومة معينة، وهي آخر نسخة رسمية من نظام التشغيل Ubuntu. هذا بيضمن إنه دائمًا بنستخدم أحدث نسخة آمنة.
• Resource: هذا هو قلب الموضوع. هون بنوصف السيرفر اللي بدنا ياه: نوعه، نظام التشغيل تبعه (اللي جبناه من الخطوة السابقة)، وشوية معلومات وصفية (Tags).

خطوات التنفيذ السحرية:

بعد ما نكتب هذا الكود، كل اللي علينا نعمله هو فتح الـ Terminal في نفس المجلد وتشغيل ثلاث أوامر بسيطة:

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

هذا هو السحر يا جماعة. نفس الكود بقدر أشاركه مع فريقي، وبقدروا يبنوا نسخة طبق الأصل من السيرفر عندي بـ 3 أوامر بسيطة.

نصائح من خبرة أبو عمر في الـ IaC

الطريق ما كان كله وردي، وغلطنا كثير وتعلمنا أكثر. من خبرتي، حاب أعطيكم شوية نصائح عملية:

نصيحة 1: ابدأ صغيرًا. لا تحاول أتمتة كل بنيتك التحتية مرة واحدة. ابدأ بمشروع صغير وغير حيوي. مثلًا، بيئة تطوير لأحد المبرمجين. تعلم، واغلط، وصلّح، وبعدين انتقل للأشياء الأكبر.

نصيحة 2: حالة البنية التحتية (State) هي كنزك. Terraform بحفظ الوضع الحالي للبنية التحتية في ملف اسمه terraform.tfstate. هذا الملف مقدس! لا تعدله يدويًا أبدًا. ومن أول يوم، تعلم كيف تخزنه عن بعد (Remote Backend) على خدمة مثل AWS S3، عشان كل الفريق يشتغل على نفس النسخة منه.

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

نصيحة 4: لا تلمس الواجهة الرسومية أبدًا! بعد ما تتبنى الـ IaC، لازم تلزم حالك وفريقك إنه أي تغيير على البنية التحتية لازم يتم من خلال الكود فقط. أي تغيير يدوي من واجهة AWS أو Azure رح يسبب “انحراف” (Drift) بين الكود والواقع، وهون بتبلش المشاكل ترجع.

الخلاصة: من الفوضى إلى النظام 💡

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

صحيح، “صامد” الأصلي رح يضل له مكانة خاصة في قلبي، لأنه علمني درس قاسي لكن مهم. اليوم، كل خوادمنا هي “صامد”، لكنها نسخ متطابقة، قوية، وقابلة للاستبدال. وصرت أقدر أنام بالليل وأنا مرتاح البال، حتى لو رن تلفوني الساعة 2 الصبح، رح تكون الإجابة بسيطة: “احذفه، وشغّل الـ terraform apply”.

نصيحتي الأخيرة لكل مطور أو مدير نظام: لا تنتظروا ليلة الكارثة اللي عشتها أنا. ابدأوا اليوم بتعلم الـ IaC. الرحلة قد تبدو طويلة، لكن صدقوني، كل خطوة فيها تستحق العناء. بالتوفيق يا جماعة!