عندما يغير شخصان نفس حالة البنية التحتية في نفس الوقت

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

هذا ليس عن شخصين يعدلان نفس المورد مباشرة. إنه عن شخصين يعدلان سجل تلك الموارد. والحل هو آلية تسمى قفل الحالة (State Locking).

ما الذي يفعله قفل الحالة بالضبط

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

يوضح مخطط التسلسل التالي كيفية تفاعل مطورين مع خلفية الحالة والقفل:

sequenceDiagram participant A as Developer A participant B as Developer B participant S3 as State Backend (S3) participant DB as Lock Backend (DynamoDB) A->>DB: Acquire lock DB-->>A: Lock acquired A->>S3: Read current state S3-->>A: State data B->>DB: Acquire lock DB-->>B: Lock denied (wait) A->>S3: Write new state S3-->>A: OK A->>DB: Release lock DB-->>A: Lock released B->>DB: Acquire lock DB-->>B: Lock acquired B->>S3: Read current state S3-->>B: State data

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

كيف تتعامل الخلفيات المختلفة مع الأقفال

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

إليك تكوين خلفية Terraform بسيط يتيح قفل الحالة مع S3 وDynamoDB:

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

الخاصية dynamodb_table تخبر Terraform باستخدام جدول DynamoDB باسم terraform-locks للقفل. يجب أن يكون هذا الجدول موجودًا قبل تشغيل terraform init. يحتاج إلى مفتاح أساسي باسم LockID (من نوع String). سيقوم Terraform تلقائيًا بإنشاء وإدخالات القفل وتحريرها في هذا الجدول أثناء عمليات الحالة.

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

عندما تفشل الأقفال

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

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

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

لماذا هذا مهم أبعد من مجرد القفل

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

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

قائمة تحقق عملية لقفل الحالة

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

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

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