أساسيات Terraform

المزودون والإصدارات

18 دقيقة الدرس 3 من 30

المزودون والإصدارات

المزوّد في Terraform هو مكوّن إضافي يُترجم تعريفات الموارد المكتوبة بـ HCL إلى استدعاءات API حقيقية على منصة سحابية أو خدمة SaaS أو نظام داخلي. كل كتلة resource وdata تكتبها تنتمي إلى مزوّد واحد بالضبط. فهم كيفية اكتشاف المزوّدين وتنزيلهم وتثبيت إصداراتهم وقفلها ليس معرفة اختيارية — بل هو المصدر الأكثر شيوعاً لأعطال "يعمل على جهازي ويفشل في CI" في مشاريع Terraform الإنتاجية.

كيف تعمل المزوّدون

لا يمتلك Terraform بحد ذاته أي معرفة مدمجة بـ AWS أو GCP أو Azure أو Kubernetes. فهو محرّك عام يفهم HCL وملف الحالة. المزوّدون هم ثنائيات Go مُصدَرة بشكل مستقل عبر Terraform Registry على registry.terraform.io. عند تشغيل terraform init، يقرأ Terraform كتلة required_providers، يحلّ قيود الإصدار، يُنزّل الثنائيات المطابقة إلى مجلد .terraform/providers/، ثم يكتب ملف القفل.

للمزوّدين عنوان ثلاثي الأجزاء: <hostname>/<namespace>/<type>. المضيف الافتراضي هو registry.terraform.io، لذا hashicorp/aws هو اختصار لـ registry.terraform.io/hashicorp/aws. المزوّدون الخارجيون (مثل grafana/grafana وcloudflare/cloudflare) يتبعون نفس النمط مع مساحة أسماء خاصة بهم.

كتلة required_providers

متطلبات المزوّدين تعيش داخل كتلة terraform في أي ملف .tf — بالاتفاق في versions.tf. تصريح المزوّدين صراحةً هنا (بدلاً من الاعتماد على الاكتشاف الضمني) إلزامي للبنى القابلة للاستنساخ:

# versions.tf — متطلبات المزوّدين الصريحة

terraform {
  required_version = ">= 1.9, < 2.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }

    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.30, < 3.0"
    }

    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.39"
    }
  }
}

الفكرة الأساسية: كتلة required_providers هي العقد بين تهيئتك والعالم الخارجي. تُخبر Terraform أين يجد كل ثنائي للمزوّد وأي الإصدارات مقبولة. حذفها يعني أن Terraform يخمّن — وعلى جهاز مختلف مع ذاكرة تخزين Terraform مختلفة قد يحلّ إصداراً مختلفاً، مُنتجاً بنية تحتية مختلفة في صمت.

صيغة قيود الإصدار

يستخدم Terraform صيغة قيود مستعارة من Semantic Versioning. اختيار العامل الصحيح أمر بالغ الأهمية عملياً:

= 5.50.0 — تثبيت دقيق. أقصى استنساخية، صفر مرونة. نادراً ما يُستخدم؛ يجعل الترقيات الروتينية مؤلمة.
!= 5.48.0 — استثناء إصدار بعينه. يُستخدم لحظر إصدار معطوب معروف مع قبول التصحيحات المستقبلية.
>= 5.0, < 6.0 — نطاق. يقبل أي إصدار 5.x. مفيد عندما تعلم أن حدود الإصدار الرئيسي تُدخل تغييرات كسر التوافق.
~> 5.50 — عامل القيد التشاؤمي (tilde-arrow). يسمح للمكوّن الأيمن من الإصدار بالتزايد بحرية. ~> 5.50 تعني >= 5.50, < 6.0. ~> 5.50.0 تعني >= 5.50.0, < 5.51.0. هذا العامل الذي تستخدمه شركات التقنية الكبرى لمعظم المزوّدين.

ممارسة احترافية — التثبيت على مستويين: لثنائي Terraform نفسه استخدم نطاقاً مثل >= 1.9, < 2.0 للسماح بترقيات التصحيح دون عبور حدود الإصدار الرئيسي بطريق الخطأ. للمزوّدين، استخدم tilde-arrow على مستوى Minor (~> 5.50) لقبول إصلاحات التصحيح تلقائياً مع البقاء على خط minor مُختبَر. ضمّ ملف القفل في git حتى تُشغّل CI دائماً نفس الثنائي بالضبط بصرف النظر عما يُعيده Registry.

تهيئة المزوّد

تصريح المزوّد في required_providers يُخبر Terraform أي ثنائي يُنزّل. تهيئته تُخبر المزوّد كيف يُوثَّق وما هي الإعدادات الافتراضية التي تُطبَّق. تهيئة المزوّد تعيش في كتلة provider:

# main.tf — تهيئة المزوّد

provider "aws" {
  region = var.aws_region

  # بيانات الاعتماد لا تُكتب هنا مطلقاً.
  # في CI، اضبط متغيرات البيئة AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY.
  # على محطة عمل محلية مع aws-vault أو aws sso login، تلتقط SDK
  # سلسلة الاعتمادات القياسية تلقائياً.

  default_tags {
    tags = {
      ManagedBy   = "terraform"
      Environment = var.environment
      Team        = "platform"
      CostCenter  = var.cost_center
    }
  }
}

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", module.eks.cluster_name]
  }
}

مصيدة إنتاجية — لا تضع بيانات الاعتماد أبداً في كتل المزوّدين. ترميز access_key وsecret_key مباشرة في HCL يعني أن تلك الأسرار تنتهي في تاريخ git وفي ملف الحالة وفي أي مخرجات للخطة تُرفَع إلى سجلات CI. استخدم دائماً متغيرات البيئة (AWS_ACCESS_KEY_ID) أو instance profiles (على EC2/ECS) أو IRSA (على EKS) أو تكامل مدير الأسرار. تعامل مع كتلة المزوّد باعتبارها تهيئة فقط، ليست مستودع اعتمادات.

أسماء المزوّدين المستعارة — تهيئات متعددة لنفس المزوّد

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

# مثال متعدد المناطق: us-east-1 الأساسية + منطقة DR: eu-west-1

provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  alias  = "eu"
  region = "eu-west-1"
}

# هذا الـ bucket ينتهي في eu-west-1:
resource "aws_s3_bucket" "dr_bucket" {
  provider = aws.eu
  bucket   = "acme-dr-bucket-eu-west-1"
}

# هذا الـ bucket ينتهي في us-east-1 (المزوّد الافتراضي):
resource "aws_s3_bucket" "primary_bucket" {
  bucket = "acme-primary-bucket-us-east-1"
}

ملف قفل التبعيات

عندما يحلّ terraform init المزوّدين لأول مرة ينشئ (أو يُحدّث) .terraform.lock.hcl. يُسجّل هذا الملف الإصدار الدقيق للمزوّد المُختار وتجزئاته التشفيرية لكل منصة مدعومة. وهو مكافئ Terraform لـ package-lock.json أو Pipfile.lock.

تدفق حلّ المزوّدين: يقرأ terraform init قيود الإصدار، يستعلم Registry، يُنزّل الثنائي، ويكتب التجزئات في ملف القفل — الذي تستخدمه CI لضمان تشغيل نفس المزوّد تماماً في كل بيئة.

إدخال ملف القفل يبدو هكذا:

# .terraform.lock.hcl — ضمّ هذا الملف في git

provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.54.1"
  constraints = "~> 5.50"

  hashes = [
    "h1:AbCdEf1234...==",  # zh: تجزئة للمنصة الحالية (darwin_arm64, linux_amd64, إلخ.)
    "zh:1234abcd...",      # تجزئات منصات إضافية مُدرجة مسبقاً بأعلام -platform
    "zh:5678efgh...",
  ]
}

البادئة h1: هي تجزئة أرشيف zip الذي يعيش فيه الثنائي؛ تجزئات zh: تغطي الثنائيات الفردية بداخله. عند تنزيل Terraform لمزوّد يُعيد حساب هذه التجزئات ويرفض المتابعة إن لم تتطابق — مما يحميك من التلاعب بسلسلة التوريد.

ممارسة احترافية — ملء تجزئات المنصات مسبقاً لـ CI: افتراضياً يحتوي ملف القفل على تجزئات للمنصة التي شُغّلت عليها terraform init فقط (مثل darwin_arm64 على Apple Silicon). تعمل CI عادةً على linux_amd64. شغّل terraform providers lock -platform=linux_amd64 -platform=darwin_arm64 مرة واحدة واضمم النتيجة حتى لا تحتاج CI للوصول إلى الشبكة للـ Registry فقط للتحقق من التجزئات.

ترقية المزوّدين بأمان

ترقيات المزوّدين الروتينية هي انضباط تشغيلي غير قابل للتفاوض. AWS وحدها تُصدر إصدارات مزوّد كل أسبوع؛ إصدارات التصحيح تُصلح أخطاء وتُضيف أنواع موارد تعكس ميزات خدمات AWS الجديدة. سير عمل الترقية الآمنة هو:

شغّل terraform init -upgrade لحلّ أحدث إصدار مسموح به بقيودك وإعادة كتابة ملف القفل.
شغّل terraform plan وراجع الفرق بعناية — ترقيات المزوّدين تُغيّر أحياناً الإعدادات الافتراضية أو تُهمل معاملات، مُنتجةً تغييرات موارد غير متوقعة.
طبّق في بيئة غير إنتاجية أولاً، ثم رقّ عبر خط أنابيب البيئات.
ضمّ ملف القفل المحدَّث كـ commit مخصص حتى يتمكن المراجعون من رؤية أي مزوّد تغيّر بالضبط.

مصيدة إنتاجية — terraform init -upgrade بدون ملف القفل في git. إن لم يضمّ مستودعك .terraform.lock.hcl، كل مهندس وكل تشغيل لـ CI يحلّ المزوّدين بشكل مستقل. في أي يوم قد يُعيد Registry إصدار تصحيح جديداً. قد يعمل مهندسان على نفس طلب السحب بإصدارات مزوّد مختلفة. فرق سلوك API صامت بين 5.50.0 و5.54.1 سيُنتج فرق خطة لا علاقة له بتغيير الكود — وقد يُعيد إنشاء موارد في صمت. ضمّ ملف القفل دائماً.

السجلات الخاصة وسجلات المرايا

كثيراً ما لا تستطيع الشركات الكبيرة السماح لمشغّلات Terraform بالوصول إلى السجل العام. الحلول هي:

Terraform Cloud / HCP Terraform: يمتلك سجلاً خاصاً مدمجاً للوحدات الداخلية وإمكانية مرايا المزوّدين.
مرايا Artifactory / Nexus: هيّئ ~/.terraformrc (أو TF_CLI_CONFIG_FILE) بكتلة provider_installation لإعادة توجيه الحلّ إلى مرآتك الداخلية قبل الرجوع إلى السجل العام.
filesystem_mirror: للبيئات المعزولة، نزّل مسبقاً ملفات zip للمزوّدين في بنية مجلد يفهمها Terraform وأشر إليها بكتلة filesystem_mirror.

يُركّز هذا الدرس على سير عمل السجل العام — تفاصيل تهيئة مرايا المؤسسات مُغطّاة في درس Terraform المتقدم.

تشريح versions.tf حقيقي

في شركة تُشغّل إعداد AWS متعدد الحسابات مع Kubernetes وDatadog وVault، يكون versions.tf الإنتاجي أداراً مُدارة بعناية وليس فكرة لاحقة:

# versions.tf — تهيئة إنتاجية عالية الجودة، متعددة المزوّدين

terraform {
  required_version = ">= 1.9.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.30, < 3.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.13"
    }
    vault = {
      source  = "hashicorp/vault"
      version = "~> 4.3"
    }
    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.39"
    }
  }
}

# بعد تعديل هذا الملف، شغّل:
#   terraform init -upgrade
#   terraform providers lock -platform=linux_amd64 -platform=darwin_arm64
# ثم ضمّ كلاً من versions.tf و.terraform.lock.hcl في git.

الاحتفاظ بـ versions.tf كملف مستقل (بدلاً من دفن required_providers داخل main.tf) يجعل مراجعة الكود أسرع — تغيير سطر واحد للإصدار يظهر فوراً كتغيير خاص بغرض واضح.