بنية الكود

الأسئلة المتعلقة ببنية كود Terraform هي الأكثر شيوعًا في المجتمع. في الكثير من الأحيان فكر الجميع في أفضل بنية كود ممكن الحصول عليها للمشروع.

كيف يجب هيكلة مشروع Terraform؟

هذا نوع من الأسئلة التي يمكن الإجابة عليها بالعديد من الطرق ومن الصعب جداً تقديم نصيحة تنفع لجميع الحالات، لذلك لنبدأ بفهم ما نتعامل معه.

• ما هو مدى تعقيد مشروعك؟

  • عدد الموارد المرتبطة ببعضها

  • عدد الموفرين (انظر الملاحظة أدناه عن "logical providers")

• كم مرة تحتاج إلى تغيير في البنية التحتية؟

  • من مرة في الشهر/الأسبوع/اليوم؟

  • إلى تغيير مستمر (عند كل commit جديدة)

• مصادر تغيير الكود، هل تسمح لمخدم CI بتعديل repository عند بناء artifact جديدة؟

  • يسمح فقط للمطورين بإضافة تغييرات إلى repository الخاصة بالبنية التحتية

  • يسمح لأي أحد باقتراح تغيير من خلال فتح PR (متضمناً المهام الأتوماتيكية التي يقوم بها مخدم CI)

• ما هي المنصة أو الخدمة التي تستعملها لعملية deployment؟

  • AWS CodeDeploy, Kubernetes, OpenShift (يحتاج كل حل إلى معاملة مختلفة)

• كيف يتم فرز البيئات المختلفة؟

  • من خلال بيئة العمل(environment)، المنطقة (region)، المشروع (project)

Logical providers

هي الموفرات التي تعمل كلياً ضمن Terraform ولا تتعامل غالباً مع أي خدمة خارجية، لذا يمكن أن نعتبرها أدوات بتعقيد O(1). أكثر هذه الموفرات شهرة هي random, local, terraform, null, time.

مقدمة إلى هيكلة مشروع Terraform

عند بداية التعامل مع Terraform أو عندما تريد أن تكتب مثالاً فإن وضع كل الكود في ملف main.tf تعتبر فكرة جيدة، ولكن في كل الحالات الأخرى يجب تقسيم الكود منطقياً إلى ملفات مختلفة كالتالي:

• ملف main.tf, والذي يستدعي الوحدات المختلفة (modules), والوسطاء المحلية (locals)، ومصادر البيانات (data) لتوليد كافة الموارد (resources)

• ملف variables.tf، الذي يحتوي على تعريف للوسطاء (variables) المراد استعمالها فيmain.tf

• ملفoutputs.tf، الذي يعرف خرج الموارد المولدة من قبلmain.tf

• ملفversions.tf ، الذي يحتوي متطلبات الإصدار الخاصة بـ Terraform و الموفرين

لا يجب استعمال terraform.tfvarsفي أي مكان ما عدا composition.

كيف يجب أن نفكر عند هيكلة مشروع 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.)

شاهد أمثلة عن Terraform أو Terragrunt في الفصل القادم