أذكرها وكأنها البارحة، ليلة خميس هادئة، وفنجان القهوة بجانبي والكود أمامي. فجأة، بدأت التنبيهات تنهال على قنوات “سلاك” كالمطر الغزير. النظام الأساسي في بيئة الإنتاج (Production) توقف عن العمل بشكل متقطع، ورسائل الخطأ غريبة وغير مفهومة. “ولعت!”، قلت في نفسي.
اجتمع الفريق على عجل في مكالمة طارئة. أنا وزميلي خليل، بدأنا رحلة البحث عن السبب. فحصنا سجلات الأخطاء (Logs)، راجعنا آخر التحديثات على الكود، لم نجد شيئًا. الكود الذي يعمل بشكل مثالي على بيئة الاختبار (Staging) ينهار في بيئة الإنتاج. مرت ساعة، ثم ساعتان، والضغط يزداد من الإدارة والعملاء. صرخ خليل من يأسه: “يا زلمة شو القصة؟ كل إشي تمام هان، بس هناك خربان!”.
بعد ثلاث ساعات من البحث المضني، وفي لحظة يأس، قررنا مقارنة قائمة الحزم المثبتة على خادم الإنتاج وخادم الاختبار يدويًا. وكانت الصدمة! وجدنا أن مكتبة لمعالجة الصور (ImageMagick) على خادم الإنتاج كانت نسخة أقدم من تلك الموجودة على خادم الاختبار. أحدهم، قبل أشهر، قام بتحديثها يدويًا على خادم الاختبار لحل مشكلة مؤقتة ونسي أن يوثّق الأمر أو يطبقه على باقي الخوادم. كانت تلك الليلة نقطة التحول التي أجبرتنا على مواجهة الوحش الذي صنعناه بأيدينا: “الانحراف التكويني”.
ما هو “الانحراف التكويني” (Configuration Drift)؟ ولماذا هو كابوس المطورين؟
ببساطة، “الانحراف التكويني” هو عندما تبدأ حالة الخوادم والبنية التحتية الفعلية بالابتعاد تدريجيًا عن الحالة الأصلية الموثقة أو المخطط لها. تخيل أنك بنيت بيتين متطابقين تمامًا، وبعد سنة، تجد أن أحدهما تم تغيير نوافذه، والآخر أُضيفت له غرفة على السطح، وكل هذا تم بشكل عشوائي وبدون مخططات محدثة. هذا بالضبط ما يحدث للخوادم.
أسباب الكابوس
- التعديلات اليدوية الطارئة: مثل قصتنا، يقوم مهندس بتثبيت حزمة أو تغيير إعداد لحل مشكلة عاجلة وينسى توثيقها.
- تحديثات غير متزامنة: تحديث خادم ونسيان تحديث الآخرين.
- غياب مصدر الحقيقة الواحد (Single Source of Truth): عندما لا يوجد مكان مركزي وموثوق يصف كيف يجب أن تكون البنية التحتية.
هذا الانحراف هو كابوس حقيقي لأنه يؤدي إلى ظاهرة “بيشتغل عندي!” الشهيرة، حيث يعمل الكود في بيئة ويفشل في أخرى، مما يهدر ساعات ثمينة في تصحيح أخطاء لا علاقة لها بالكود نفسه، بل بالبيئة التي يعمل عليها.
الحل السحري: البنية التحتية كشيفرة (Infrastructure as Code – IaC)
بعد ليلتنا العصيبة تلك، قررنا أن الفوضى يجب أن تنتهي. هنا دخلت “البنية التحتية كشيفرة” أو IaC إلى حياتنا. الفكرة عبقرية في بساطتها: عامل بنيتك التحتية (خوادم، شبكات، قواعد بيانات) بنفس الطريقة التي تعامل بها كود التطبيق.
بدلاً من الدخول إلى كل خادم وتجهيزه يدويًا، نقوم بكتابة ملفات نصية (شيفرة) تصف تمامًا كيف يجب أن يبدو الخادم، ما هي البرامج المثبتة عليه، وكيف يتم تكوين الشبكة. هذه الملفات تصبح هي “مخطط البناء” أو “مصدر الحقيقة”.
“البنية التحتية كشيفرة” تحول إدارة الخوادم من عمل يدوي فني عرضة للخطأ، إلى عملية هندسية دقيقة، موثقة، وقابلة للتكرار.
فوائد لا تقدر بثمن
- الاتساق (Consistency): ضمان أن بيئة التطوير، الاختبار، والإنتاج متطابقة 100%، مما يقضي على الأخطاء المفاجئة.
- السرعة والكفاءة: إنشاء بنية تحتية كاملة ومعقدة في دقائق بدلًا من أيام أو أسابيع.
- التحكم في الإصدارات (Version Control): وضع شيفرة البنية التحتية في Git. يمكنك الآن معرفة من غيّر ماذا، متى، ولماذا. يمكنك أيضًا العودة لإصدار سابق بسهولة.
- تقليل المخاطر والأخطاء البشرية: الأتمتة تقلل من احتمالية نسيان خطوة أو ارتكاب خطأ أثناء التكوين اليدوي.
أدوات المعركة: Terraform و Ansible في الميدان
لخوض هذه المعركة، احتجنا إلى أسلحة مناسبة. هناك العديد من الأدوات، لكننا اعتمدنا على ثنائي قوي أثبت جدارته: Terraform و Ansible.
Terraform: مهندس البناء (Provisioning)
تيرافورم هي الأداة المسؤولة عن “بناء” الموارد الأساسية. هي التي تتواصل مع مزودي الخدمات السحابية (مثل AWS, Azure, Google Cloud) أو حتى الخوادم المحلية لإنشاء الخوادم الافتراضية، قواعد البيانات، الشبكات، موازنات التحميل (Load Balancers)، وكل ما يلزم. أنت تصف “الحالة النهائية” التي تريدها، وتيرافورم تتكفل بالوصول إليها.
مثال: إنشاء خادم افتراضي بسيط باستخدام Terraform
هذا الكود (بلغة HCL) يطلب من AWS إنشاء خادم افتراضي من نوع t2.micro باستخدام نسخة أوبنتو.
# provider.tf
provider "aws" {
region = "eu-west-1"
}
# main.tf
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # Ubuntu Server 20.04 LTS
instance_type = "t2.micro"
tags = {
Name = "WebServer-Prod"
}
}
بمجرد تنفيذ أمر terraform apply، سيقوم تيرافورم بإنشاء هذا الخادم لك تمامًا كما هو موصوف.
نصيحة من أبو عمر: ابدأوا دائمًا بفصل شيفرة Terraform إلى وحدات (Modules) صغيرة قابلة لإعادة الاستخدام. لا تكتبوا كل شيء في ملف واحد ضخم. هيك أسهل للصيانة والتطوير، تمامًا كما نقسّم الكود البرمجي إلى دوال (functions) صغيرة.
Ansible: فنان التجهيز والتكوين (Configuration Management)
بعد أن يقوم Terraform ببناء “الهيكل العظمي” (الخادم الفارغ)، يأتي دور Ansible “لتأثيث” هذا الخادم وتجهيزه. Ansible هو المسؤول عن تثبيت البرامج (مثل خادم الويب Nginx)، إنشاء المستخدمين، نسخ ملفات التطبيق، وتعديل ملفات الإعدادات.
مثال: تثبيت Nginx باستخدام Ansible
هذا الملف (يُسمى Playbook ومكتوب بلغة YAML) يصف الخطوات اللازمة لتثبيت وتفعيل خادم الويب Nginx.
# playbook.yml
- name: Configure web server
hosts: web_servers
become: yes # لتنفيذ الأوامر بصلاحيات المدير (root)
tasks:
- name: Install nginx
apt:
name: nginx
state: latest
update_cache: yes
- name: Start and enable nginx service
service:
name: nginx
state: started
enabled: yes
Ansible يتصل بالخادم عبر SSH وينفذ هذه المهام خطوة بخطوة.
نصيحة من أبو عمر: من أجمل ميزات Ansible أنه لا يحتاج إلى تثبيت أي برامج (agent) على الخوادم التي يديرها، وهذا بخلي الأمور “خفيفة نظيفة”. استفيدوا من خاصية الـ “Idempotency”، والتي تعني أنك لو قمت بتشغيل نفس الـ Playbook عشر مرات، النتيجة النهائية ستكون واحدة ولن يتسبب ذلك في أي فوضى.
رحلتنا من الفوضى إلى النظام: خطوات عملية لتبني الـ IaC
- ابدأ صغيرًا: لا تحاول أتمتة كل شيء دفعة واحدة. اختر خدمة واحدة غير حرجة، وابدأ بأتمتة عملية إنشائها وتكوينها.
- كل شيء في Git: منذ اليوم الأول، ضع كل شيفرة الـ IaC (ملفات Terraform و Ansible) في نظام إدارة الإصدارات Git. طبق عليها نفس صرامة مراجعة الكود (Code Review) التي تطبقها على كود تطبيقك.
- الأتمتة، ثم الأتمتة: اربط تنفيذ شيفرة الـ IaC مع أنظمة التكامل والنشر المستمر (CI/CD). يجب أن يكون تشغيل
terraform applyعملية مؤتمتة تتم عبر Pipeline، وليس من جهاز أحد المطورين. - امنع التعديلات اليدوية تمامًا: هذه هي الخطوة الأصعب ثقافيًا. يجب أن يتفق الفريق على أن أي تغيير، مهما كان بسيطًا، يجب أن يتم عبر تعديل الشيفرة وطلب دمج (Pull Request). أي تعديل يدوي على الخوادم هو “جريمة” يجب التراجع عنها فورًا.
خلاصة الحكاية ونصيحة من القلب 🇵🇸
الانتقال إلى “البنية التحتية كشيفرة” لم يكن مجرد تغيير تقني، بل كان تحولًا جذريًا في ثقافتنا كفريق. في البداية كان هناك بعض المقاومة والخوف من المجهول، ولكن النتائج كانت مذهلة. لقد قضينا على الانحراف التكويني، وأصبحت عملية نشر تحديثات أو إنشاء بيئات جديدة أمرًا روتينيًا يستغرق دقائق، بدلاً من كونه مغامرة محفوفة بالمخاطر.
يا جماعة الخير، لا تسمحوا لخوادمكم بأن تصبح نسخًا مشوهة وغامضة. ابدأوا اليوم، ولو بخطوة صغيرة. تعلموا Terraform، جربوا Ansible. الاستثمار في أتمتة بنيتكم التحتية هو أفضل استثمار يمكن أن تقوموا به لضمان استقرار وسرعة مشاريعكم. صدقوني، لما تشوفوا أول بنية تحتية كاملة تنشأ بكبسة زر خلال دقائق، وهي نسخة طبق الأصل عن غيرها، رح تعرفوا إنه كل التعب بستاهل. يلا، شدّوا حيلكم! 💪
