أوامر Terraform الأساسية المذهلة (Init, Plan, Apply, Destroy)

إذا كنت تبني بنية سحابية حديثة، فإن فهم أوامر Terraform الأساسية ليس مجرد خطوة تعليمية، بل هو حجر الأساس لأي ممارسة احترافية في البنية التحتية ككود. هذه الأوامر الأربع تمثل دورة حياة المورد السحابي بالكامل: التهيئة، المعاينة، التنفيذ، ثم الإزالة عند الحاجة.

في البيئات الواقعية، لا تُستخدم هذه الأوامر بمعزل عن غيرها، بل تدخل داخل خطوط CI/CD، وتتكامل مع أدوات مثل GitHub Actions وJenkins لإنشاء بيئات آلية قابلة للتكرار، موثوقة، وقابلة للمراجعة قبل أي تغيير على الخوادم أو الشبكات أو قواعد البيانات.

لماذا هذه الأوامر مهمة لكل مهندس DevOps؟

عند إدارة بنية سحابية يدوياً من لوحة التحكم، يصبح تتبع التغييرات صعباً، ويزداد خطر الاختلاف بين البيئات مثل development وstaging وproduction. أما مع Terraform، فإن البنية نفسها تتحول إلى ملفات قابلة للإصدار والمراجعة.

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

مثال عملي بسيط قبل شرح الأوامر

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

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

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

هذا المثال ليس بنية إنتاجية كاملة، لكنه كافٍ لفهم كيف تتحرك الأوامر الأربع ضمن دورة تنفيذ منضبطة.

الأمر الأول: terraform init

أمر init هو نقطة البداية الإلزامية. وظيفته تهيئة مجلد المشروع، تنزيل مزودي الخدمة providers، وتجهيز ملفات الحالة المحلية أو الخلفيات البعيدة backend عند استخدامها.

بدون هذا الأمر، لن يعرف المشروع من أين يجلب الإضافات اللازمة للتواصل مع AWS أو DigitalOcean أو غيرهما. كما يُعاد تشغيله عند تغيير إعدادات المزود أو تعديل نوع التخزين الخاص بملف الحالة.

terraform init

ماذا يفعل فعلياً؟

• ينزل الإضافات الخاصة بمزود الخدمة.
• ينشئ مجلد .terraform.
• يقرأ القيود الخاصة بالإصدارات.
• يجهز التكامل مع remote state إذا تم تعريفه.

لا ترفع مجلد .terraform أو ملفات الحالة الحساسة مثل terraform.tfstate إلى المستودع العام. هذه الملفات قد تحتوي على بيانات بنيوية حساسة وربما معرفات موارد أو أسرار مرتبطة بالمزود السحابي.

الأمر الثاني: terraform plan

بعد التهيئة، يأتي دور أهم مرحلة مراجعة: plan. هذا الأمر لا ينفذ التغييرات، بل يعرض ما الذي سيحدث إن وافقت عليه. عملياً، هو طبقة أمان تمنع تنفيذ تعديلات غير متوقعة على الإنتاج.

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

terraform plan

كيف نقرأ نتيجة plan؟

• الرمز + يعني إنشاء مورد جديد.
• الرمز ~ يعني تعديل مورد موجود.
• الرمز - يعني حذف مورد.
• الرمز -/+ يعني استبدال المورد بالكامل.

في البيئات المؤسسية، من الأفضل حفظ الخطة في ملف ثم تمريرها لاحقاً إلى التنفيذ، حتى تضمن أن ما تمت مراجعته هو نفسه ما سيتم تطبيقه فعلاً.

terraform plan -out=tfplan

الأمر الثالث: terraform apply

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

إذا استخدمت ملف خطة محفوظاً، فإن التنفيذ يصبح أكثر انضباطاً، خاصة داخل أنظمة مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) أو أدوات الموافقة المرحلية.

terraform apply tfplan

أفضل ممارسات عند التنفيذ

• نفذ plan دائماً قبل apply.
• استخدم حسابات خدمة بصلاحيات محدودة وفق مبدأ least privilege.
• افصل بين بيئات الاختبار والإنتاج باستخدام ملفات متغيرات مستقلة.
• ادمج التنفيذ داخل مسار مراجعة يعتمد على Pull Request.

تنفيذ terraform apply -auto-approve على بيئة إنتاجية بدون مراجعة خطة مسبقة قد يؤدي إلى حذف مورد حرج أو تغيير شبكة تشغيلية، وبالتالي حدوث Downtime أو انقطاع خدمة كامل.

الأمر الرابع: terraform destroy

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

هذه الفكرة أساسية في أنماط البنية المؤقتة ephemeral environments التي تُنشأ مع كل فرع أو مراجعة ثم تُزال بعد انتهاء التحقق، مما يقلل التكلفة السحابية ويمنع تراكم موارد منسية.

terraform destroy

متى نستخدمه بحذر شديد؟

• عند حذف بيئة اختبارية كاملة بعد انتهاء مهمة.
• عند تنظيف موارد مكررة أنشئت للتجارب.
• عند إيقاف بنية مؤقتة مرتبطة بفرع تطوير.
• عند الانتقال إلى تصميم جديد يتطلب إعادة إنشاء الموارد من الصفر.

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

كيف تدخل هذه الأوامر داخل خط CI/CD؟

في المشاريع المتقدمة، لا يعمل المهندس محلياً فقط، بل يربط التنفيذ بمسار آلي يبدأ مع Push أو Pull Request. هنا يمكن تشغيل الترتيب التالي:

1. تنزيل المستودع.
2. تشغيل terraform init.
3. التحقق من الصياغة والمنطق.
4. تشغيل terraform plan.
5. عرض الخطة للمراجعة البشرية.
6. تنفيذ terraform apply بعد الموافقة.

هذا التكامل يصبح أكثر أماناً عند استخدام إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة، لأن مفاتيح الوصول السحابي يجب ألا تُخزن داخل الملفات النصية أو المستودعات.

أخطاء شائعة يجب تجنبها

• تشغيل apply مباشرة دون مراجعة الخطة.
• مشاركة ملف الحالة بين عدة أشخاص بدون قفل locking.
• استخدام صلاحيات إدارية مطلقة بدلاً من حسابات محدودة المهمة.
• عدم عزل البيئات بمتغيرات أو workspaces.
• الاعتماد على تغييرات يدوية من لوحة السحابة ثم نسيان مزامنتها مع الكود.

الخلاصة

أوامر terraform init وterraform plan وterraform apply وterraform destroy ليست أوامر تشغيل عادية، بل تمثل منهجية كاملة لإدارة البنية السحابية بشكل يمكن التنبؤ به ومراجعته وأتمتته.

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