تصف وثائق Terraform الرسمية جميع مصطلحات تعريف البنى التحتية بالتفصيل. اقرأها بعناية لفهم بقية هذا القسم.

يشرح هذا القسم المفاهيم الأساسية المستخدمة في الكتاب

المورد (Resource)

المورد هو aws_vpc، aws_db_instance الخ...، ينتمي المورد إلى موفر معين (provider) ويقبل الوسيطات (arguments) ويولد المخرجات (outputs) وله دورات حياة (lifecycles). يمكن إنشاء مورد واسترجاع معلوماته وتحديثه وحذفه.

وحدة الموارد (Resource module)

وحدة الموارد هي مجموعة من الموارد المرتبطة ببعضها والتي تقوم مع بعضها بتنفيذ وظيفة معينة (لنأخذ كمثال، تقوم هذه الوحدة ببناء VPC، subnets, NAT gateway والعديد من الموارد التي نستعملها للتشبيك)، تعتمد وحدة الموارد على الموفر، ويتم تعريفها أما في الموفر أو في الهياكل عالية المستوى (على سبيل المثال ، في وحدة البنية التحتية).

وحدة البنية التحتية (Infrastructure module)

وحدة البنية التحتية هي مجموعة وحدات موارد والتي قد لا تتربط منطقياً ولكنها توجد في مشروع أو نظام يخدم نفس الهدف. تعرف هذه الوحدة الـتهيئة (configuration) للموفرين (providers)، والتي تقوم بتمريرها إلى وحدات الموارد والموارد المؤلفة لهذه الوحدة. عادةً ما يقتصر العمل في وحدة بنية تحتية واحدة لكل كيان منفصل (على سبيل المثال ، AWS Region ، Google Project).

كمثال فإن وحدة البنية التحتية تستعمل وحدات الموارد مثل و لإدارة البنية التحتية اللازمة لتشغيل on .

كمثال أخر فإن وحدة البنية التحتية يتم استعمالها لإدارة البنية التحتية كما تقوم باستعمال أداة Docker لإدارة Docker images في وحدة واحدة.

التركيب (Composition)

التركيب هو مجموعة من وحدات البنية التحتية والتي يمكن أن تمدد على العديد من المناطق المنفصلة (AWS Regions, AWS Accounts) . يتم استعمال التركيب لوصف كامل البنية التحتية لمؤسسة أو مشروع.

كما يبين الشكل يتألف تركيب البنية التحتية (infrastructure composition) من مجموعة وحدات بنية تحتية (infrastructure module) والتي تتكون من وحدات موارد (resources module) والتي تنجز عدة موارد محددة

مصدر البيانات (Data source)

يوفر مصدر البيانات مورداً قابلاً للقراءة فقط (read-only) ويعتمد على نمط الموفر (provider) الذي نتعامل معه، يتم استعماله من قبل كل من وحدة البنية التحتية ووحدة الموارد.

يعتبر مصدر البيانات terraform_remote_stateأداة لربط الوحدات عالية المستوى والتراكيب المختلفة مع بعضها

يسمح مصدر البيانات بالبرامج الخارجية بالعمل كمصدر للبيانات ليتم التعامل معها في مكان أخر من ملفات التهئية الخاصة بأداة Terraform، يمكن أن نجد مثالاً في حيث يتم الحصول على اسم الملف من خلال استدعاء كود Python خارجي

يحصل مصدر البيانات على معلوماته من خلال إرسال طلب HTTP GET لرابط معين ويصدر الجواب الذي حصلنا عليه ويعتبر هذه المصدر مفيداً في حال عدم وجود موفر Terraform.

ملف الحالة المخرن عن بعد (Remote state)

يجب تخزين لكل من وحدات البنية التحتية والتراكيب عن بعد حيث يمكن استرجاعه من قبل كل الأشخاص العاملين عليه ويجب أن تتم إدارته بشكل يضمن السرية والتنظيم (e.g. specify ACL, versioning, logging).

الموفر (Provider, provisioner)

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

أين الصعوبة؟

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

حتى نتمكن من الوصول إلى بيانات فإننا نستعمل مخرجات الوحدات (outputs) بالإضافة إلى مصادر البيانات (data sources)

حتى نتمكن من تبادل البيانات من تركيب إلى تركيب أخر يجب علينا استعمال مصدر البيانات terraform_remote_state،()

وأخيراً يمكننا تمثيل المفاهيم المشروحة سابقاً بهذا الشكل

بنى الكود في Terraform

بنى الكود في Terragrunt

يعد الـ مشروع جديد نسبياً (مثل معظم أدوات الـ DevOps )، صدر في عام 2014.

تعد أداة Terraform قوية (إن لم تكن الأقوى الآن) وواحدة من أكثر الأدوات استعمالاً لتوصيف البنى التحتية المعلوماتية باستعمال الكود (Infrastructure as code). تسمح هذه الأداة للمطورين بالقيام بالكثير من الوظائف ولا تمنعهم من فعل الأشياء بطرق يصعب دعمها أو التواصل معها.

بعض المعلومات في هذا الكتاب قد تبدو وكأنها لا تصنف كأفضل الممارسات. أعلم هذا. ولمساعدة القراء على التفريق بين ما يعد أفضل ممارسة أو ما هو مجرد طريقة أخرى لفعل الأشياء، فإني سأقوم باستعمال التلميحات (hints) في بعض الأحيان وتوفير الأيقونات لتحديد مستوى النضج في كل قسم فرعي يتعلق بأفضل الممارسات.

تم البدء بكتابة هذا الكتاب في مدريد في سنة 2018 وهو متوفر مجاناً على الرابط -

تم التعديل على هذا الكتاب بعد عدة سنين لإضافة أفضل الممارسات المتوفرة لإصدار Terraform 1.0 ، هذا الكتاب يجب أن يحتوي أفضل الممارسات والتوصيات الغير القابلة للجدل ليتم استعمالها من قبل مستخدمي الـ Terraform

المصدر:

يحتوي هذا المثال على كود لهيكلة كود Terraform لبنية تحتية صغيرة، حيث لا وجود لاعتمادات خارجية

يوجد أيضاً ورشة عمل للناس التي تريد أن تتمرن على الأشياء التي تعلمناها في هذا المرجع

هنا يوجد المحتوى - https://github.com/antonbabenko/terraform-best-practices-workshop

المصدر:

يحتوي هذا المثال على كود لهيكلة كود Terraform لبنية تحتية متوسطة والتي تستعمل:

• حسابين AWS

• بيئتين مختلفتين (prod and stage لا وجود لشيء مشترك بينهما). كل بيئة موجودة في حساب AWS مختلف

التوثيق

التوثيق مولداً تلقائياً

إن هو إطار عمل لإدارة وصيانة pre-commit hooks متعددة اللغات، مكتوبة بلغة بايثون وهي أداة قوية للقيام ببعض المهام بشكل أتوماتيكي على جهاز المطور قبل الدفع بالكود إلى git repository. تستعمل عادةً لتشغيل linters ولتنسيق الكود ( انظر إلى )

مع ملفات Terraform يمكننا استعمال pre-commitلتنسيق الكود والتحقق منه بالإضافة إلى تعديل التوثيق

تحقق من ومن الذي يقوم باستعماله

أداة terraform-docs

إن هي أداة تقوم بتوليد التوثيق من وحدات Terraform وتولد أشكال مختلفة، يمكنك أن تشغلها يدوياً (بدون pre-commit hooks) أو تستعمل إطار عمل لجعل التوثيق يتكون أتوماتيكياً.

@todo: Document module versions, release, GH actions

الموراد

3. Blog post by :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ملفoutputs.tf

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

كيف يجب أن نفكر عند هيكلة مشروع Terraform

التوصيات العامة لهيكلة الكود

• إنه من الأسهل والأسرع التعامل مع عدد قليل من الموارد

  • إن كل من تعليمتي terraform planوterraform apply تقوم باستدعاء cloud API للتحقق من حالة الموارد

  • إذا كانت كل بنيتك التحتية في تركيب واحد ستأخذ هذه التعليمات وقتاً طويلاً للتنفيذ

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

تنسيق وحدات وتركيبات البنى التحتية

وجود بنية تحتية صغيرة يعني وجود عدد صغير من الاعتماديات (dependencies) والموارد، كلما كبر المشروع فإن أهمية ربط البنى المختلفة وتمرير المتحولات في التركيب تصبح واضحة اكثر.

يوجد على الأقل 5 أدوات تنسيقات مستقلة التي يمكن للمطور أن يستعملها:

1. يكفي للمطور أن يستعمل Terraform

2. استعمال أداة Terragrunt، وهي أداة orchestration تستعمل لتنسيق كل البنية التحتية والاعتماديات، تعمل هذه الأداة مع مختلف الوحدات (modules) والتراكيب (compositions) لذلك تخفف من تكرار الكود (إعادة اختراع العجلة)

3. استعمال scripts خاصة بالشركة (In-house scripts)، تم استعمالها كبداية لعمليات التنسيق قبل صدور Terragrunt

4. استعمال أداة Ansible أو أي أداة أتمتة (Autoamtion tools) . يتم استعمالها في حال تم تبني Terraform بعد استعمال Ansible، أو في حال استعمال Ansible UI.

في هذا الكتاب نقوم فقط بعرض الحلين الأولين (Terraform only and Terragrunt.)

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

https://twitter.com/antonbabenko/lists/terraform-experts - قائمة بالناس الذين عملوا مع الأداة بشكل كبير ومن الممكن أن تتعلم الكثير منهم (إذا سألت)

https://github.com/shuaibiyy/awesome-terraform - قائمة مختارة من مصارد تعلم الأداة

http://bit.ly/terraform-youtube - "جرعتك الأسبوعية من الأداة"

بث مباشر من قبل مؤلف هذه الكتاب. مراجعات، مقابلات، Q&A، جلسات تكويد وكل شيء عن الأداة

- "الرسائل الأسبوعية عن الأداة"

أخبار مختلفة عن عالم الأداة (مشاريع جديدة، إعلانات، نقاشات) ترسل إليك من قبل مؤلف الكتاب.

المصدر: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

يحتوي هذا المثال على كود لهيكلة كود Terraform لبنية تحتية كبيرة والتي تستعمل:

• حسابين AWS

• منطقتين

• بيئتين مختلفتين (prod and stage لا وجود لشيء مشترك بينهما). كل بيئة موجودة في حساب AWS مختلف وتوزع الموارد على المنطقتين

• كل بيئة تستعمل إصدارات مختلفة للوحدات الجاهزة (alb) مصدرها

• كل بيئة تستعمل الإصدار نفسه للوحدات الداخلية modules/network مصدره المجلد المحلي

استعمل locals لتحديد الاعتماديات الصريحة بين الموارد

من الطرق المساعدة لإخبار Terraform أنه يجب حذف بعض الموارد حتى عندما لا يوجد اعتمادية مباشرة عليها

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

إصدار Terraform 0.12 - الوسيطات الإجبارية والاختيارية

1. الوسيط index_documentهو وسيط إجباري يجب تحديده، إذا كانتvar.websiteليستmapفارغة

2. الوسيط error_documentهو وسيط اختياري من الممكن عدم ذكره

القواعد العامة

1. استعمل _ (underscore) بدلاً من - (dash) في كل مكان (أسماء الموراد، أسماء مصادر البيانات، أسماء المتحولات، أسماء المخرجات الخ..)

2. فضل استعمال الأحرف الصغيرة (lowercase) والأرقام فقط (حتى لو كان نظام UTF-8 مدعوماً)

أسماء الموراد ومصادر البيانات

1. لا تكرر نوع المورد في اسم المورد (ليس جزئيًا أو كليًا):

   resource "aws_route_table" "public" {}

أمثلة كود لأسماء المصادر

استعمال count / for_eachفي الكود

وضعية tagsفي الكود

استعمال الشروط في countفي الكود

أسماء المتحولات

1. لا تعيد اختراع العجلة في وحدات الموارد: استخدم الاسمnameوالوصفdescriptionوالقيمة الافتراضية defaultللمتحولات كما هو محدد في قسم "Argument Reference" للمورد الذي تعمل معه.

2. عملية التحقق (Validation) من المتحولات محدود نوعًا ما (على سبيل المثال ، لا يمكن الوصول إلى متحولات أخرى أو إجراء عمليات بحث). خطط وفقًا لذلك لأنه في كثير من الحالات تكون هذه الميزة غير مجدية.

3. استخدم صيغة الجمع في اسم متحول عند يكون نمطه

أسماء المخرجات

اجعل المخرجات متسقة ومفهومة خارج سياقها ( عندما يتم استعمال وحدة من قبل مستخدم يجب على المخرجات أن تكون واضح ما هو نمط وما صفات القيمة التي ترجعها)

1. يجب على اسم الخرج أن يصف القيمة التي يرجعها وأن تكون أقل حرية مما تريد عادة.

2. الشكل الجيد لاسم الخرج يكون كالتالي {attribute}_{type}_{name} حيث:

   1. إن {name} هو اسم المورد أو اسم مصدر البيانات بدون اسم الموفر. كمثال للمورد aws_subnet يكون الاسم هو

أمثلة كود لأسماء المخرجات

تعيد على الأكثر Security group ID وحيد

عند وجود عدة مصادر من نفس النمط، يجب حذفthisمن الخرج:

إذا كانت قيمة الخرج عبارة عن list فإنه يجب أن نستعمل اسم جمع :

ما هي الأدوات التي يجب معرفتها واستخدامها؟

• أداة Terragrunt -أداة تنسيق

• أداة

• أداة - إدارة الإصدارات

• أداة أتمتة العمل مع PR

• أداة مجموعة من git-hooks خاصة بأداة Terraform التي يتم استعمالها مع إطار العمل

ما هي الحلول لمشكلة مع الوحدات؟

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

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