Helm / أساسي: أسس الحزمة والتصيير / الدرس 1

الحزم والإصدارات وحدود الدليل

ميّز مصدر الحزمة القابل لإعادة الاستخدام والإصدار المسمى وكائنات Kubernetes الناتجة، وحدد ما تثبته المراجعة دون اتصال.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-28

في هذه الصفحة

أهداف الدرس

الفصل بين نسخة الحزمة ونسخة التطبيق ومراجعة الإصدار.
تتبع المدخلات عبر التصيير ثم تسوية Kubernetes للحالة.
تحديد الدليل المناسب للتغليف والقبول وسلوك التطبيق.

افصل بين ثلاث هويات

الحزمة chart مجموعة قابلة لإعادة الاستخدام من القوالب والقيم الافتراضية. أما release فهو تثبيت مسمى لحزمة داخل namespace. وتسجل مراجعة الإصدار تغييرا في دورة الحياة، بينما تعرّف نسخة الحزمة تطور ملفات التغليف. في تطبيق كتالوج افتراضي، قد تغلف الحزمة catalog ذات النسخة 0.4.0 التطبيق 2.7، ويكون الإصدار preview-catalog في المراجعة الثالثة لأن إعداداته تغيرت مرتين. لا يحل أي رقم محل الآخر. سجّل الهويات الثلاث في المراجعة كي تربط حادث التطبيق بالحزمة والمدخلات الفعلية.

تتبع حد التصيير

يجمع Helm القوالب والقيم وسياق التصيير لإنتاج manifests. ثم يفسر Kubernetes الكائنات المقدمة من خلال القبول والمتحكمات والجدولة وتشغيل الأحمال. هذه مراحل منفصلة تختلف أسباب فشلها. المخطط نموذج للمسؤوليات وليس إجراء نشر. إنتاج Service لا يثبت وجود Pods مطابقة، وإنتاج حقل كلمة مرور لا يثبت سريتها. يدرس هذا المسار سلوك Helm 3 وبيانات الحزمة v2 باستخدام ملفات افتراضية. لدى Helm 4 اعتبارات انتقال خاصة، ولذلك يمثل فرع التوثيق المختار افتراضا تعليميا صريحا لا وصفا للعميل المثبت عند القارئ.

text ثلاثة حدود للدليل

chart + values + render context -> manifests
submitted objects -> Kubernetes reconciliation
application requests -> user-visible behavior

يمكن مراجعة الحد الأول محليا؛ أما الحدان الآخران فيحتاجان دليلا مستقلا من بيئة مصرح بها.

اقرأ سجل إصدار افتراضي

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

python حقول هوية دون خدمات

record = {"release": "preview-catalog", "namespace": "lab",
          "chart": "catalog-0.4.0", "revision": 3}
print(record["chart"])
print(record["revision"])

الناتج المتوقع

catalog-0.4.0
3

يقرأ هذا المثال الكامل بيانات افتراضية في الذاكرة فقط؛ فلا يتصل بعنقود ولا يحاكي تشغيله.

حدد مسؤولية الحزمة

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

عرّف دليل الاكتمال

تعامل مع المراجعة كسلسلة من الادعاءات. قد تكون بنية الحزمة صحيحة ثم تنتج YAML غير صالح. وقد يتضمن YAML صالح واجهة API غير مدعومة. وقد تُقبل الكائنات وتظل غير متاحة، أو تكون Pods متاحة وتعيد نتائج خاطئة. سجّل إذن الادعاء المحدد الذي يدعمه كل فحص. تبقى جميع مقاطع Helm هنا غير قابلة للتشغيل ولا تُنفذ أوامر عنقود. تتحقق أمثلة Python الآمنة من حساباتها المعلنة وحدها. وأي مختبر مصرح به لاحقا يحتاج نطاقه وسياساته وخطة رجوعه وفحوص تجربة المستخدم؛ فلا يمنح التحقق المحلي ضمانات تشغيلية كهذه.

الأخطاء الشائعة وإصلاحها

الخلط بين نسخة الحزمة ومراجعة الإصدار

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

وصف الملفات الناتجة بأنها نشر يعمل

لماذا يحدث؟: فُسر تحويل محلي على أنه تحقق من التطبيق.
كيف تصلحه؟: احصر الادعاء في التصيير وخطط لفحوص مستقلة للقبول والسلوك.
كيف تتجنب تكراره؟: اربط كل نتيجة تحقق بحد الدليل الذي تغطيه.

افتراض رجوع خدمة بيانات خارجية مع الحزمة

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

اختبر فهمك

1. ثُبتت الحزمة catalog 0.4.0 مرتين بقيم مختلفة. هل يجب أن يتطابق الاسم أو رقم المراجعة؟

اعرض الحل المشروح

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

2. أثبتت مراجعة صحة YAML وصحة محددات Service. ما الادعاءات التي ما زالت مفتوحة؟