تخطيط المجلدات الموصى به

مع نمو المشاريع، تتحول الملفات المتناثرة إلى فوضى. ويحدد هيكل الأدلة القياسي لفريقكم المكان الدقيق لكل شيء. 📁

وفقًا لل convention، يُعدّ site.yml playbook الأعلى مستوى الذي يربط بنيتكم التحتية بأكملها ويضم بقية الملفات.

يوجد ملف inventory لديكم (أو دليله) بالقرب من المستوى الأعلى، ولذلك تعرف playbooks الموجودة بجانبه دائمًا المضيفات التي تديرها.

قسّموا العمليات الكبيرة إلى ملفات مركّزة مثل webservers.yml وdbservers.yml، ثم اجمعوها من site.yml.

يحتوي دليل group_vars على متغيرات تنطبق على مجموعات مضيفين كاملة، ويُحمّل تلقائيًا بحسب اسم المجموعة.

يؤدي دليل host_vars الوظيفة نفسها للأجهزة الفردية، مع ملف يحمل اسم كل مضيف على حدة.

توجد الأتمتة القابلة لإعادة الاستخدام ضمن دليل roles. ويبحث Ansible هنا أولًا عندما يشير play إلى role بالاسم.

يحتوي مجلد library على modules مخصّصة، بينما يحتوي module_utils أو filter_plugins على شيفرة مساعدة مشتركة يكتشفها Ansible تلقائيًا.

ضعوا ansible.cfg في جذر المشروع. يلتقط Ansible الإعدادات من دليلكم الحالي، وبذلك تبقى إعدادات المشروع محلية.

باستخدام هذا التنظيم، يمنح git clone واحد زميلكم playbooks وinventory والمتغيرات وroles كلها ضمن بنية متسقة واحدة. 🎯

إليكم الهيكل الموصى به الذي تقترحه الوثائق الرسمية. احفظوا البنية، لا كل ملف.

ما الملف الذي يُعدّ نقطة الدخول التقليدية الأعلى مستوى لمشروع كامل؟

تعلّمتم التنظيم القياسي: site.yml مع inventory وgroup_vars وhost_vars وroles في مستودع واحد. وتكبر البنية المتوقعة مع فريقكم. ✅