إدارة حالة البنية التحتية Terraform State وكيف تحافظ عليها من الضياع

عند العمل على البنية التحتية ككود باستخدام Terraform، فإن أخطر ملف في المشروع ليس ملف الموارد نفسه، بل ملف terraform.tfstate. هذا الملف هو الذاكرة التشغيلية التي تخبر الأداة بما تم إنشاؤه فعلياً في السحابة، وما هي المعرفات الحقيقية للموارد، وما الذي يجب تحديثه أو حذفه لاحقاً.

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

ما هو ملف Terraform State فعلياً؟

ملف الحالة هو مخرجات داخلية تحتفظ فيها أداة Terraform بخريطة بين الكود المكتوب والموارد المنشأة فعلياً لدى مزود السحابة مثل AWS أو DigitalOcean. عند تنفيذ أوامر Terraform الأساسية المذهلة (Init, Plan, Apply, Destroy)، تعتمد الأداة على هذا الملف لمعرفة الفرق بين المطلوب والموجود.

داخلياً، يحتوي الملف على معلومات مثل:

• معرّفات الموارد الحقيقية مثل instance_id.
• قيم الخصائص التي تم إنشاؤها أو قراءتها من المزود.
• المخرجات outputs المستخدمة بين المشاريع.
• علاقات الموارد داخل الرسوم البيانية للتنفيذ.
• بيانات حساسة قد تتضمن أسراراً إن لم تُدار بشكل صحيح.

لماذا ضياع الحالة أخطر من ضياع بعض ملفات الكود؟

يمكنك استعادة ملفات .tf من Git بسهولة، لكن ملف State يمثل الوضع الحقيقي المتغير مع الزمن. لهذا لا يكفي نسخه يدوياً أو تركه على جهاز المطور المحلي.

أشهر المشكلات الناتجة عن سوء إدارة الحالة تشمل:

1. تشغيل apply من جهازين مختلفين بملفين حالة مختلفين.
2. رفع الملف إلى مستودع عام فينكشف ما بداخله من معلومات بنيوية أو حساسة.
3. تلف الملف المحلي بسبب دمج خاطئ أو حذف غير مقصود.
4. غياب القفل locking مما يسبب سباق تنفيذ بين أعضاء الفريق أو داخل CI/CD.

لا تضع ملف terraform.tfstate داخل مستودع الكود، خصوصاً إن كنت تستخدم متغيرات حساسة أو مزودات سحابية تُعيد بيانات اعتماد أو معرّفات داخلية. هذا القرار وحده قد يمنع تسرباً أمنياً أو توقفاً مكلفاً للخدمات.

أفضل ممارسة: استخدام Remote Backend

الحل الاحترافي هو نقل الحالة من جهاز المطور إلى مخزن مركزي آمن يعرف باسم Remote Backend. بهذه الطريقة يصبح لدى الفريق مصدر واحد للحقيقة، مع إمكانات القفل، التحكم في الصلاحيات، والنسخ الاحتياطي.

من أشهر الخيارات في بيئات AWS استخدام S3 لتخزين الحالة، مع DynamoDB لتفعيل القفل ومنع الكتابة المتزامنة.

مثال إعداد backend بعيد

terraform {
  backend "s3" {
    bucket         = "company-terraform-state-prod"
    key            = "network/production/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

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

كيف تنقل الحالة الحالية بأمان إلى مخزن بعيد؟

إذا بدأت مشروعك محلياً بعد تثبيت Terraform وربطه مع مزود خدمة سحابي ثم أدركت لاحقاً أهمية التخزين المركزي، فلا تنسخ الملف يدوياً إلى أي مكان. الطريقة الصحيحة هي تعريف backend ثم إعادة التهيئة.

terraform init -migrate-state

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

خطوات تشغيلية موصى بها داخل الفرق

• أنشئ حساب خدمة مخصصاً للتنفيذ بدلاً من الاعتماد على حسابات شخصية.
• اجعل بيئات dev وstaging وproduction تملك مفاتيح حالة منفصلة.
• اربط التنفيذ مع خط نشر مؤتمت منضبط مثل ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟.
• امنع أي تنفيذ مباشر على الإنتاج خارج المسارات المصرح بها.

حماية الحالة من التلف، الحذف، والوصول غير المصرح

الاحتفاظ بالحالة في مخزن بعيد لا يكفي وحده. يجب تصميم طبقات حماية حولها كما نصمم الحماية حول قواعد البيانات أو الأسرار. لأن ملف الحالة قد يحتوي على بيانات حرجة تسهّل فهم البنية أو اختراقها إن وصل إلى الأيدي الخطأ.

أهم ضوابط الحماية العملية

• تفعيل التشفير encryption at rest على مخزن الحالة.
• تطبيق مبدأ أقل صلاحية least privilege على الوصول إلى الحاوية أو الدلو.
• تفعيل النسخ الإصداري versioning لاستعادة نسخة سابقة عند الفساد أو الحذف.
• إرسال السجلات إلى أنظمة التدقيق لمراقبة من قرأ أو عدّل الحالة.
• منع دمج أي ملف .tfstate داخل المستودع عبر قواعد .gitignore وفحوصات pre-commit.

echo ".terraform/" >> .gitignore
echo "*.tfstate" >> .gitignore
echo "*.tfstate.backup" >> .gitignore

في البيئات الحرجة، لا تمنح صلاحية الحذف على مخزن الحالة إلا لعدد محدود جداً من الحسابات الخدمية. حذف ملف الحالة في بيئة إنتاج قد يجرّ وراءه قرارات تدميرية خاطئة عند التنفيذ التالي.

العلاقة بين Terraform State وعمليات CI/CD

في المؤسسات الناضجة، لا يتم تنفيذ Terraform Apply من أجهزة المطورين، بل من خلال خطوط أنابيب مؤتمتة ومقيدة الصلاحيات. هذا ينسجم مع ممارسات مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) أو أي منصة مشابهة.

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

• شغّل plan عند كل pull request.
• اسمح بـ apply فقط بعد المراجعة والموافقة.
• خزّن بيانات الوصول باستخدام إدارة الأسرار (GitHub Secrets).
• اربط التنفيذ بإشعارات مراقبة وفشل عند الحاجة.

ماذا تفعل إذا فُقدت الحالة أو انحرفت عن الواقع؟

أحياناً تُحذف الحالة، أو يتم إنشاء موارد يدوياً خارج الكود، أو يتدخل مهندس بشكل مباشر من لوحة المزود. هنا يظهر ما يسمى state drift، أي انحراف الحالة عن الواقع.

الخيارات الممكنة تعتمد على شدة المشكلة:

1. استعادة نسخة سابقة من التخزين الإصداري أو النسخ الاحتياطي.
2. استخدام أوامر الاستيراد لربط الموارد الموجودة بالحالة من جديد.
3. فحص ناتج plan بدقة قبل أي تصحيح.
4. تجميد التغييرات مؤقتاً إلى أن يتم التحقق من الإنتاج.

terraform state list
terraform plan
terraform import aws_instance.web i-0abc123def4567890

هذا السيناريو شائع خصوصاً بعد إنشاء موارد سحابية يدوياً بدلاً من تعريفها برمجياً كما شرحنا في كتابة أول ملف Terraform لإنشاء سيرفر (VPS) سحابي برمجياً. كل تدخل يدوي غير موثق يزيد احتمالات الانفصال بين الكود والحقيقة التشغيلية.

نمط معماري موصى به لبيئات الإنتاج

لبيئة إنتاج مستقرة، اجعل مشروع Terraform مبنياً على وحدات modules منفصلة، مع حالة مستقلة لكل طبقة مثل الشبكات، قواعد البيانات، والحوسبة. هذا يقلل مساحة الانفجار إذا فشلت عملية واحدة، كما يجعل الاستعادة الجزئية أسهل.

كذلك لا تربط كل شيء في ملف حالة واحد عملاق. تقسيم الحالة حسب النطاقات التشغيلية يسهّل إدارة الصلاحيات ويقلل التعارضات، خاصة في فرق DevOps الكبيرة.

الخلاصة

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

كلما نضجت بيئتك، يجب أن تنتقل من إدارة محلية فردية إلى إدارة مركزية مؤتمتة ومتكاملة مع CI/CD. بهذه الطريقة لا تحافظ فقط على ملف حالة، بل تحافظ على إمكانية التحكم، الاستعادة، والتوسع الآمن في بنيتك السحابية.