عندما تتغير البنية التحتية خارج خط الأنابيب الخاص بك: تمرين اكتشاف الانجراف

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

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

البنية التحتية الخاصة بك الآن مختلفة عما يجب أن يكون عليه الكود. هذا الاختلاف يُسمى الانجراف (Drift). وإذا لم تكن تعلم بحدوثه، فقد يؤدي نشرك التالي إلى كسر أشياء بطرق لم تتوقعها.

كيف يبدو الانجراف فعليًا

يحدث الانجراف عندما تتباعد الحالة الفعلية للبنية التحتية الخاصة بك عن الحالة المرغوبة المُعرّفة في الكود. إنها ليست مشكلة نظرية. إنها تحدث طوال الوقت في الفرق الحقيقية:

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

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

تمرين بسيط لرؤية الانجراف عمليًا

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

ابدأ بإنشاء مورد واحد باستخدام Terraform. مجموعة أمان في AWS أو مخزن تخزين في أي موفر سحابي يعمل بشكل جيد. شغّل خط الأنابيب الخاص بك حتى يتم إنشاء المورد وحفظ ملف الحالة. تأكد من أنك تستطيع رؤية المورد في وحدة التحكم السحابية.

إليك تكوين Terraform بسيط يمكنك استخدامه للمتابعة:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTP and SSH traffic"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-server-sg"
    Env  = "test"
  }
}

قم بتشغيل terraform init و terraform apply لإنشاء مجموعة الأمان. بعد ذلك، في وحدة تحكم AWS، قم يدويًا بإعادة تسمية مجموعة الأمان إلى web-server-sg-manual وإزالة وسم Env. أخيرًا، قم بتشغيل terraform plan لرؤية الانجراف:

$ terraform plan
aws_security_group.web_sg: Refreshing state... [id=sg-0123456789abcdef0]

Terraform will perform the following actions:

  # aws_security_group.web_sg will be updated in-place
  ~ resource "aws_security_group" "web_sg" {
        id          = "sg-0123456789abcdef0"
      ~ name        = "web-server-sg-manual" -> "web-server-sg"
        tags        = {
          - "Env"  = "test" -> null
            "Name" = "web-server-sg"
        }
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

يُظهر الخطة أن Terraform سيعيد الاسم ويُضيف الوسم المفقود. هذا هو الانجراف عمليًا.

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

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

الهدف هو خلق موقف حيث لم يعد المورد الفعلي يطابق الكود الخاص بك. هذا هو الانجراف.

يوضح مخطط التدفق التالي تسلسل الأحداث في تمرين اكتشاف الانجراف هذا:

flowchart TD A[الحالة المرغوبة: تكوين Terraform] --> B[خط الأنابيب ينشئ المورد] B --> C[الحالة الفعلية تطابق التكوين] C --> D[تغيير يدوي في وحدة التحكم] D --> E[الحالة الفعلية تنحرف عن التكوين] E --> F[تشغيل terraform plan] F --> G{الخطة تُظهر تغييرات؟} G -- نعم --> H[تم اكتشاف الانجراف] G -- لا --> I[لا يوجد انجراف] H --> J{قرار التوفيق} J -- قبول التغيير --> K[تحديث كود Terraform] J -- استعادة التكوين --> L[تشغيل terraform apply] K --> M[تشغيل خط الأنابيب، الحالة متطابقة] L --> M

تشغيل Terraform Plan بعد الانجراف

بمجرد إجراء التغيير اليدوي، قم بتشغيل terraform plan في الطرفية الخاصة بك. انظر إلى المخرجات بعناية. سيقوم Terraform بمقارنة ملف الحالة الخاص بك بالمورد الفعلي وسيُظهر لك ما سيغيّره إذا قمت بتشغيل apply.

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

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

اكتشاف الانجراف بشكل صريح

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

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

اكتب الموارد التي انحرفت وما الذي تغير. سيساعدك هذا السجل في التفكير في الخطوة التالية.

اتخاذ قرار التوفيق

الآن لديك خيار. أنت تعلم أن البنية التحتية قد انحرفت. أنت تعلم ما الذي تغير. ماذا ستفعل حيال ذلك؟

اسأل نفسك هذه الأسئلة:

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

إذا قررت التوفيق، قم بتشغيل terraform apply. يجب أن يعود المورد إلى الحالة المُعرّفة في الكود الخاص بك. تحقق من أن كل شيء يعمل كما هو متوقع.

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

اختلافات للتجربة

بمجرد فهمك للسيناريو الأساسي، جرب اختلافات أكثر تعقيدًا:

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

كل اختلاف يُعلّمك شيئًا عن كيفية تصرف الانجراف في الأنظمة الحقيقية. كلما كان السيناريو أكثر تعقيدًا، أصبح من الواضح أن اكتشاف الانجراف والتوفيق يتطلبان تفكيرًا دقيقًا، وليس مجرد أتمتة.

قائمة مراجعة عملية لإدارة الانجراف

قبل المتابعة، إليك قائمة مراجعة قصيرة لتطبيقها في بيئتك الخاصة:

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

ما يُعلّمك إياه هذا التمرين

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

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

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