عندما تتعطل بيئة الإنتاج: لماذا تحتاج إلى تتبع الصور والتراجع عنها
تم نشر إصدار جديد من تطبيقك. بعد خمس دقائق، يبدأ المستخدمون في الإبلاغ عن أخطاء. أول سؤال يظهر في دردشة الفريق: "أي إصدار يعمل الآن؟"
إذا لم يستطع أحد الإجابة على هذا السؤال بسرعة، فستفقد وقتًا ثمينًا. تتحول الدقائق إلى ساعات بينما يبحث الأشخاص في سجلات النشر، ويتحققون من علامات السجل، ويسألون بعضهم البعض لمعرفة ما تم نشره بالفعل. بحلول الوقت الذي تعرف فيه أي صورة تعمل في الإنتاج، يكون الضرر قد تفاقم.
هذا الموقف أكثر شيوعًا مما يعترف به معظم الفرق. ويحدث لأن شيئين تم التعامل معهما كخيار: معرفة ما يعمل بالضبط، ووجود طريقة موثوقة للعودة إلى شيء كان يعمل.
التتبع يبدأ من وقت البناء
القدرة على تتبع ما يعمل في الإنتاج تبدأ في اللحظة التي تبني فيها صورة الحاوية الخاصة بك. كيف تضع علامة على تلك الصورة يحدد ما إذا كان يمكنك لاحقًا التعرف عليها بيقين.
العلامات مثل v1.2.3 أو production مفيدة للبشر. تساعدك في التعرف على الإصدارات بنظرة سريعة. لكن العلامات ليست موثوقة للتتبع. العلامة هي مجرد تسمية تشير إلى صورة، وهذه التسمية يمكن أن تتغير. الصورة myapp:production قد تشير إلى الإصدار 1.2.3 اليوم وإلى الإصدار 1.3.0 غدًا. إذا كنت تتابع العلامات فقط، فلن تعرف أبدًا على وجه اليقين أي إصدار يعمل بالفعل.
المصدر الموثوق للحقيقة هو Digest الصورة. Digest هو تجزئة فريدة يتم إنشاؤها من محتوى الصورة. إذا كانت صورتان لهما نفس Digest، فهما متطابقتان. لا غموض، ولا خطر من علامات خاطئة، ولا تسميات مستبدلة. عندما تحتاج إلى معرفة بالضبط ما يعمل، فإن Digest هو ما تحتاجه.
سجل Digest، وليس العلامة فقط
في خط الأنابيب الخاص بك، يجب عليك التقاط Digest لكل صورة تمر عبر كل مرحلة. عندما يتم بناء صورة، سجل Digest الخاص بها. عندما تجتاز فحص الأمان، سجلها مرة أخرى. عندما يتم ترقيتها إلى مرحلة الاختبار ثم إلى الإنتاج، احتفظ بهذا Digest في سجلات النشر الخاصة بك.
أين تخزن هذه المعلومات؟ المكان الأكثر عملية هو بيان النشر الخاص بك. بيان النشر هو الملف الذي يخبر نظامك بكيفية تشغيل الحاوية. في Kubernetes، هذا ملف YAML. في Docker Compose، هذا ملف compose. في كل مرة تنشر فيها، يجب أن يشير البيان إلى Digest الدقيق، وليس فقط العلامة.
هذا ما يبدو عليه في نشر Kubernetes:
لالتقاط Digest في خط الأنابيب الخاص بك، استخدم تسلسلًا مثل هذا:
# Build and push the image
docker build -t myregistry.com/myapp:latest .
docker push myregistry.com/myapp:latest
# Capture the digest from the registry
export DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myregistry.com/myapp:latest)
echo "Deploying image: $DIGEST"
# Use the digest in your deployment manifest
sed "s|image: myregistry.com/myapp:latest|image: $DIGEST|" deployment.yaml > deployment-digest.yaml
kubectl apply -f deployment-digest.yaml
يضمن هذا أن نشرك يشير دائمًا إلى محتوى الصورة الدقيق، وليس إلى علامة قابلة للتغيير.
يوضح مخطط التسلسل التالي أين يتناسب تسجيل Digest والتراجع في دورة حياة النشر:
spec:
template:
spec:
containers:
- name: myapp
image: myregistry.com/myapp@sha256:a1b2c3d4e5f6...
لاحظ الجزء @sha256:.... هذا هو Digest. عندما تستخدم هذا التنسيق، فأنت تخبر Kubernetes بتشغيل تلك الصورة بالضبط، وليس ما يشير إليه latest.
بتسجيل Digest في بيانك، فإنك تنشئ سجلاً دائمًا. يمكنك النظر إلى أي نقطة زمنية ومعرفة بالضبط أي صورة كانت تعمل. يمكنك رؤية متى تم نشرها، ومن قام بتشغيل النشر، وما التغييرات التي جاءت معها.
بدون هذا السجل، فأنت تخمن. والتخمين أثناء حادث مكلف.
التراجع: شبكة الأمان التي تبنيها قبل أن تحتاجها
التتبع يعطيك إجابة "ما الذي يعمل؟" التراجع يعطيك إجابة "كيف نعود إلى شيء كان يعمل؟"
التراجع هو عملية إعادة تطبيقك إلى إصدار سابق من الصورة كان معروفًا بأنه مستقر. لكن لا يمكنك القيام بذلك بفعالية في منتصف حادث. تحتاج إلى الاستعداد له قبل النشر.
استراتيجية تراجع جيدة تبدأ بثلاثة أسئلة:
- هل الصورة السابقة لا تزال متاحة في السجل؟
- هل بيان النشر السابق لا يزال قابلًا للاستخدام؟
- هل الصورة السابقة متوافقة مع التكوين الحالي؟
العديد من الفرق تخزن بيانات النشر الخاصة بها في Git. في كل مرة ينشرون فيها، يقومون بإيداع البيان مع Digest الدقيق. إذا حدث خطأ ما، يمكنهم التراجع عن البيان إلى إيداع سابق وإعادة النشر. هذا بسيط، وقابل للتدقيق، ويعمل عبر بيئات مختلفة.
في Kubernetes، يمكنك استخدام kubectl rollout undo للعودة إلى مراجعة سابقة. يعمل هذا الأمر لأن Kubernetes يحتفظ بسجل لمراجعات النشر. لكنك تحتاج إلى تكوين عدد المراجعات التي تريد الاحتفاظ بها. عدد قليل جدًا، وستفقد القدرة على التراجع إلى الوراء بما يكفي. عدد كبير جدًا، وستستهلك ذاكرة الكتلة لتاريخ قد لا تستخدمه أبدًا.
متى يعمل التراجع ومتى لا يعمل
التراجع سريع وفعال لمشاكل مستوى التطبيق. إذا أدخل إصدار جديد خطأ في منطق الأعمال، أو تسبب تحديث مكتبة في كسر شيء ما، فإن العودة إلى الصورة السابقة تستعيد الخدمة بسرعة.
لكن التراجع ليس حلاً شاملاً. إذا كانت المشكلة في مخطط قاعدة البيانات، فإن التراجع عن صورة التطبيق قد لا يساعد. قد تكون قاعدة البيانات بالفعل في حالة لا يستطيع رمز التطبيق القديم التعامل معها. إذا كانت المشكلة في تكوين تم تغييره بشكل منفصل عن الصورة، فإن التراجع عن الصورة وحدها يترك التكوين الخاطئ في مكانه.
اعرف حدود آلية التراجع الخاصة بك. اختبرها بانتظام. تأكد من أن فريقك يعرف متى يستخدمها ومتى يبحث عن حل آخر.
بعد التراجع، أصلح السبب الجذري
التراجع يستعيد الخدمة. لا يصلح المشكلة. بمجرد أن تتراجع ولم يعد المستخدمون متأثرين، يبدأ العمل الحقيقي.
الصورة التي تسببت في المشكلة تحتاج إلى إصلاح. يجب أن يستمر خط الأنابيب في العمل بالإصدار المصحح. تلك الصورة الجديدة تمر بنفس العملية: بناء، فحص، ترقية، نشر. كان التراجع شبكة أمان، وليس نهاية الرحلة.
بعض الفرق ترتكب خطأ معاملة التراجع كخطوة نهائية. يتراجعون، ويعلنون أن الحادث قد تم حله، ويمضون قدمًا. يظهر نفس الخطأ مرة أخرى في الإصدار التالي لأن لا أحد حقق في السبب الجذري. لا تدع هذا يحدث.
قائمة التحقق العملية
قبل نشرك التالي في الإنتاج، راجع قائمة التحقق هذه:
- كل صورة في خط الأنابيب مشار إليها بواسطة Digest، وليس فقط بالعلامة
- بيانات النشر مخزنة في التحكم في الإصدار مع Digest الدقيق
- الصور السابقة محفوظة في السجل لآخر N من الإصدارات على الأقل
- إجراءات التراجع موثقة ومختبرة في بيئة غير إنتاجية
- الفريق يعرف الفرق بين المشاكل التي يمكن للتراجع إصلاحها والمشاكل التي تحتاج إلى نهج مختلف
ماذا يعني هذا لفريقك
التتبع والتراجع ليسا موضوعين متقدمين. إنها نظافة تشغيلية أساسية. لا تحتاج إلى منصة معقدة أو أدوات باهظة الثمن لتنفيذها. تحتاج إلى انضباط في كيفية وضع العلامات على الصور، وكيفية تسجيل عمليات النشر، وكيفية الاستعداد للحظة التي يحدث فيها خطأ ما.
في المرة القادمة التي تتعطل فيها بيئة الإنتاج، سيكون السؤال الأول لا يزال: "أي إصدار يعمل؟" مع تتبع الصور في مكانه، سيكون لديك الإجابة في ثوانٍ. ومع آلية تراجع مختبرة، ستتمكن من استعادة الخدمة في دقائق بدلاً من ساعات.
ابنِ شبكة الأمان قبل أن تحتاجها. ذاتك المستقبلية، التي تتصحيح الأخطاء في الساعة 2 صباحًا، ستشكرك.