عندما يتم تشغيل Terraform Apply فعليًا: ماذا يحدث بعد الموافقة على الخطة

لقد راجعت مخرجات الخطة. تأكدت من أن Terraform سينشئ مثيلي EC2، ولن يحذف قاعدة البيانات الموجودة، وسيُرفق مجموعة الأمان الصحيحة. الآن تكتب terraform apply وتضغط Enter. يبدأ الطرفية بالتمرير برسائل مثل aws_instance.app_server: Creating... وأنت تنتظر.

هذه اللحظة هي التي تتحول فيها البنية التحتية ككود من مجرد ملف تكوين إلى بنية تحتية حقيقية. يتم تشغيل الخوادم. يتم تكوين الشبكات. يتم إنشاء سجلات DNS. ولكن ماذا يحدث بالضبط أثناء terraform apply، وكيف تتأكد من أن هذه الخطوة لا تسبب مشاكل؟

لماذا يجب استخدام ملف خطة محفوظ

الطريقة الأكثر أمانًا لتشغيل terraform apply هي تغذيته بملف خطة قمت بإنشائه مسبقًا. بعد تشغيل terraform plan -out=plan.tfplan، يمكنك تنفيذ terraform apply plan.tfplan. هذا يضمن أن Terraform يطبق بالضبط ما راجعته، لا أكثر ولا أقل.

إليك تسلسل الأوامر الدقيق لإنشاء وتطبيق ملف خطة محفوظ:

terraform plan -out=plan.tfplan
terraform apply plan.tfplan

المخاطرة في تشغيل terraform apply بدون ملف خطة حقيقية ولكنها خفية. بين الوقت الذي تشغل فيه terraform plan و terraform apply، قد يقوم شخص آخر في فريقك بدمج تغيير في نفس التكوين. أو قد تقوم بتعديل ملف متغير دون أن تدرك ذلك. عندما تشغل terraform apply بدون خطة محفوظة، يعيد Terraform تشغيل الخطة باستخدام أي تكوين موجود في تلك اللحظة. قد يختلف المخرج عما راجعته قبل عشر دقائق.

لبيئات الإنتاج، استخدم دائمًا ملف خطة محفوظ. هذا ينشئ مسار تدقيق: يمكنك الإشارة إلى plan.tfplan والقول "هذا هو بالضبط ما تمت الموافقة عليه." لبيئات التطوير أو الاختبار حيث التغييرات صغيرة ومتكررة، قد تكون راحة تشغيل terraform apply بدون ملف خطة مقبولة. فقط كن على علم بالمقايضة.

ماذا يحدث أثناء عملية Apply

عندما يتم تنفيذ terraform apply، لا يقوم ببساطة "بتطبيق التكوين." إنه يتواصل مع API المزود لكل مورد يحتاج إلى التغيير. إذا كنت تنشئ aws_instance، يستدعي Terraform API AWS EC2 لتشغيل مثيل. إذا كنت تقوم بتحديث google_storage_bucket، فإنه يستدعي API Google Cloud Storage.

كل استدعاء API يمكن أن يستغرق من أجزاء من الثانية إلى عدة دقائق. إنشاء جهاز افتراضي يستغرق عادةً من 30 ثانية إلى بضع دقائق. توفير مجموعة Kubernetes مُدارة يمكن أن يستغرق 10-15 دقيقة. يعرض Terraform التقدم في الطرفية، لكنه لا يعطيك شريط تقدم للموارد الفردية. ترى رسائل مثل:

المخطط الانسيابي التالي يلخص تدفق apply والنتائج المتفرعة عند النجاح أو الفشل:

flowchart TD A[بدء terraform apply] --> B[قراءة ملف الخطة أو إعادة التخطيط] B --> C[الحصول على قفل الحالة] C --> D[لكل مورد: استدعاء API المزود] D --> E{هل تم إنشاء/تحديث جميع الموارد؟} E -- نعم --> F[كتابة الحالة الكاملة إلى ملف الحالة] F --> G[تحرير قفل الحالة] G --> H[تم بنجاح] E -- لا --> I[حفظ حالة جزئية للموارد التي تم إنشاؤها] I --> J[تحرير قفل الحالة] J --> K[يلزم تدخل يدوي] K --> L[إصلاح المشكلة وإعادة التطبيق] K --> M[إتلاف يدوي أو استخدام terraform destroy] 
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]

خلال هذا الوقت، يحتفظ Terraform بقفل الحالة. لا يمكن لأي شخص آخر في فريقك تشغيل terraform apply أو terraform plan حتى تنتهي العملية الحالية أو تنتهي مهلة. هذا مقصود: يمنع شخصين من تعديل نفس البنية التحتية في وقت واحد.

ماذا يحدث عندما ينجح Apply

بعد إنشاء أو تحديث جميع الموارد بنجاح، يكتب Terraform الحالة الحالية إلى ملف الحالة. يسجل ملف الحالة هذا كل مورد مع معرفه الفريد، وجميع السمات، والعلاقات بين الموارد. على سبيل المثال، إذا قمت بإنشاء مثيل EC2 وأرفقت مجموعة أمان، فإن ملف الحالة يعرف أن aws_instance.app_server مرتبط بـ aws_security_group.web_sg.

يصبح ملف الحالة هذا المصدر الوحيد للحقيقة للبنية التحتية الخاصة بك. في المرة التالية التي تشغل فيها terraform plan، يقارن Terraform تكوينك بملف الحالة، وليس بموارد السحابة الحية. هذا هو السبب في أن ملفات الحالة التالفة أو المفقودة تسبب الكثير من المشاكل: يفقد Terraform نقطة مرجعيته.

ماذا يحدث عندما يفشل Apply

فشل Apply شائع بما يكفي لمعرفة كيفية التعامل معه. قد يفشل إنشاء مورد بسبب:

  • الوصول إلى حد الحصة (مثل عدد كبير جدًا من مثيلات EC2 في منطقة)
  • انتهاء صلاحية بيانات اعتماد المزود أو عدم صلاحيتها
  • وجود تعارض مع مورد موجود (مثل محاولة إنشاء سجل DNS موجود بالفعل)
  • انقطاع أو تقييد من مزود السحابة

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

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

  • إصلاح المشكلة (مثل طلب زيادة الحصة) وتشغيل terraform apply مرة أخرى. سيحاول Terraform إنشاء الموارد المتبقية.
  • إتلاف الموارد التي تم إنشاؤها يدويًا والبدء من جديد.
  • استخدام terraform destroy لتنظيف كل شيء، ولكن فقط إذا كنت متأكدًا من رغبتك في إزالة جميع الموارد.

سلوك الحالة الجزئية هذا هو أحد الأسباب التي تجعلك تختبر تغييرات البنية التحتية في بيئة غير إنتاجية أولاً. يمكن أن يترك فشل Apply في الإنتاج البنية التحتية في حالة غير متناسقة تتطلب تدخلًا يدويًا.

قائمة التحقق العملية قبل تشغيل Apply

قبل أن تكتب terraform apply على أي بيئة مهمة، راجع هذه النقاط:

  • هل راجعت مخرجات الخطة بحثًا عن تغييرات غير متوقعة، خاصة الحذف؟
  • هل ملف الحالة مدعوم أو مخزن في خلفية بعيدة مع التحكم في الإصدارات؟
  • هل لديك بيانات الاعتماد للتراجع إذا حدث خطأ ما؟
  • هل هناك نافذة صيانة أو إشعار للفريق؟
  • للإنتاج: هل استخدمت ملف خطة محفوظ (terraform apply plan.tfplan)؟
  • لتغييرات قاعدة البيانات: هل لديك خطة تراجع عن الترحيل منفصلة عن Terraform؟

الخلاصة الملموسة

تشغيل terraform apply هو اللحظة التي يصبح فيها تكوينك بنية تحتية حقيقية. استخدم ملف خطة محفوظ للإنتاج لضمان تطبيق ما تمت مراجعته بالضبط. افهم أن حالات الفشل تترك حالة جزئية، وليس تراجعًا تلقائيًا. واعرف دائمًا أين يوجد ملف الحالة الخاص بك وكيفية استعادته، لأنه بدونه، لا يمكن لـ Terraform إدارة البنية التحتية الخاصة بك على الإطلاق.