سير عمل Terraform: استراتيجيات متقدمة للعمل الفردي والجماعي

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

المفاهيم الأساسية في سير عمل Terraform

لنبدأ بتحديد الإجراءات الأساسية أولاً. جميع سير العمل الموصوفة مبنية على ثلاث خطوات رئيسية: Write (الكتابة)، Plan (التخطيط)، و Apply (التطبيق). ومع ذلك، تختلف تفاصيل وإجراءات هذه الخطوات بين سير العمل المختلفة.

• الكتابة (Write): هذه هي المرحلة التي تقوم فيها بإجراء تغييرات على التعليمات البرمجية الخاصة بالبنية التحتية.
• التخطيط (Plan): هنا تقوم بمراجعة التغييرات المقترحة وتحديد ما إذا كنت ستقبلها أو لا.
• التطبيق (Apply): هذه هي المرحلة التي توافق فيها على التغييرات وتطبقها على البنية التحتية الحقيقية.

إنها فكرة بسيطة ولكن مع مجموعة متنوعة من التطبيقات الممكنة.

سير العمل الفردي الأساسي

يُعد هذا أبسط سير عمل إذا كنت تعمل بمفردك على مشروع Terraform صغير نسبيًا. يناسب سير العمل هذا كل من الواجهات الخلفية المحلية والبعيدة بشكل جيد.

مرحلة الكتابة (Write)

تبدأ باستنساخ مستودع التعليمات البرمجية البعيد أو سحب أحدث التغييرات، ثم تقوم بتحرير التعليمات البرمجية للتكوين. بعد ذلك، تقوم بتشغيل الأوامر terraform validate و terraform fmt للتأكد من أن التعليمات البرمجية تعمل بشكل صحيح وتتبع التنسيق القياسي.

مرحلة التخطيط (Plan)

هنا تقوم بتشغيل الأمر terraform plan للتأكد من أن تغييراتك ستحقق ما تريده بالضبط. هذا هو الوقت المناسب لالتزام (commit) تغييرات التعليمات البرمجية الخاصة بك (أو يمكنك القيام بذلك في الخطوة التالية).

مرحلة التطبيق (Apply)

في هذه المرحلة، تقوم بتشغيل الأمر terraform apply لتطبيق التغييرات على كائنات البنية التحتية الحقيقية. كما أن هذا هو الوقت المناسب لدفع (push) التغييرات الملتزم بها إلى المستودع البعيد.

سير عمل الفريق الأساسي

هذا السير العمل مثالي عندما تعمل مع فريق على تعليمات برمجية للتكوين وترغب في استخدام فروع الميزات (feature branches) لإدارة التغييرات بدقة.

مرحلة الكتابة (Write)

ابدأ بإنشاء فرع جديد (checkout a new branch)، قم بإجراء تغييراتك، ثم قم بتشغيل الأوامر terraform validate و terraform fmt للتأكد من أن التعليمات البرمجية تعمل بشكل جيد. تشغيل الأمر terraform plan في هذه الخطوة سيساعد على ضمان حصولك على ما تتوقعه.

مرحلة التخطيط والمراجعة (Plan & Review)

هذه هي المرحلة التي تتم فيها مراجعات التعليمات البرمجية وخطط التغيير. أضف مخرجات الأمر terraform plan إلى طلب السحب (Pull Request) الخاص بتغييراتك. من الجيد أن تضيف فقط الأجزاء المتغيرة من المخرجات الشائعة، وهي الجزء الذي يبدأ بعبارة "Terraform will perform the following actions".

مرحلة التطبيق (Apply)

بمجرد مراجعة طلب السحب (PR) ودمجه في الفرع الرئيسي (upstream branch)، يصبح من الآمن سحب الفرع الرئيسي محليًا وتطبيق التكوين باستخدام الأمر terraform apply.

سير عمل الفريق مع الأتمتة

باختصار، يتيح لك سير العمل هذا إدخال نوع من اختبارات التدخين (smoke test) لتعليمات البنية التحتية البرمجية الخاصة بك (باستخدام plan) وأيضًا أتمتة ردود الفعل في عملية التكامل المستمر (CI process). يتكون الجزء المؤتمت من سير العمل هذا من خطة تخمينية (speculative plan) عند الالتزام (commit) و/أو طلب السحب (Pull Request - PR)، بالإضافة إلى إضافة مخرجات plan إلى تعليق طلب السحب. تعني الخطة التخمينية مجرد إظهار التغييرات، وعدم تطبيقها بعد ذلك.

مرحلة الكتابة (Write)

هذه الخطوة هي نفسها كما في سير العمل السابق.

مرحلة التخطيط المؤتمت (Automated Plan)

هنا تقوم أداة التكامل المستمر (CI tool) بعملها. دعنا نستعرض هذه الخطوة خطوة بخطوة:

• تقوم بإنشاء طلب سحب (PR) مع تغييرات التعليمات البرمجية التي ترغب في تنفيذها.
• يتم تشغيل مسار التكامل المستمر (CI pipeline) بواسطة حدث من مستودع التعليمات البرمجية الخاص بك (مثل دفع webhook push) ويقوم بتشغيل خطة تخمينية (speculative plan) مقابل التعليمات البرمجية الخاصة بك.
• تتم إضافة قائمة التغييرات (ما يسمى "plan diff") إلى طلب السحب للمراجعة بواسطة التكامل المستمر.
• بمجرد الدمج، يتم تشغيل مسار التكامل المستمر مرة أخرى وتحصل على الخطة النهائية الجاهزة للتطبيق على البنية التحتية.

مرحلة التطبيق (Apply)

الآن بعد أن أصبح لديك فرع (مثل main) يحتوي على التعليمات البرمجية الجديدة لتطبيقها، تحتاج إلى سحبها محليًا وتشغيل الأمر terraform apply. يمكنك أيضًا إضافة التطبيق المؤتمت هنا – الخطوة 5 في الصورة أعلاه. قد يكون هذا مفيدًا جدًا للبيئات القابلة للتخلص منها مثل بيئات الاختبار (testing)، التدريج (staging)، التطوير (development)، وما إلى ذلك. الأداة الدقيقة للتكامل المستمر التي ستستخدمها هنا متروكة لك: Jenkins، GitHub Actions، و Travis CI كلها تعمل بشكل جيد. من المهم ملاحظة أن مسار التكامل المستمر يجب أن يتم تكوينه بطريقة ثنائية الاتجاه مع مستودعك للحصول على التعليمات البرمجية منه وتقديم تقارير بالتعليقات إلى طلب السحب (PR). كخيار، يمكنك التفكير في استخدام Terraform Cloud الذي يحتوي على الكثير من الوظائف، بما في ذلك تكامل المستودعات المذكور أعلاه، حتى مع الاشتراك المجاني.

سير عمل الاستيراد (Import Workflow)

يشير سير العمل هذا إلى موقف تكون فيه بعض الكائنات قد تم إنشاؤها بالفعل (أي، تعمل)، وتحتاج إلى إدارتها باستخدام Terraform. لنفترض أن لدينا بالفعل حاوية S3 bucket في AWS تسمى "someassetsbucket" ونريد تضمينها في التعليمات البرمجية للتكوين الخاصة بنا.

مرحلة التحضير (Prepare)

يجب عليك إنشاء كتلة مورد (resource block) لاستخدامها لاحقًا للكائن الحقيقي الذي ستقوم باستيراده. لا تحتاج إلى ملء الوسائط فيه في البداية، لذلك قد تكون مجرد كتلة مورد فارغة، على سبيل المثال:

resource "aws_s3_bucket" "assets" {

}

مرحلة الاستيراد (Import)

الآن تحتاج إلى استيراد المعلومات حول الكائن الحقيقي إلى ملف حالة Terraform الحالي الخاص بك. يمكن القيام بذلك باستخدام الأمر terraform import، على سبيل المثال:

terraform import aws_s3_bucket.assets "someassetsbucket"

مرحلة الكتابة (Write)

الآن تحتاج إلى كتابة تعليمات Terraform البرمجية المقابلة لهذه الحاوية. لتجنب تعديل الكائن الحقيقي الخاص بك عند إجراء terraform apply، يجب عليك تحديد جميع الوسائط المطلوبة بالقيم الدقيقة من مرحلة الاستيراد. يمكنك رؤية التفاصيل عن طريق تشغيل الأمر terraform state show، على سبيل المثال:

terraform state show aws_s3_bucket.assets

سيكون مخرج هذا الأمر مشابهًا جدًا لتعليمات التكوين البرمجية. ولكنه يحتوي على كل من الوسائط والسمات للمورد، لذلك تحتاج إلى تنظيفه قبل تطبيقه. يمكنك استخدام إحدى التكتيكات التالية: إما نسخه ولصقه، ثم تشغيل terraform validate و terraform plan عدة مرات للتأكد من عدم وجود أخطاء مثل "argument is not expected here" أو "this field cannot be set"، أو يمكنك اختيار وكتابة الوسائط الضرورية فقط. في أي حال، تأكد من الرجوع إلى وثائق المورد خلال هذه العملية.

مرحلة التخطيط (Plan)

الهدف هو الحصول على مخرجات terraform plan تظهر تغييرات "~ update in-place" فقط. ومع ذلك، ليس من الواضح دائمًا ما إذا كان الكائن الحقيقي سيتم تعديله أو سيتم تحديث ملف الحالة فقط. لهذا السبب يجب أن تفهم كيفية عمل الكائن الحقيقي وتعرف دورة حياته للتأكد من أنه آمن لتطبيق الخطة.

مرحلة التطبيق (Apply)

هذا هو إجراء terraform apply المعتاد. بمجرد التطبيق، سيتوافق التكوين وملف الحالة الخاص بك مع تكوين الكائن الحقيقي.

الخلاصة التقنية

تُظهر استعراضات سير عمل Terraform هذه المرونة والقوة التي يوفرها لإدارة البنية التحتية كتعليمات برمجية (Infrastructure as Code). سواء كنت تعمل بمفردك على مشروع صغير أو ضمن فريق كبير يستخدم التكامل المستمر والأتمتة، فإن اعتماد سير عمل منظم أمر بالغ الأهمية لضمان الاتساق، تقليل الأخطاء، وتحسين الكفاءة. من خلال فهم المراحل الأساسية (الكتابة، التخطيط، التطبيق) وتكييفها مع احتياجاتك الخاصة، يمكنك تحقيق أقصى استفادة من Terraform، حتى في سيناريوهات معقدة مثل استيراد الموارد الموجودة. إن الاستثمار في تحديد وتطبيق سير عمل واضح لا يقل أهمية عن كتابة التعليمات البرمجية نفسها، فهو يمثل حجر الزاوية في ممارسات DevOps الحديثة.