أين يجب تخزين حالة البنية التحتية؟ دليل عملي

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

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

ما هي الحالة ولماذا هي مهمة؟

الحالة هي سجل لكل ما أنشأته أداة البنية التحتية الخاصة بك. تحتوي على معرفات الموارد وعناوين IP وقيم التكوين، وأحيانًا حتى كلمات المرور أو مفاتيح API المخزنة كنص عادي. عندما تقوم بتشغيل terraform plan، تقرأ الأداة الحالة الحالية لتفهم ما هو موجود بالفعل وما يحتاج إلى تغيير. بدون حالة دقيقة، لا يمكن للأداة معرفة ما إذا كان يجب إنشاء مورد أو تحديثه أو تركه كما هو.

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

فخ الملف المحلي

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

ولكن بمجرد انضمام شخص ثانٍ، ينهار التخزين المحلي. إليك ما يحدث:

  • تقوم بإنشاء خادم. ملف الحالة الخاص بك يسجله.
  • زميلك يقوم بتشغيل نفس التكوين. ملف الحالة الخاص به فارغ، لذلك تحاول الأداة إنشاء خادم آخر بنفس الاسم.
  • مزود السحابة يرفض التكرار، أو الأسوأ من ذلك، تقوم الأداة باستبدال الخادم الموجود لأنها لا تعلم بوجوده.

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

لمساعدتك في تحديد النهج الذي يناسب حالتك، إليك مخطط تدفق القرار:

flowchart TD A[كم عدد الأشخاص الذين يديرون البنية التحتية؟] --> B[شخص واحد] A --> C[عدة أشخاص] B --> D[الملف المحلي مقبول] C --> E[بحاجة إلى خلفية بعيدة] E --> F[اختر نوع الخلفية] F --> G[S3 + DynamoDB] F --> H[GCS] F --> I[Azure Storage] F --> J[Terraform Cloud] F --> K[Consul] G --> L[يدعم التأمين والإصدار] H --> L I --> L J --> M[مُدار، عبء تشغيلي أقل] K --> M L --> N[قم بإعداد التحكم في الوصول] M --> N N --> O[جاهز للاستخدام من قبل الفريق]

الخلفية البعيدة: مصدر الحقيقة المشترك

الخلفية البعيدة تخزن الحالة في موقع يمكن لجميع أعضاء الفريق الوصول إليه. الخيارات الشائعة تشمل دلو S3 على AWS، أو دلو GCS على Google Cloud، أو حاوية Azure Storage. الجميع يوجهون أداة البنية التحتية الخاصة بهم إلى نفس الخلفية، لذلك تكون الحالة متسقة دائمًا.

إليك تكوين خلفية Terraform بسيط يستخدم دلو S3 لتخزين الحالة وجدول DynamoDB للتأمين:

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "production/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

قبل استخدام هذا التكوين، قم بإنشاء دلو S3 مع تمكين الإصدار وجدول DynamoDB بمفتاح أساسي باسم LockID (من نوع String). يضمن إعداد encrypt = true تشفير ملف الحالة أثناء التخزين.

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

التحكم في الوصول غير قابل للتفاوض

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

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

مقايضات السرعة والتكلفة

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

بعض الخلفيات تفرض رسومًا لكل عملية أو لكل غيغابايت من التخزين. S3، على سبيل المثال، تفرض رسومًا على طلبات PUT و GET. إذا كان فريقك يقوم بتشغيل terraform plan عشرات المرات في اليوم، فإن هذه التكاليف تتراكم. اختر خلفية تناسب نمط استخدام فريقك.

الإصدار ينقذك من الأخطاء

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

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

الخلفيات المُدارة تقلل العبء التشغيلي

إذا كنت لا تريد إدارة دلو وسياسات الوصول والإصدار بنفسك، فكر في خلفية مُدارة مثل Terraform Cloud أو HashiCorp Consul. هذه الخدمات مصممة خصيصًا لإدارة الحالة. تتضمن الإصدار والسجل والتأمين والتكامل مع خطوط CI/CD.

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

التأمين يمنع التغييرات المتزامنة

حتى مع خلفية بعيدة، يمكن لشخصين تشغيل terraform apply في نفس الوقت. بدون تأمين، تقرأ كلتا العمليتين نفس الحالة، وتجري التغييرات، وتكتب النتائج. الكتابة الثانية تستبدل الأولى، ويتم فقدان تغييرات الشخص الأول.

معظم الخلفيات البعيدة تدعم التأمين. S3 مع DynamoDB، على سبيل المثال، تستخدم جدول DynamoDB لحمل قفل. عندما يبدأ شخص عملية، تكتسب الأداة القفل. يجب أن تنتظر العمليات الأخرى حتى يتم تحرير القفل. هذا يمنع تلف الحالة من الكتابات المتزامنة.

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

قائمة تحقق عملية لتخزين الحالة

قبل أن تقرر أين تخزن الحالة، راجع قائمة التحقق هذه:

  • هل الخلفية متاحة لكل من يحتاجها؟
  • هل الوصول مقصور على الأشخاص والأنظمة المصرح لهم؟
  • هل تدعم الخلفية الإصدار؟
  • هل تدعم الخلفية التأمين؟
  • هل التكلفة مقبولة لاستخدام فريقك؟
  • هل زمن الاستجابة مقبول لسير عملك؟

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

الخلاصة العملية

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