الحالة: قلب Terraform

الحالة: قلب Terraform

في كل مرة ينشئ فيها Terraform بنية تحتية أو يعدّلها أو يحذفها، يُسجّل النتيجة في ملف مرجعي وحيد يُعرف بـالحالة (State). بدون هذا الملف، لن يعرف Terraform ما سبق بناؤه، وسيحاول في كل مرة إنشاء كل شيء من الصفر. ولذلك فإن الحالة ليست ميزة اختيارية، بل هي الآلية التي تُتيح إدارة البنية التحتية بصورة تدريجية وقابلة للتكرار دون تكرار الأعمال..

ما هي الحالة فعليًا؟

الحالة هي مستند JSON (يُسمى عادةً terraform.tfstate) يربط كل مورد في إعداداتك بنظيره الحقيقي عبر واجهة برمجة المزوّد. فمثلاً بالنسبة لنموذج EC2 في AWS، يحتفظ ملف الحالة بمعرّف النموذج والـ AMI والعنوان الخاص ومجموعات الأمان والوسوم وعشرات السمات الأخرى التي لم يكن Terraform يعرفها وقت التخطيط. وتُستخدم هذه السمات المخزّنة من أجل:

• حساب الفوارق — مقارنة الإعداد المطلوب بالحالة الفعلية في السحابة دون استدعاء واجهة برمجة التطبيقات لكل سمة على حدة.
• بناء مخطط التبعيات — المراجع العابرة بين الموارد كـ aws_subnet.main.id تُحلَّل من الحالة لا من استدعاءات API مباشرة.
• اكتشاف الانجراف — عند تعديل البنية التحتية خارج Terraform، تكشف الحالة عن التناقض.
• تفعيل العمليات المحددة — terraform apply -target=aws_instance.web يعمل لأن Terraform يعرف أي الموارد قائمة بالفعل.

المقارنة الثلاثية

كل terraform plan يُجري مقارنة ثلاثية:

1. الحالة المطلوبة — ملفات .tf الخاصة بك.
2. الحالة المُسجَّلة — terraform.tfstate.
3. الحالة الفعلية — قراءة حديثة من واجهة برمجة المزوّد (ما يُعرف بـ "التحديث" أو refresh).

يقارن Terraform المطلوب مع المُسجَّل بعد تحديثه لإنتاج الخطة. ولهذا السبب تُجري terraform plan استدعاءات API حقيقية: فهي تحتاج إلى تحديث الحالة المُسجَّلة قبل إجراء الفارق. يمكنك تخطّي التحديث بـ -refresh=false لتسريع العملية، لكن لا تفعل ذلك إلا عندما تكون متأكدًا من عدم وجود أي تغيير خارجي.

تشريح ملف الحالة

لا يُقصد تعديل ملف الحالة يدويًا، لكن قراءته تُعلّمك بالضبط ما يتتبعه Terraform. بعد تشغيل terraform apply على VPC وشبكة فرعية بسيطة، يحتوي الملف على مصفوفة resources يحمل كل إدخال فيها:

• mode — إما managed (أنشأه Terraform) أو data (مصدر بيانات للقراءة فقط).
• type وname — مثلاً aws_vpc / main.
• provider — عنوان المزوّد المسؤول عن هذا المورد.
• instances — مصفوفة (إدخال واحد لكل نسخة عبر count أو for_each) تحتوي على schema_version وخريطة attributes كاملة.

فحص الحالة بأمان

لا تفتح terraform.tfstate في محرر نصي للفحص الروتيني. استخدم أوامر CLI التي تحلل الحالة وتعرضها بوضوح، وتحترم القفل عند استخدام الحالة البعيدة.

يبدو ناتج terraform state show aws_vpc.main كالتالي عندما تكون الـ VPC قيد التشغيل:

عمليات الحالة التي يجب أن تعرفها

إلى جانب الفحص، يمنحك الأمر الفرعي terraform state تحكمًا دقيقًا:

• terraform state mv — إعادة تسمية مورد أو نقل عنوانه في الحالة دون تدميره وإعادة إنشائه. ضروري عند إعادة هيكلة إعداد مسطح إلى وحدات (modules).
• terraform state rm — حذف مورد من الحالة دون لمس البنية التحتية الفعلية. يُستخدم عندما تريد أن "ينسى" Terraform موردًا ما (مثلاً عند نقله لحالة فريق آخر).
• terraform import — إدراج مورد سحابي قائم تحت إدارة Terraform بكتابة سماته في الحالة. ضروري للتعامل مع البنية التحتية الموروثة (brownfield).

رقم التسلسل وحارس الإصدار

كل كتابة على الحالة تزيد رقم serial بمقدار واحد. إذا طبّق مهندسان في آنٍ واحد من أجهزة مختلفة — كلاهما بدأ من serial رقم 7 — فإن الثاني الذي ينتهي سيجد أن الحالة البعيدة باتت عند serial رقم 8 وسيرفض الكتابة فوقها. هكذا تعمل الحالة كقفل تزامن متفائل عند استخدام backend بعيد. ملف terraform.tfstate المحلي لا يملك هذه الحماية، وهذا تحديدًا لماذا الحالة المحلية آمنة للمشغّل الفردي فقط.

القيم الحساسة في الحالة

يخزّن Terraform جميع سمات الموارد في الحالة، بما فيها الأسرار ككلمات مرور قواعد البيانات والمفاتيح الخاصة ورموز الوصول. حتى لو وسّمت ناتجًا بـ sensitive = true، تبقى القيمة موجودة بنص صريح داخل ملف الحالة. لهذا تداعيات أمنية مباشرة في الإنتاج:

• لا تُلزم terraform.tfstate أو terraform.tfstate.backup أبدًا في نظام إدارة الإصدار. أضف كليهما إلى .gitignore فورًا.
• استخدم backend بعيدًا مع تشفير وقت التخزين (S3 + SSE-KMS أو Terraform Cloud) حتى لا تُخزَّن الحالة أبدًا على جهاز مطوّر.
• قيّد وصول IAM / RBAC إلى bucket الحالة على دور CI/CD والمهندسين الرئيسيين فقط.