كتابة ملفات الجرد (Inventory) لتعريف وتصنيف الخوادم

ملف الجرد هو النقطة التي تبدأ منها أي عملية أتمتة حقيقية في بيئات الخوادم. فعندما تستخدم Ansible لإدارة عشرات أو مئات العقد، فإن أول سؤال هندسي ليس: ما هو الأمر الذي سنشغله؟ بل: كيف سنعرّف هذه الخوادم ونصنفها بطريقة تسمح بالتوسع، والعزل، وإعادة الاستخدام؟ هنا يظهر دور Inventory باعتباره خريطة تشغيلية دقيقة للبنية التحتية.

في المشاريع الصغيرة قد يبدو الملف مجرد قائمة عناوين IP، لكن في البيئات المتقدمة يتحول إلى طبقة تنظيم كاملة تحدد المجموعات، والبيئات، وأنواع التطبيقات، ومتغيرات الاتصال، وسياسات النشر. وهذا مهم جداً إذا كنت تربط الأتمتة مع مسارات CI/CD أو مع إجراءات النشر المستمر للخدمات.

ما هو ملف الجرد ولماذا يعد أساسياً؟

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

الفائدة الحقيقية لا تكمن في التعريف فقط، بل في التصنيف. عندما تنشئ مجموعة باسم web وأخرى باسم db وثالثة باسم staging، فأنت تبني لغة تشغيل تساعدك لاحقاً في تنفيذ Playbooks دقيقة، وتوجيه النشر إلى بيئة دون أخرى، وربط ذلك مع سياسات الفروع وعمليات التسليم الآلي.

أبسط شكل لملف الجرد الثابت

يمكن كتابة الجرد بصيغة INI أو YAML. ورغم أن الصيغة التقليدية منتشرة، فإن الصيغة الهيكلية باستخدام YAML تصبح أوضح في البيئات المركبة وتندمج بشكل ممتاز مع بقية ملفات البنية التحتية ككود.

all:
  children:
    web:
      hosts:
        web-01:
          ansible_host: 192.168.1.10
        web-02:
          ansible_host: 192.168.1.11
    db:
      hosts:
        db-01:
          ansible_host: 192.168.1.20

في المثال السابق لدينا مجموعة رئيسية اسمها all، وتحتها مجموعات أبناء. كل خادم يحمل اسماً منطقياً مستقراً، بينما يحتفظ الحقل ansible_host بعنوانه الحقيقي. هذا الفصل مفيد جداً عندما يتغير العنوان الفعلي لكنك تريد بقاء الاسم المستخدم في الأتمتة كما هو.

تصنيف الخوادم بطريقة تخدم البنية والتشغيل

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

تصنيف حسب الدور التشغيلي

• مجموعة web لخوادم الواجهة الأمامية أو Nginx.
• مجموعة app لعقد التطبيقات أو الخدمات الخلفية.
• مجموعة db لخوادم قواعد البيانات.
• مجموعة monitoring لأدوات الرصد والتنبيهات.

تصنيف حسب البيئة

• development للتجارب والتطوير.
• staging للمحاكاة القريبة من الإنتاج.
• production للخدمات الحية.

هذا النمط يصبح بالغ الأهمية عندما تربط النشر التلقائي مع النشر المستمر (Continuous Deployment): رفع الكود الجديد إلى سيرفر Linux تلقائياً، لأن نفس Playbook يمكنه استهداف بيئة محددة اعتماداً على المجموعة لا على تعديل يدوي خطير.

استخدام المتغيرات داخل ملف الجرد

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

all:
  vars:
    ansible_user: deploy
    ansible_port: 22
  children:
    production:
      vars:
        app_env: production
      hosts:
        app-01:
          ansible_host: 10.0.1.10
        app-02:
          ansible_host: 10.0.1.11
    staging:
      vars:
        app_env: staging
      hosts:
        stage-01:
          ansible_host: 10.0.2.10

بهذا الأسلوب يمكن للأدوار والمهام أن تقرأ المتغير app_env وتضبط السلوك تلقائياً. كما أن هذا يتكامل بشكل ممتاز مع مفاهيم تمرير المتغيرات البيئية (Environment Variables) للحاويات بشكل آمن عندما تكون التطبيقات منشورة داخل حاويات.

الهيكلة الاحترافية للمجلدات

في المشاريع الإنتاجية لا يُنصح بوضع كل شيء في ملف واحد ضخم. الأفضل هو تقسيم الجرد إلى ملفات ومجلدات تعكس البيئات والمجموعات، وتسهّل القراءة والمراجعة داخل فرق DevOps.

inventories/
├── production/
│   ├── hosts.yml
│   ├── group_vars/
│   │   ├── web.yml
│   │   └── db.yml
│   └── host_vars/
│       └── app-01.yml
└── staging/
    ├── hosts.yml
    └── group_vars/
        └── web.yml

هذا التنظيم يجعل مراجعات Git أوضح، ويخفف التعارضات بين أعضاء الفريق، خاصة إذا كنتم تعملون وفق ممارسات مثل استراتيجيات العمل الجماعي: نظام GitHub Flow وكيف تعمل الشركات الكبرى؟.

فحص ملف الجرد قبل التنفيذ

من الممارسات الذكية اختبار الجرد قبل استخدامه في مهام فعلية. ذلك يمنع استهداف خوادم خاطئة أو اكتشاف أخطاء هيكلية أثناء وقت النشر. يمكنك استخدام أمر الفحص لاستخراج البنية كما يراها Ansible.

ansible-inventory -i inventories/production/hosts.yml --list

ansible all -i inventories/production/hosts.yml -m ping

الأمر الأول يعرض التمثيل الكامل للمجموعات والمتغيرات، أما الأمر الثاني فيؤكد صحة الاتصال. وإذا كنت قد أعددت الوصول الآمن مسبقاً عبر إعداد الاتصال الآمن (SSH Keys) بدون كلمات مرور بين جهازك والخوادم فستصبح اختبارات الوصول أكثر استقراراً وأمناً.

لا تضع خوادم production وstaging في مجموعة تشغيل واحدة بدون فصل واضح، لأن أي أمر جماعي أو Playbook غير منضبط قد يسبب Downtime أو تعديلات مباشرة على البيئة الحية.

العلاقة بين ملفات الجرد وخطوط النشر المؤتمتة

في البنى الحديثة، لا يعيش ملف الجرد بمعزل عن خط الأنابيب. بل غالباً ما يُستدعى من مهام Pipeline لتحديد وجهة النشر بعد نجاح الاختبارات. لذلك فإن أي خطأ في التصنيف سيؤدي إلى خطأ في الاستهداف، مهما كانت جودة خطوات البناء أو الاختبار.

عند تنفيذ نشر آلي من GitHub Actions أو Jenkins، يمكنك تمرير بيئة مستهدفة مثل production أو staging، فيتم اختيار ملف الجرد المناسب تلقائياً. وهذا ينسجم مع ما شرحناه سابقاً في مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) ومشروع عملي: بناء CI/CD كامل يختبر وينشر تطبيق ويب إلى السيرفر آلياً.

احرص على أن تكون صلاحيات حساب النشر المستخدم في ملف الجرد محدودة وفق مبدأ Least Privilege. استخدام حساب root في كل المهام يرفع مخاطر العبث غير المقصود ويصعّب التدقيق الأمني لاحقاً.

أخطاء شائعة يجب تجنبها

• استخدام أسماء غير دلالية مثل server1 وserver2 بدلاً من أسماء تعكس الدور.
• مزج متغيرات خاصة بخادم واحد داخل متغيرات مجموعة كاملة.
• عدم فصل البيئات في ملفات مستقلة.
• تكرار عناوين IP أو الاعتماد على نسخ ولصق عشوائي.
• تخزين أسرار حساسة مباشرة داخل ملفات الجرد بدلاً من أدوات إدارة الأسرار مثل إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة.

خاتمة

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

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