كان كل خادم حالة فريدة: كيف أنقذنا Ansible من جحيم ‘الانحراف في الإعدادات’ (Configuration Drift)؟

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

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

قضينا الساعات الثلاث التالية ندخل يدويًا عبر SSH على كل خادم من خوادمنا العشرين، ننفذ نفس الأوامر مرارًا وتكرارًا (`dpkg -l | grep a7san-lib`، `apt-get remove …`) لنتأكد أن الإعدادات متطابقة. في تلك الليلة، أدركت أننا لا ندير بنية تحتية، بل ندير حديقة حيوانات أليفة، كل خادم فيها له اسمه وشخصيته ومشاكله الفريدة. كان هذا هو جحيم “الانحراف في الإعدادات”، وقررت أن هذه ستكون آخر ليلة نقضيها كإطفائيين.

ما هو “الانحراف في الإعدادات” (Configuration Drift)؟ وليش هو كابوس؟

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

من وين بيجي هالانحراف؟

• الإصلاحات السريعة (Hotfixes): مثل ما حصل معنا، تدخل على خادم الإنتاج مباشرةً لتحل مشكلة وتنسى تطبيق نفس الحل على البقية.
• التحديثات اليدوية: يقوم مهندس بتحديث حزمة على خادم واحد لاختبار شيء ما، وينسى إعادته لحالته الأصلية.
• الأعضاء المختلفون في الفريق: كل واحد منا له طريقته في حل المشاكل، واحد بستخدم `apt` والثاني `dpkg`، واحد بغير الملف X والثاني بغير الملف Y. النتيجة؟ فوضى.
• غياب التوثيق: التغييرات التي لا يتم تسجيلها، كأنها لم تكن… حتى تسبب كارثة.

النتيجة كانت كارثية: بيئة غير متوقعة، صعوبة في نشر التحديثات، فشل في استعادة النظام بعد الكوارث، ووقت ضائع لا يقدر بثمن في تتبع مشاكل “غريبة” تحدث على خادم واحد فقط.

الدخول إلى عالم “البنية التحتية ككود” (IaC) و Ansible

كان الحل واضحًا: يجب أن نتعامل مع خوادمنا كما نتعامل مع الكود البرمجي. يجب أن تكون الحالة المطلوبة لكل خادم مكتوبة في ملف، يمكننا وضعه في Git، مراجعته، واختباره، وتطبيقه بشكل آلي. هذا هو جوهر مفهوم “البنية التحتية ككود” (Infrastructure as Code – IaC).

بعد بحث وتقصي، وقع اختيارنا على Ansible. ليش بالذات؟

ليش Ansible بالذات؟ (مش أي أداة تانية)

• بدون عميل (Agentless): هذه كانت الميزة القاتلة. Ansible لا يتطلب تثبيت أي برنامج خاص على الخوادم التي تريد إدارتها. كل ما يحتاجه هو اتصال SSH، وهو موجود بالفعل على كل خوادم لينكس. يعني “ما في وجعة راس” في تثبيت وصيانة برامج إضافية.
• بسيط ومقروء (YAML): ملفات الإعدادات في Ansible (اسمها Playbooks) مكتوبة بلغة YAML، وهي لغة سهلة القراءة والكتابة تشبه قائمة المهام. أنت تصف “الحالة النهائية” التي تريدها للخادم، و Ansible يتكفل بالباقي.
• التكرارية (Idempotency): هذه هي الكلمة السحرية. معناها أنك لو شغّلت نفس الأمر 100 مرة، النتيجة ستكون نفسها كأنك شغلته مرة واحدة. Ansible يتحقق من الحالة الحالية، وإذا كانت مطابقة لما طلبته، لا يفعل شيئًا. وإذا كانت مختلفة، يقوم بالتغييرات اللازمة فقط. هذا هو السلاح الفتاك ضد الانحراف في الإعدادات.

من الفوضى إلى النظام: خطواتنا العملية مع Ansible

بدأنا رحلتنا لتحويل حديقة الحيوانات الأليفة إلى قطيع من الماشية المتطابقة. إليك كيف فعلنا ذلك خطوة بخطوة.

1. جرد الأصول (Inventory): أول اشي، اعرف شو عندك

أول خطوة هي أن تخبر Ansible عن الخوادم التي يملكها. هذا يتم عبر ملف بسيط يسمى “ملف الجرد” (Inventory file). قمنا بإنشاء ملف `hosts` وجمعنا فيه كل خوادمنا وقمنا بتصنيفها.

نصيحة أبو عمر: التصنيف هو مفتاح القوة. لا تضع كل خوادمك تحت قائمة واحدة. صنفها حسب وظيفتها (web, db, cache) أو بيئتها (production, staging). هذا يسمح لك بتطبيق إعدادات مختلفة على مجموعات مختلفة بسهولة.

# inventory/production

[webservers]
web1.mysite.com
web2.mysite.com
web3.mysite.com

[dbservers]
db1.mysite.com

[all:vars]
ansible_user=aboomar
ansible_ssh_private_key_file=~/.ssh/id_rsa

في هذا المثال، عرفنا مجموعتين: `webservers` و `dbservers`. كما وضعنا بعض المتغيرات العامة مثل اسم المستخدم ومفتاح SSH الذي سيستخدمه Ansible للاتصال.

2. كتابة أول “وصفة” (Playbook)

الـ Playbook هو قلب Ansible النابض. إنه ملف YAML الذي تصف فيه المهام التي تريد تنفيذها. قررنا أن نبدأ بشيء بسيط: التأكد من أن خادم الويب Nginx مثبت ويعمل على كل خوادم الويب.

---
- name: Configure and Harden Web Servers
  hosts: webservers
  become: yes # Execute tasks with root privileges (sudo)

  tasks:
    - name: Ensure nginx is installed at the latest version
      apt:
        name: nginx
        state: latest
        update_cache: yes
      notify: Restart Nginx

    - name: Ensure our custom nginx config is in place
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart Nginx

    - name: Ensure nginx service is started and enabled on boot
      service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

دعنا نفصّل هذا الكود “شقفة شقفة”:

• hosts: webservers: هذا يخبر Ansible بتطبيق هذه الوصفة على كل الخوادم الموجودة في مجموعة `webservers` في ملف الجرد.
• become: yes: هذا يعادل استخدام `sudo`، لأن تثبيت البرامج وتعديل ملفات النظام يتطلب صلاحيات المدير.
• tasks:: هذه هي قائمة المهام. Ansible ينفذها بالترتيب.
• المهمة الأولى: تستخدم وحدة apt للتأكد من أن حزمة nginx مثبتة بآخر إصدار (state: latest).
• المهمة الثانية: تستخدم وحدة template لنسخ ملف إعدادات Nginx مخصص من جهازنا المحلي إلى الخادم. هذا يضمن أن كل خوادم الويب لديها نفس الإعدادات بالضبط.
• المهمة الثالثة: تستخدم وحدة service للتأكد من أن خدمة Nginx تعمل الآن (state: started) وستعمل تلقائيًا عند إعادة تشغيل الخادم (enabled: yes).
• handlers:: هذه مهام خاصة لا تعمل إلا إذا تم استدعاؤها. لاحظنا وجود notify: Restart Nginx بعد المهام التي تغير الإعدادات. هذا يعني: “إذا تغير ملف الإعدادات، قم بتشغيل الـ handler المسمى Restart Nginx”. هذا أكثر كفاءة من إعادة تشغيل الخدمة في كل مرة.

3. القضاء على الانحراف: قوة التكرار (Idempotency) في العمل

الآن يأتي السحر. بعد تشغيل هذا الـ Playbook لأول مرة، قام Ansible بتثبيت Nginx وضبط إعداداته على كل الخوادم. ولكن ماذا لو قام أحدهم بإيقاف الخدمة يدويًا على أحد الخوادم لحل مشكلة ما؟

في السابق، كان هذا الخادم سيبقى “مختلفًا” حتى نكتشف المشكلة بالصدفة. الآن، كل ما علينا فعله هو تشغيل نفس الـ Playbook مرة أخرى. سيقوم Ansible بالتحقق من كل خادم:

• هل Nginx مثبت؟ نعم. (OK, no change)
• هل ملف الإعدادات هو نفسه؟ نعم. (OK, no change)
• هل الخدمة تعمل؟ لا! إنها متوقفة. (CHANGED) -> سيقوم Ansible بتشغيل الخدمة تلقائيًا.

أصبح بإمكاننا تشغيل هذا الـ Playbook كل ساعة، وكل يوم. أصبح هو “مصدر الحقيقة” (Source of Truth) لحالة خوادمنا. أي انحراف يتم تصحيحه تلقائيًا وبسرعة. ودّعنا جلسات الـ SSH اليدوية إلى الأبد. ✅

نصائح من “الختيار” أبو عمر

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

1. كل شيء في Git: من اليوم الأول، ضع ملفات الـ Playbooks، الـ Inventory، والـ templates في مستودع Git. هذا يعطيك سجلًا تاريخيًا، إمكانية مراجعة التغييرات (Pull Requests)، والقدرة على العودة لإصدار سابق إذا حدث خطأ. الكود اللي مش في Git، كأنه مش موجود.
2. استخدم الـ Roles: عندما تكبر مشاريعك، لا تضع كل شيء في ملف Playbook واحد. قم بتقسيم المنطق إلى “أدوار” (Roles) قابلة لإعادة الاستخدام. مثلاً، `role-nginx`، `role-database`، `role-monitoring`. هذا يجعل الكود أنظف وأسهل في الإدارة.
3. لا تخترع العجلة: مجتمع Ansible ضخم. قبل أن تكتب Role من الصفر لتثبيت برنامج مشهور (مثل Postgres أو Redis)، ابحث في Ansible Galaxy. غالبًا ستجد Role جاهزًا، موثوقًا، ومستخدمًا من قبل الآلاف.
4. التحقق قبل التنفيذ (Dry Run): هذه أهم نصيحة. قبل تطبيق أي تغيير على خوادم الإنتاج، استخدم الأمر ansible-playbook --check my_playbook.yml. هذا سيُظهر لك بالضبط ما هي التغييرات التي سيقوم بها Ansible دون أن ينفذها فعليًا. لقد أنقذتني هذه الميزة من كوارث لا حصر لها.

الخلاصة: من الإطفائي إلى المهندس ✨

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

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