لماذا إدارة الإعدادات؟

لماذا إدارة الإعدادات؟

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

إدارة الإعدادات هي المنهجية — والأدوات — التي تُغلق تلك الفجوة. إنها تجيب على سؤال بسيط في ظاهره وعميق في جوهره: كيف تضمن أن كل جهاز في أسطولك مُهيَّأ تماماً كما هو مقصود، في جميع الأوقات، حتى مع تغيير المهندسين للإعدادات وتحديث الحزم وترك الحوادث لإصلاحات عشوائية؟

Ansible هو الإجابة الصناعية المعيارية للتهيئة على مستوى نظام التشغيل. قبل أن تكتب playbook واحدة، عليك أن تشعر بالمشاكل التي تحلها.

انجراف الإعدادات: القاتل الصامت

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

إليك تسلسل واقعي من الأحداث على أسطول إنتاجي بدون إدارة إعدادات:

1. الأسبوع الأول: يُصلح مهندس خدمة معطوبة بتعديل /etc/nginx/nginx.conf مباشرةً على الخادم. لا يُودَع الإصلاح في أي مستودع.
2. الأسبوع الرابع: يُعطّل فريق الأمن TLS 1.0 بإضافة سطر إلى /etc/ssl/openssl.cnf على عقدة واحدة للاختبار، ثم ينسى تطبيقه على بقية العقد الأحد عشر في المجموعة.
3. الأسبوع التاسع: يُطبَّق تحديث النواة على تسعة من اثني عشر خادماً خلال نافذة صيانة؛ انقطاع الشبكة يتسبب في تخطي الثلاثة المتبقية. تشغّل الاثنا عشر عقدة الآن إصدارات نواة مختلفة.
4. الأسبوع الخامس عشر: يُشغّل مهندس مبتدئ pip install --upgrade requests على app-server-07 لتشخيص مشكلة مكتبة. ترقية الإصدار تكسر تبعية على تلك العقدة وحدها بصمت.
5. الأسبوع السادس عشر: تبدأ الخدمة برمي أخطاء 500 بشكل متقطع. الأخطاء تؤثر على 25% فقط من الطلبات لأن 25% فقط من حركة المرور تصل مصادفةً إلى العقد المنجرفة. يستغرق التشخيص ست ساعات.

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

خوادم ندفة الثلج: النمط المضاد

خادم ندفة الثلج (Snowflake Server) هو مضيف انجرف بعيداً جداً عن أي خط أساس موثق حتى أصبح لا يمكن الاستغناء عنه. مثل ندفة ثلج حقيقية، لا يوجد اثنان متشابهان — ومثل ندفة الثلج، هم هشّون.

أعراض خوادم ندفة الثلج في الإنتاج:

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

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

Push مقابل Pull: النموذجان للإعدادات

أدوات إدارة الإعدادات تنقسم عموماً إلى نموذجين معماريين. فهم الفرق بينهما يُحدد أي أداة تناسب أي بيئة — ويُبلّغ مباشرةً لماذا اتخذ Ansible الخيارات المعمارية التي اتخذها.

نموذج Push: نهج Ansible

في نموذج Push، تتصل عقدة تحكم مركزية بالعقد المدارة عبر SSH (أو WinRM لـ Windows)، وتنقل حمولة Python صغيرة، وتنفّذها، وتُعيد النتائج. لا تحتاج العقد المدارة إلى عميل يعمل بشكل دائم — فقط Python ودايمون SSH، وكلاهما موجود بشكل افتراضي على كل خادم Linux تقريباً.

Ansible هو الأداة النموذجية لنموذج Push. عندما تشغّل playbook، يقوم Ansible بـ:

1. قراءة المخزون (inventory) — قائمة المضيفين والمجموعات.
2. فتح اتصالات SSH متوازية لجميع المضيفين المستهدفين.
3. إرسال وحدات Python مضغوطة إلى مجلد مؤقت على كل مضيف.
4. تنفيذ الوحدات؛ تُجري التغييرات اللازمة وتُعيد نتيجة JSON.
5. تنظيف الملفات المؤقتة وإغلاق الاتصالات.

التداعية الحاسمة: يعمل Ansible فقط عند استدعائه. إذا غيّر مهندس ملفاً على عقدة بعد ساعة من تشغيل الـ playbook، فـ Ansible لا يعلم بذلك. يجب جدولة تشغيل الـ playbook (عبر cron أو AWX أو Ansible Automation Platform) لإعادة فرض الحالة المطلوبة بشكل دوري — التطبيق دوري لا مستمر.

نموذج Pull: Puppet وChef وCFEngine

في نموذج Pull، تشغّل كل عقدة مدارة دايمون عميل دائم. يتصل العميل دورياً بخادم سياسة مركزي (كل 30 دقيقة بشكل افتراضي في Puppet)، ويسترجع الحالة المطلوبة الحالية ("catalog" أو "cookbook")، ويقارنها بالواقع المحلي، ويُطبّق أي تغييرات تصحيحية — كل ذلك بدون أي تدخل بشري.

أدوات Pull مثل Puppet وChef كانت النموذج السائد لإدارة الإعدادات في شركات الحجم الكبير خلال أواخر العقد الأول والأول من الألفية الثالثة. تتميز بـ التطبيق المستمر: إذا تغيّر ملف يدوياً على عقدة، يصحح العميل ذلك خلال 30 دقيقة تلقائياً. المقايضة هي التعقيد التشغيلي: يجب صيانة خادم سياسة متاح بشكل كبير، وإدارة شهادات TLS لمصادقة العميل-الخادم، وتثبيت وصيانة العميل على كل عقدة تديرها — بما في ذلك أثناء التهيئة الأولية، التي تصبح مشكلة الدجاجة والبيضة.

ما يديره Ansible: نطاق الإعدادات

قبل كتابة مهمة واحدة، من المفيد تعداد ما تتحكم فيه إدارة الإعدادات فعلاً على مستوى نظام التشغيل. يمكن لـ Ansible إدارة:

• الحزم — تثبيت أو إزالة أو تثبيت إصدارات محددة من حزم نظام التشغيل عبر apt أو yum أو dnf أو pip.
• الملفات والقوالب — نشر ملفات الإعداد من قوالب Jinja2، وتعيين الأذونات والملكية وسياقات SELinux.
• الخدمات — ضمان عمل الدايمونات (أو إيقافها)، وتفعيلها عند الإقلاع، وإعادة تشغيلها عند تغيير الإعداد.
• المستخدمون والمجموعات — إنشاء حسابات الخدمة، وتعيين مفاتيح SSH المصرّح بها، وإدارة قواعد sudo.
• قواعد الجدار الناري — إدارة قواعد iptables أو firewalld أو ufw بشكل تصريحي.
• معامل النواة — تعيين قيم sysctl (مثل net.core.somaxconn للأحمال عالية الاتصال).
• التحميل والتخزين — تهيئة الأقسام، وإعداد LVM، وإدارة إدخالات /etc/fstab.
• موارد السحابة — عبر وحدات المزوّد، يمكن لـ Ansible أيضاً توفير EC2 على AWS وأجهزة Azure الافتراضية ومثيلات GCP — رغم أن Terraform هو المفضل لتلك الطبقة.

مجتمعة، تتيح لك هذه البدائيات وصف الحالة المقصودة الكاملة للخادم كـ code — قابلة للإصدار، وقابلة للمراجعة، وقابلة للإعادة الإنتاج.

هاتان المهمتان، مُطبَّقتان على مئة خادم بشكل متوازٍ، تضمنان أن nginx في الحالة الصحيحة على كل واحد منها — بصرف النظر عما فُعل على تلك الخوادم يدوياً قبل تشغيل الـ playbook. هذا هو القيمة الجوهرية لإدارة الإعدادات: الحالة المطلوبة تفوز على التاريخ المتراكم.

نظام Ansible البيئي في عام 2025

Ansible نفسه هو أداة سطر الأوامر مفتوحة المصدر (ansible وansible-playbook وansible-galaxy). تشحن Red Hat طبقتين تجاريتين فوقه:

• AWX — واجهة الويب مفتوحة المصدر، وREST API، ومجدوِل المهام لـ Ansible. مستضاف ذاتياً.
• Ansible Automation Platform (AAP) — المنتج التجاري المدعوم من Red Hat (يعمل AAP 2.x على Kubernetes). تستخدمه معظم شركات Fortune 500 التي تشغّل Ansible على نطاق واسع.

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

بقية هذا الدرس التعليمي يبنيك من الصفر إلى ممارس Ansible كامل: تصميم المخزون، والوحدات، والـ playbooks، والمتغيرات والقوالب، والأدوار، وإدارة الأسرار باستخدام Ansible Vault، والتوسع لمئات المضيفين، ومشروع ختامي يُهيّئ أسطولاً واقعياً متعدد العقد. في النهاية، ستتمكن من استبدال أي خادم ندفة ثلج في أسطولك بإعداد قابل للإعادة الإنتاج ومتحكم في إصداره — وتفعل ذلك في دقائق لا ساعات.