الأسئلة المتعلقة ببنية كود 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 و الموفرين
لا يجب استعمال terraform.tfvars
في أي مكان ما عدا composition.
الرجاء التأكد من فهم المفاهيم الرئيسية 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 أدوات تنسيقات مستقلة التي يمكن للمطور أن يستعملها:
يكفي للمطور أن يستعمل Terraform
استعمال أداة Terragrunt، وهي أداة orchestration تستعمل لتنسيق كل البنية التحتية والاعتماديات، تعمل هذه الأداة مع مختلف الوحدات (modules) والتراكيب (compositions) لذلك تخفف من تكرار الكود (إعادة اختراع العجلة)
استعمال scripts خاصة بالشركة (In-house scripts)، تم استعمالها كبداية لعمليات التنسيق قبل صدور Terragrunt
استعمال أداة Ansible أو أي أداة أتمتة (Autoamtion tools) . يتم استعمالها في حال تم تبني Terraform بعد استعمال Ansible، أو في حال استعمال Ansible UI.
أستعمال أداة Crossplane و الأدوات الملهمة من قبل Kubernetes. من المنطقي أحياناً استعمال Kubernetes لتنسيق Terraform. لمزيد من المعلومات شاهد هذا الفيديو Crossplane vs Terraform
في هذا الكتاب نقوم فقط بعرض الحلين الأولين (Terraform only and Terragrunt.)
شاهد أمثلة عن Terraform أو Terragrunt في الفصل القادم