Terraform المتقدم وأنماط البنية ككود

اختبار Terraform

18 دقيقة الدرس 6 من 28

اختبار Terraform

البنية التحتية كرمز التي لا تُختبر أبداً هي التزام مُقنَّع على هيئة إنتاجية. وحدة Terraform معطوبة تُدمج في الفرع الرئيسي وتُطبَّق على الإنتاج تسبّبت في انقطاعات لا تُحصى — مجموعات أمان خاطئة تفتح منافذ على 0.0.0.0/0، شبكات VPC بلا دقة DNS، وقواعد بيانات RDS بلا احتفاظ بنسخ احتياطية. تمنحك منظومة اختبار Terraform الآن دفاعاً متعدد الطبقات: التحقق الساكن، وتأكيدات مرحلة الخطة، والأمر الأصلي terraform test، وبوابات السياسات في CI — كل منها يكتشف نوعاً مختلفاً من الأخطاء في أبكر وقت ممكن.

الطبقة الأولى — التحقق الساكن

قبل أن تُلمس أي حالة، أمران مدمجان يُزيلان فئات كاملة من الأخطاء في ثوانٍ معدودة:

terraform validate — يتحقق من أنواع HCL، ويحل المراجع، ويُبلّغ عن السمات غير المعروفة أو الوسائط المطلوبة المفقودة. يعمل بلا بيانات اعتماد وبلا وصول شبكي، مما يجعله مثالياً كـ pre-commit hook.
terraform fmt -check — يفرض التنسيق الأصلي. التنسيق غير المتسق في HCL ليس مجرد مسألة جمالية؛ إنه من أبرز أسباب تعارضات الدمج. أفشل الـ pipeline إذا اختلف fmt.

# pre-commit: يعمل في ميلي ثوانٍ، لا يحتاج بيانات اعتماد سحابية
terraform fmt -check -recursive
terraform validate

شغّل validate في دليل الوحدة نفسه وأيضاً في الجذر الذي يستدعيها. الوحدة قد تكون سليمة نحوياً بمعزل عن غيرها لكن تفشل التحقق حين تتركّب مع قيم متغيرات محددة.

الطبقة الثانية — تأكيدات مرحلة الخطة

تحوّل الخطة نواياك إلى فرق ملموس مقابل الحالة الفعلية. قراءة الخطط برمجياً تكشف المفاجآت قبل apply:

أخرج خطة قابلة للقراءة آلياً باستخدام terraform plan -out=tfplan && terraform show -json tfplan > plan.json، ثم أرسلها عبر أدوات مثل conftest أو سكريبت jq بسيط.
أكّد الثوابت: لا يجب لأي مورد من نوع aws_s3_bucket أن يحمل acl = "public-read"؛ لا قاعدة aws_security_group_rule تسمح بـ cidr_blocks = ["0.0.0.0/0"] على المنفذ 22.
في Google وMeta، يعمل تحليل الخطة الآلي على كل طلب سحب (PR)، ويتلقى المراجعون ملخصاً مقروءاً من JSON. لا مراجع يلمس PRs البنية التحتية دون رؤية أثر الخطة.

# تصدير خطة منظمة والتحقق منها بـ jq
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# تأكيد: لا ACL عامة على S3
jq '[.resource_changes[]
      | select(.type == "aws_s3_bucket")
      | select(.change.after.acl == "public-read")]
    | length == 0' tfplan.json

الطبقة الثالثة — terraform test (اختبارات الوحدة والتكامل الأصلية)

أُطلق الأمر terraform test في Terraform 1.6؛ يحمّل ملفات *.tftest.hcl جانب الوحدة، ويُنشئ بنية تحتية حقيقية، ويُشغّل التأكيدات، ثم يُدمّر كل شيء — في أمر واحد خامل. هذا أقرب ما يكون لاختبارات الوحدة للبنية التحتية.

دورة حياة terraform test: التحميل، التطبيق على بنية تحتية حقيقية، التأكيد، ثم التدمير دائماً.

يعيش ملف الاختبار جانب الوحدة ويُعرّف كتل run. كل run يمكنه تطبيق الخطة أو تقييمها فقط، ثم تقييم شروط assert باستخدام تعبيرات Terraform:

# tests/s3_bucket.tftest.hcl
variables {
  bucket_name = "my-test-bucket-tftest-20240101"
  environment = "test"
}

run "bucket_exists_and_is_private" {
  command = apply   # الافتراضي؛ استخدم "plan" لفحوصات أسرع وأرخص

  assert {
    condition     = aws_s3_bucket.this.bucket == var.bucket_name
    error_message = "Bucket name mismatch."
  }

  assert {
    condition     = aws_s3_bucket_public_access_block.this.block_public_acls == true
    error_message = "Public ACLs must be blocked on all buckets."
  }
}

run "versioning_enabled" {
  command = plan

  assert {
    condition     = aws_s3_bucket_versioning.this.versioning_configuration[0].status == "Enabled"
    error_message = "Versioning must be enabled for compliance."
  }
}

شغّل الحزمة بـ terraform test من جذر الوحدة. يكتشف Terraform تلقائياً جميع ملفات *.tftest.hcl. استخدم -filter=tests/s3_bucket.tftest.hcl لاستهداف ملف محدد أثناء التطوير.

استخدم وضع command = plan للتأكيدات التي لا تحتاج موارد حقيقية (التحقق من الأنواع، صيغ الأسماء المحسوبة، قيود المتغيرات). احتفظ بـ command = apply للسلوكيات التي لا يمكن التحقق منها إلا بعد الإنشاء — المخرجات، واستعلامات مصادر البيانات، والمراجع المتقاطعة. هذا يُبقي حزمة الاختبار سريعة: حزمة مؤلفة من 20 اختباراً في وضع plan تعمل في أقل من 30 ثانية، بينما يستغرق وضع apply دقائق ويتكبّد تكاليف سحابية.

الطبقة الرابعة — فحوصات السياسات في CI

أدوات السياسة كرمز تفرض ضوابط المؤسسة التي لا يمكن التعبير عنها داخل وحدة Terraform لأن مؤلف الوحدة ومؤلف السياسة فريقان مختلفان. يستهلك HashiCorp Sentinel (Terraform Cloud/Enterprise) وOpen Policy Agent مفتوح المصدر مع conftest خطة JSON ويُصدران حكماً بالنجاح أو الفشل.

# policy/deny_public_s3.rego  (OPA / conftest)
package main

deny[msg] {
  r := input.resource_changes[_]
  r.type == "aws_s3_bucket"
  r.change.after.acl == "public-read"
  msg := sprintf("DENY: bucket %v has public-read ACL", [r.address])
}

deny[msg] {
  r := input.resource_changes[_]
  r.type == "aws_security_group_rule"
  r.change.after.cidr_blocks[_] == "0.0.0.0/0"
  r.change.after.to_port == 22
  msg := sprintf("DENY: %v opens SSH to the internet", [r.address])
}

# .github/workflows/terraform-ci.yml  (مقتطف)
jobs:
  plan-and-policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Terraform fmt check
        run: terraform fmt -check -recursive

      - name: Terraform validate
        run: |
          terraform init -backend=false
          terraform validate

      - name: Terraform plan
        run: |
          terraform plan -out=tfplan.binary
          terraform show -json tfplan.binary > tfplan.json

      - name: OPA / conftest policy gate
        run: conftest test tfplan.json --policy policy/

      - name: terraform test (unit)
        run: terraform test -filter=tests/fast_plan_tests.tftest.hcl

لا تشغّل terraform test بوضع command = apply على بيئة staging مشتركة. هذه الاختبارات تُنشئ موارد حقيقية وتُدمّرها — بما فيها تلك التي قد تتطابق أسماؤها مع موارد قائمة. عزل تشغيل الاختبارات في حساب AWS مخصص ومؤقت أمر ضروري. على نطاق الشركات الكبرى، تستخدم الفرق لاحقات أسماء عشوائية لكل تشغيل (${random_pet.suffix.id}) لضمان عدم التعارض.

تجميع كل شيء — بوابة CI

خط أنابيب CI الناضج لـ Terraform هو تسلسل صارم من البوابات، كل منها أرخص وأسرع من التي تليها. الكود الذي يجتاز كل البوابات فقط يصل إلى مراجعة بشرية:

fmt + validate — ميلي ثوانٍ، لا بيانات اعتماد مطلوبة.
tflint / checkov / trivy — تحليل ساكن للثغرات الأمنية والواجهات البرمجية المتقادمة (30-60 ثانية).
Plan + policy check — يحتاج بيانات اعتماد قراءة سحابية؛ يُوقف عند أي انتهاك للسياسة.
terraform test (وضع plan) — تأكيدات سريعة على القيم المحسوبة.
terraform test (وضع apply) — اختبارات تكامل كاملة في حسابات معزولة؛ تعمل عند الدمج في main، لا على كل PR.

تُبوّب فرق IaC الداخلية في Google على الطبقات الخمس كلها قبل أن يصل أي تغيير إلى وحدة جذر الإنتاج. الاستثمار يُسدّد خلال أسابيع: انقطاع واحد يُمنع يوفّر عادةً ساعات مهندسين أكثر مما يكلف بناء حزمة الاختبار بأكملها.