لماذا يجب عليك دائمًا رؤية الخطة قبل تشغيل Terraform
لقد انتهيت للتو من كتابة تكوين Terraform لخادم وقاعدة بيانات جديدين. يبدو الملف صحيحًا. تقوم بتشغيل terraform apply وتنتظر. بعد بضع ثوانٍ، تدرك أن حجم الخادم أكبر بمرتين من اللازم، وأن قاعدة البيانات في المنطقة الخطأ. الآن عليك تفكيك كل شيء والبدء من جديد.
هذا السيناريو يتكرر باستمرار في الفرق الجديدة في مجال البنية التحتية كرمز. الرغبة في تخطي الخطوات وتطبيق التغييرات مباشرة قوية. لكن هناك خطوة توفر الوقت والمال والإحباط: رؤية الخطة قبل تنفيذها.
ماذا يحدث عندما تتخطى الخطة
عندما تقوم بتشغيل terraform apply مباشرة، يبدأ Terraform فورًا في إنشاء أو تعديل أو حذف الموارد بناءً على تكوينك. إذا كان هناك خطأ ما، ستكتشفه فقط بعد إجراء التغييرات. قد يكون التراجع بسيطًا لبعض الموارد، لكن بالنسبة لموارد أخرى قد يتضمن تنظيفًا يدويًا، أو تذاكر دعم مع موفري الخدمات السحابية، أو توقفًا للمستخدمين.
المشكلة ليست فقط في أخطاء التكوين. حتى عندما يكون تكوينك صحيحًا تقنيًا، قد يكون للتغييرات آثار جانبية لم تتوقعها. تغيير في تكوين الشبكة قد يكسر الاتصال بين الخدمات. تقليل حجم التخزين قد يسبب فقدان البيانات. تحديث مجموعة أمان قد يعرض الموارد الداخلية للإنترنت عن طريق الخطأ.
أنت بحاجة إلى طريقة لمعاينة ما سيفعله Terraform قبل أن يفعله.
كيف تعمل خطة Terraform
يقوم أمر terraform plan بإنشاء ما يسمى خطة التنفيذ. يقرأ ملفات التكوين الخاصة بك ويقارنها بالحالة الحالية للبنية التحتية الخاصة بك، المخزنة في ملف حالة Terraform. يُظهر المخرجات بالضبط الموارد التي سيتم إنشاؤها أو تعديلها أو حذفها، بالإضافة إلى تفاصيل كل تغيير.
الفرق الحاسم هو أن terraform plan لا يقوم فعليًا بأي تغييرات. إنه يقرأ ويقارن فقط. لا يتم إنشاء أو تحديث أو تدمير أي موارد. يمكنك تشغيله عدة مرات كما تريد دون التأثير على البنية التحتية الخاصة بك.
إليك ما يحدث عند تشغيله:
terraform plan
يتصل Terraform بالموفر الخاص بك، ويقرأ التكوين الخاص بك، ويتحقق من الحالة الحالية، ويطبع ملخصًا للإجراءات المخطط لها. بالنسبة لتكوين الخادم وقاعدة البيانات السابق، قد يبدو الإخراج كالتالي:
- سيتم إنشاء خادم افتراضي واحد بمعالج ثنائي النواة وذاكرة وصول عشوائي 8 جيجابايت
- سيتم إنشاء قاعدة بيانات واحدة بسعة تخزين 100 جيجابايت
- سيتم ربط كلا الموردين عبر شبكة داخلية
إذا كان لديك بالفعل خادم قيد التشغيل وقمت بتغيير تكوينه، ستظهر الخطة أنه سيتم تحديث الخادم الحالي في مكانه، وليس تدميره وإعادة إنشائه. هذا الفرق مهم لأن التحديثات في المكان عادة ما تكون أكثر أمانًا وأسرع من الاستبدال.
لماذا تهم الخطة لسير عملك
تمنحك خطة التنفيذ ثلاثة أشياء يصعب الحصول عليها بطريقة أخرى.
أولاً، يمكنك التحقق من أن تغييراتك تطابق ما قصدته. قبل الالتزام بتطبيق التغييرات، لديك فرصة لمراجعة التفاصيل. هل قمت عن طريق الخطأ بتعيين نوع مثيل خاطئ؟ هل إصدار محرك قاعدة البيانات صحيح؟ تظهر الخطة هذه التفاصيل بوضوح.
ثانيًا، يمكنك اكتشاف الآثار الجانبية التي لم تفكر فيها. ربما قمت بتغيير متغير يؤثر على موارد متعددة. ربما يؤدي تعديل بسيط في التكوين إلى استبدال مورد بدلاً من تحديثه. تبرز الخطة هذه التبعيات المخفية.
ثالثًا، يمكنك مشاركة الخطة مع أشخاص آخرين. في بيئة الفريق، ليس من الضروري أن يفهم الجميع بناء جملة Terraform. لكن معظم المهندسين يمكنهم قراءة مخرجات الخطة واكتشاف المشكلات المحتملة. يمكن لمسؤول قاعدة البيانات التحقق من أن تكوين التخزين مناسب. يمكن لمهندس الأمن التحقق من أن قواعد الشبكة ليست متساهلة للغاية.
استخدام الخطة في خطوط CI/CD
في بيئات الفريق، عادة ما تتم أتمتة terraform plan في خط أنابيب CI/CD. عندما يفتح شخص ما طلب سحب يغير تكوين البنية التحتية، يقوم خط الأنابيب بتشغيل terraform plan تلقائيًا وينشر النتيجة كتعليق على طلب السحب.
يعني سير العمل هذا أن الفريق بأكمله يمكنه مراجعة ما سيتغير قبل دمج الكود. تتم المناقشة حول مخرجات الخطة، وليس حول أوصاف مجردة لما قد يفعله الكود. يتم الرد على أسئلة مثل "لماذا يتم استبدال هذا المورد؟" أو "هل يجب أن تكون مجموعة الأمان هذه مفتوحة للإنترنت؟" قبل تطبيق أي تغييرات.
يوضح المخطط الانسيابي التالي دورة المراجعة والتطبيق النموذجية المستخدمة في خطوط CI/CD:
تذهب بعض الفرق إلى أبعد من ذلك من خلال طلب الموافقة على مخرجات الخطة قبل أن تتمكن خطوة التطبيق من المتابعة. تصبح الخطة نقطة تفتيش تتحكم في التغييرات التي تصل إلى البنية التحتية للإنتاج.
خطأ شائع: الخطط القديمة
هناك قيد مهم يجب فهمه. خطة التنفيذ هي لقطة لما سيفعله Terraform في اللحظة التي قمت فيها بتشغيل الأمر. إذا قام شخص آخر بتغيير البنية التحتية بين وقت تشغيل terraform plan ووقت تشغيل terraform apply، فقد لا تكون الخطة دقيقة بعد الآن.
على سبيل المثال، لنفترض أنك قمت بتشغيل terraform plan ورأيت أنه سيتم إنشاء خادم واحد. قبل تشغيل terraform apply، يقوم زميل في الفريق بإنشاء نفس الخادم يدويًا من خلال وحدة التحكم السحابية. عند تشغيل terraform apply، سيكتشف Terraform التعارض ويفشل، أو الأسوأ من ذلك، قد يقوم بإنشاء مورد مكرر اعتمادًا على كيفية كتابة التكوين الخاص بك.
لهذا السبب تحافظ سير العمل الجيدة على بقاء خطوات الخطة والتطبيق قريبة من بعضها البعض. في خطوط CI/CD، يقوم نفس تشغيل خط الأنابيب عادةً بتنفيذ كلا الخطوتين بالتسلسل. للتطوير المحلي، يجب عليك تشغيل الخطة مباشرة قبل التطبيق، وليس بعد ساعات أو أيام.
تستخدم بعض الفرق أيضًا قفل الحالة لمنع التعديلات المتزامنة. عندما يقوم شخص أو خط أنابيب بتشغيل خطة أو تطبيق، يتم منع الآخرين من إجراء تغييرات حتى تكتمل العملية.
قائمة مراجعة عملية لاستخدام خطة Terraform
- قم بتشغيل
terraform planقبل كلterraform apply، حتى للتغييرات الصغيرة - راجع مخرجات الخطة بحثًا عن عمليات استبدال أو حذف غير متوقعة للموارد
- تحقق من أن عدد الموارد التي يتم إنشاؤها يطابق توقعاتك
- ابحث عن التغييرات في مجموعات الأمان وقواعد الشبكة وسياسات IAM
- شارك مخرجات الخطة مع أعضاء الفريق المعنيين للمراجعة
- في CI/CD، انشر الخطة كتعليق على طلبات السحب
- حافظ على خطوات الخطة والتطبيق قريبة من بعضها البعض في الوقت
- استخدم قفل الحالة لمنع التعارضات في بيئات الفريق
ما تكسبه من هذه العادة
إن عادة تشغيل terraform plan قبل كل تغيير تحول سير عملك من رد الفعل إلى المتعمد. بدلاً من اكتشاف المشكلات بعد إنشاء الموارد، تلتقطها بينما لا تزال مجرد نص على الشاشة. تكلفة إصلاح خطأ في خطة هي صفر. تكلفة إصلاحه بعد التطبيق يمكن أن تكون ساعات من التصحيح والتنظيف اليدوي والتنسيق مع فريقك.
في المرة القادمة التي تكتب فيها تكوين Terraform، قم بتشغيل الخطة أولاً. اقرأ المخرجات بعناية. ثم قرر ما إذا كنت ستطبق. تلك الخطوة الإضافية الواحدة هي ما يفصل بين الفرق التي تدير البنية التحتية بثقة والفرق التي تقوم باستمرار بالتنظيف وراء نفسها.