وحدات Terraform القابلة لإعادة الاستخدام، ومتى يجب الامتناع عنها

تُنشأ الوحدة (module) في أغلب الأحيان قبل أوانها. والسيناريو متكرر: تحتاج إلى طابور رسائل ثانٍ، فتلاحظ أن الكتلة تشبه الأولى، فتستخرجها في وحدة «لوقت لاحق». وبعد ستة أشهر يصبح للوحدة أحد عشر متغيرًا منطقيًا وثلاثة تعبيرات count = var.enable_x ? 1 : 0، ولا أحد يجرؤ على لمسها لأنها تُستدعى من أربعة مشاريع، يعتمد اثنان منها على سلوك يعدّه الثالث خطأً برمجيًا. فالتجريد الذي كان يُفترض أن يقلّل التكرار أنتج مكوّنًا أصعب قراءةً من النسخ الأربع التي حلّ محلها.

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

بنية الوحدة

الوحدة ليست سوى مجلد يحتوي على ملفات .tf. لا توجد كلمة مفتاحية لتعريفها؛ فكل مجلد وحدة محتملة.

modules/
  service-web/
    main.tf         # الموارد
    variables.tf    # المدخلات
    outputs.tf      # المخرجات
    versions.tf     # قيود المزوّد
    README.md       # ما تفعله الوحدة، وما لا تفعله