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

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

• حسابين AWS

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

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

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

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

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

المورد (Resource)

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

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

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

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

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

كمثال فإن وحدة البنية التحتية terraform-aws-atlantis تستعمل وحدات الموارد مثل terraform-aws-vpc و terraform-aws-security-group لإدارة البنية التحتية اللازمة لتشغيل Atlantis on AWS Fargate.

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

التركيب (Composition)

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

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

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

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

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

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

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

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

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

الموفر (Provider, provisioner)

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

أين الصعوبة؟

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

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

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

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

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }

}

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

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

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

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

الرعاة

الترجمات

اتصل بي إذا كنت تود المساعدة بالترجمة إلى لغات أخرى

المساهمات

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

المؤلفون

الترخيص

هذا العمل مرخص بموجب ترخيص Apache 2. انظر LICENSE للحصول على التفاصيل الكاملة.

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

حقوق النشر © 2018-2023 Anton Babenko.

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

• حسابين AWS

• منطقتين

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

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

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

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

الأسئلة المتعلقة ببنية كود 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، الذي يعرف خرج الموارد المولدة من قبلmain.tf

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

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

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

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

  • إن كل من تعليمتي 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.

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

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

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