عندما يجب أن يخدم تكوين بنية تحتية واحد بيئات متعددة

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

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

هناك نهجان شائعان يحلان هذه المشكلة: مساحات العمل (Workspaces) والوحدات الجذرية المنفصلة (Root Modules). يتعاملان مع نفس المشكلة بطرق مختلفة جوهريًا، ويعتمد الاختيار بينهما على كيفية عمل فريقك ومدى الفصل الذي تحتاجه بيئاتك.

مساحات العمل: قاعدة كود واحدة، حالات متعددة

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

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

يوضح الرسم البياني أدناه الفرق الهيكلي بين النهجين.

إليك كيف يبدو سير العمل هذا عمليًا:

# إنشاء مساحة عمل لكل بيئة
terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

# التبديل إلى مساحة عمل التطوير
export TF_WORKSPACE=dev
# أو استخدم: terraform workspace select dev

# تخطيط وتطبيق التغييرات لمساحة العمل النشطة
export TF_VAR_instance_type=t3.micro
terraform plan -out=dev.tfplan
terraform apply dev.tfplan

# التبديل إلى الإنتاج عند الاستعداد
export TF_WORKSPACE=prod
export TF_VAR_instance_type=t3.large
terraform plan -out=prod.tfplan
terraform apply prod.tfplan
flowchart TD subgraph Workspaces A1["قاعدة كود واحدة"] --> B1["مساحة عمل: dev"] A1 --> C1["مساحة عمل: staging"] A1 --> D1["مساحة عمل: prod"] B1 --> E1["حالة: dev"] C1 --> F1["حالة: staging"] D1 --> G1["حالة: prod"] E1 --> H1["واجهة خلفية واحدة"] F1 --> H1 G1 --> H1 end subgraph Root_Modules I1["وحدة مشتركة"] --> J1["تكوين جذر: dev"] I1 --> K1["تكوين جذر: staging"] I1 --> L1["تكوين جذر: prod"] J1 --> M1["واجهة خلفية: dev"] K1 --> N1["واجهة خلفية: staging"] L1 --> O1["واجهة خلفية: prod"] end

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

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

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

الوحدات الجذرية: مجلدات منفصلة، منطق مشترك

البديل هو إعطاء كل بيئة وحدتها الجذرية الخاصة. بدلاً من مجلد واحد بثلاث مساحات عمل، لديك ثلاثة مجلدات: dev و staging و prod. يحتوي كل مجلد على ملف التكوين الرئيسي الخاص به وتكوين الواجهة الخلفية للحالة الخاص به. إنها مستقلة تمامًا.

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

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

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

متى تستخدم أيًا منهما

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

الوحدات الجذرية تعمل بشكل أفضل للفرق الأكبر، أو البيئات التي تحتاج إلى فصل صارم، أو المواقف التي تتطلب فيها كل بيئة سير عمل موافقة مختلف. إذا كانت تغييرات الإنتاج تحتاج إلى مراجعة طلب سحب، وموافقة مدير، ونافذة تغيير، بينما يمكن تطبيق تغييرات التطوير مباشرة، فإن الوحدات الجذرية تجعل هذا الفصل طبيعيًا. يمكن أن يكون لكل مجلد بيئة خط أنابيب CI/CD خاص به مع بوابات مختلفة.

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

قائمة مراجعة عملية

قبل اختيار نهجك، اطرح هذه الأسئلة:

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

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

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

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