بنية الكود
الأسئلة المتعلقة ببنية كود Terraform هي الأكثر شيوعًا في المجتمع. في الكثير من الأحيان فكر الجميع في أفضل بنية كود ممكن الحصول عليها للمشروع.
هذا نوع من الأسئلة التي يمكن الإجابة عليها بالعديد من الطرق ومن الصعب جداً تقديم نصيحة تنفع لجميع الحالات، لذلك لنبدأ بفهم ما نتعامل معه.
- ما هو مدى تعقيد مشروعك؟
- عدد الموارد المرتبطة ببعضها
- عدد الموفرين (انظر الملاحظة أدناه عن "logical providers")
- كم مرة تحتاج إلى تغيير في البنية التحتية؟
- من مرة في الشهر/الأسبوع/اليوم؟
- إلى تغيير مستمر (عند كل commit جديدة)
- مصادر تغيير الكود، هل تسمح لمخدم CI بتعديل repository عند بناء artifact جديدة؟
- يسمح فقط للمطورين بإضافة تغييرات إلى repository الخاصة بالبنية التحتية
- يسمح لأي أحد باقتراح تغيير من خلال فتح PR (متضمناً المهام الأتوماتيكية التي يقوم بها مخدم CI)
- ما هي المنصة أو الخدمة التي تستعملها لعملية deployment؟
- AWS CodeDeploy, Kubernetes, OpenShift (يحتاج كل حل إلى معاملة مختلفة)
- كيف يتم فرز البيئات المختلفة؟
- من خلال بيئة العمل(environment)، المنطقة (region)، المشروع (project)
عند بداية التعامل مع Terraform أو عندما تريد أن تكتب مثالاً فإن وضع كل الكود في ملف
main.tf تعتبر فكرة جيدة، ولكن في كل الحالات الأخرى يجب تقسيم الكود منطقياً إلى ملفات مختلفة كالتالي:- ملف
main.tf, والذي يستدعي الوحدات المختلفة (modules), والوسطاء المحلية (locals)، ومصادر البيانات (data) لتوليد كافة الموارد (resources) - ملف
variables.tf، الذي يحتوي على تعريف للوسطاء (variables) المراد استعمالها فيmain.tf - ملف
outputs.tf، الذي يعرف خرج الموارد المولدة من قبلmain.tf - ملف
versions.tf، الذي يحتوي متطلبات الإصدار الخاصة بـ Terraform و الموفرين
الرجاء التأكد من فهم ال مفاهيم الرئيسية resource module, infrastructure module, composition لأهميتها لفهم الأمثلة التالية
- إنه من الأسهل والأسرع التعامل مع عدد قليل من الموارد
- إن كل من تعليمتي
terraform planوterraform applyتقوم باستدعاء cloud API للتحقق من حالة الموارد - إذا كانت كل بنيتك التحتية في تركيب واحد ستأخذ هذه التعليمات وقتاً طويلاً للتنفيذ
- مدى الضرر يكون أصغر في حال تعريف موارد قليلة
- عزل الموارد غير المرتبطة ببعضها في تراكيب مختلفة يقلل الخطر في حال حدوث مشكلة ما
- استعمل ملف الحالة المخرن عن بعد
- حاسبك الشخصي لا يمثل عكس لحقيقة البنية التحتية
- إدارة tfstate في git أمر كارثي
- لاحقاً عند توسع البنية في اتجاهات عدة (عدد الموارد وعدد dependencies)، سيكون استعمال هذا الملف أسهل للتحكم بهذه البنية
- تمرن على بنية وطرق تسمية متسقة
- مثل الكود العادي، فإن كود Terraform يجب أن يكون مقروءاً، الاتساق سيساعد عندما تريد التحقق من تعديلات تمت إضافتها من 6 أشهر ماضية
- من الممكن أن تنقل موارد لم يتم تعريفها سابقاً إلى ملف Terraform State، لكن وجود كود غير متسق سيصعب الأمر
- قم ببناء وحدة (modules) بسيطة قدر الإمكان
- لا تقم باستعمال قيم ثابتة (hardcoded) إذا كنت تستطيع تمريرها كمتحول أو الحصول عليها من مصدر بيانات
- استعمل مصادر البيانات و
terraform_remote_stateكغراء بين وحدات البنية التحتية في التركيب
في هذا المشروع قمنا بفرز المشروعات بحسب تعقيدها من البنى الصغيرة إلى الكبيرة جداً، لا يعتبر هذا التجميع ملزماً، لذا ابحث عن طرق أخرى أيضاً.
وجود بنية تحتية صغيرة يعني وجود عدد صغير من الاعتماديات (dependencies) والموارد، كلما كبر المشروع فإن أهمية ربط البنى المختلفة وتمرير المتحولات في التركيب تصبح واضحة اكثر.
يوجد على الأقل 5 أدوات تنسيقات مستقلة التي يمكن للمطور أن يستعملها:
- 1.يكفي للمطور أن يستعمل Terraform
- 2.استعمال أداة Terragrunt، وهي أداة orchestration تستعمل لتنسيق كل البنية التحتية والاعتماديات، تعمل هذه الأداة مع مختلف الوحدات (modules) والتراكيب (compositions) لذلك تخفف من تكرار الكود (إعادة اختراع العجلة)
- 3.استعمال scripts خاصة بالشركة (In-house scripts)، تم استعمالها كبداية لعمليات التنسيق قبل صدور Terragrunt
- 4.استعمال أداة Ansible أو أي أداة أتمتة (Autoamtion tools) . يتم استعمالها في حال تم تبني Terraform بعد استعمال Ansible، أو في حال استعمال Ansible UI.
- 5.أستعمال أداة Crossplane و الأدوات الملهمة من قبل Kubernetes. من المنطقي أحياناً استعمال Kubernetes لتنسيق Terraform. لمزيد من المعلومات شاهد هذا الفيديو Crossplane vs Terraform
في هذا الكتاب نقوم فقط بعرض الحلين الأولين (Terraform only and Terragrunt.)
Last modified 1mo ago