Helm وتغليف Kubernetes

استخدام الـ Charts

18 دقيقة الدرس 2 من 28

استخدام الـ Charts

الـ Chart في Helm هو حزمة — دليل يحتوي على قوالب YAML وقيم افتراضية وبيانات وصفية تصف وحدة واحدة قابلة للنشر على Kubernetes. عندما تُشغّل helm install، يقوم Helm بتصيير تلك القوالب مقابل القيم التي قدّمتها، ويرسل المانيفستات المُصيَّرة إلى واجهة برمجة Kubernetes، ويُسجّل النتيجة كـ Release. يتناول هذا الدرس كل أمر تحتاجه لتثبيت الـ Releases وترقيتها والتراجع عنها وفحصها بثقة في بيئة الإنتاج.

العمل مع المستودعات

قبل تثبيت أي Chart تحتاج إلى مصدر. يأتي Helm 3 بدون أي مستودعات افتراضية — تُضيفها يدويًا.

# أضف مستودع Bitnami (الأكثر استخدامًا في المستودعات العامة) helm repo add bitnami https://charts.bitnami.com/bitnami # حدّث الفهرس المحلي (شغّل هذا دائمًا قبل البحث أو التثبيت) helm repo update # اعرض المستودعات المضافة helm repo list # ابحث عن Chart بكلمة مفتاحية helm search repo redis # اعرض جميع الإصدارات المتاحة لـ Chart معين helm search repo bitnami/redis --versions
في شركات التقنية الكبرى، تُخزَّن الـ Charts الداخلية في سجلات OCI خاصة (Amazon ECR أو Google Artifact Registry أو Azure ACR أو Harbor). تسجّل الدخول عبر helm registry login <registry-host> ثم تُشير إلى الـ Chart على شكل oci://registry-host/path/chart-name بدلًا من helm repo add. OCI هو المعيار الحديث — تعلّمه مبكرًا.

helm install — أول Release لك

الصيغة الأساسية للتثبيت هي helm install <release-name> <chart>. يُسمّي Helm كل نسخة مُنشأة بـ Release، لذا يمكنك تثبيت الـ Chart نفسه عدة مرات بأسماء مختلفة (مثلًا redis-cache وredis-session).

# ثبّت Redis، اسم الـ Release = my-redis، في الـ Namespace الحالي helm install my-redis bitnami/redis # ثبّت في Namespace محدد (أنشئه إذا لم يكن موجودًا) helm install my-redis bitnami/redis \ --namespace data-layer \ --create-namespace # ثبّت إصدارًا محددًا (دائمًا حدّد الإصدار في الإنتاج!) helm install my-redis bitnami/redis --version 18.6.4 # تجريب جاف: صيّر المانيفستات وتحقق منها دون تطبيقها helm install my-redis bitnami/redis --dry-run --debug # اعرض YAML المُصيَّر دون التواصل مع الـ Cluster helm template my-redis bitnami/redis
لا تُثبّت أبدًا دون --version في الإنتاج. حذفه يعني تثبيت أحدث إصدار، وهو ما قد يتغير في أي وقت. حدّد إصدار الـ Chart وتتبّعه في Git — هذا ما يتطلبه GitOps.

تخصيص القيم

يأتي كل Chart مع ملف values.yaml يوثّق جميع الخيارات القابلة للتخصيص. تتجاوز القيم الافتراضية عبر ثلاث آليات مكمّلة، مرتّبة من الأدنى إلى الأعلى أولوية:

  1. --set key=value — سريع للسطر الواحد، مناسب لأسرار CI؛ ليس للهياكل المعقدة
  2. --values my-values.yaml (أو -f) — الأسلوب القياسي في الإنتاج؛ احتفظ بهذا الملف في Git
  3. عدة أعلام -f — تجاوزات طبقية (مثلًا base-values.yaml + prod-overrides.yaml)
# افحص جميع القيم المتاحة وافتراضياتها قبل التخصيص helm show values bitnami/redis --version 18.6.4 > redis-defaults.yaml # تجاوز قيمة واحدة مباشرة helm install my-redis bitnami/redis \ --set auth.password=supersecret \ --version 18.6.4 # التجاوز عبر ملف values (موصى به لكل ما يزيد عن مفتاح واحد) # my-redis-values.yaml # ------------------------------------------ # architecture: standalone # auth: # enabled: true # existingSecret: redis-secret # يُشير إلى K8s Secret مُنشأ مسبقًا # master: # persistence: # enabled: true # size: 20Gi # resources: # requests: # cpu: 250m # memory: 512Mi # limits: # cpu: 500m # memory: 1Gi # ------------------------------------------ helm install my-redis bitnami/redis \ -f my-redis-values.yaml \ --version 18.6.4 \ --namespace data-layer
استخدم helm show values (لا تكتفِ بقراءة README الـ Chart) لرؤية كل حقل قابل للتهيئة. تُتيح الـ Charts عشرات الخيارات التي لا توجد إلا في values.yaml.

الـ Releases — تتبّع ما نشرته

يُخزّن Helm كل Release على شكل Kubernetes Secret في الـ Namespace المستهدف (الـ Backend الافتراضي في Helm 3). كل تثبيت أو ترقية يزيد عدّاد الـ Revision.

# اعرض جميع الـ Releases في الـ Namespace الحالي helm list # اعرض عبر جميع الـ Namespaces helm list --all-namespaces # اعرض الحالة التفصيلية والمانيفست الأخير helm status my-redis # اعرض القيم المُستخدمة فعليًا للـ Release (النتيجة المدمجة) helm get values my-redis # اعرض YAML المُصيَّر الكامل الذي طُبّق على الـ Cluster helm get manifest my-redis # اعرض تاريخ الـ Release (جميع الـ Revisions) helm history my-redis

helm upgrade — تغيير Release نشطة

الترقية تُطبّق فرقًا — يحسب Helm الفرق بين مانيفستات الـ Release الحالية والمانيفستات الجديدة المُصيَّرة، ويُرسل فقط الكائنات المتغيرة إلى API Server.

# رقّ إلى إصدار أحدث من الـ Chart مع نفس ملف القيم helm upgrade my-redis bitnami/redis \ -f my-redis-values.yaml \ --version 18.7.0 \ --namespace data-layer # تثبيت أو ترقية في أمر واحد (المعيار في الإنتاج) helm upgrade --install my-redis bitnami/redis \ -f my-redis-values.yaml \ --version 18.7.0 \ --namespace data-layer \ --create-namespace # أضف --atomic: تراجع تلقائي إذا فشلت الترقية helm upgrade --install my-redis bitnami/redis \ -f my-redis-values.yaml \ --version 18.7.0 \ --namespace data-layer \ --atomic \ --timeout 5m
helm upgrade --install هو الأمر الاصطلاحي في CI/CD. يعمل كتثبيت في أول تشغيل وكترقية في التشغيلات اللاحقة، مما يجعل pipeline الخاص بك تصريحيًا وقابلًا لإعادة التشغيل دون أي منطق تفريعي. اقرنه بـ --atomic حتى يُشغّل التراجع تلقائيًا في حال فشل النشر.

مخطط دورة حياة الـ Helm Release

Helm release lifecycle: install, upgrade, rollback Chart Repo (bitnami / OCI) values.yaml (your overrides) Helm CLI install / upgrade Release Store (K8s Secrets, rev 1…N) Kubernetes API apply manifests Rollback re-apply rev N-1 chart values record apply prev rev re-apply
دورة حياة الـ Helm Release: تُدمج الـ Charts والقيم في سجل Release؛ تُضيف الترقيات Revision جديدة؛ يُعيد الـ Rollback تطبيق مانيفستات Revision سابقة.

helm rollback — التعافي من ترقية فاشلة

يُخزّن Helm كل مانيفست مُصيَّر لكل Revision. التراجع يُعيد تطبيق مانيفستات Revision سابقة على الـ Cluster — لا يُعيد قاعدة البيانات أو البيانات الحالة، بل فقط تعريفات كائنات Kubernetes.

# اعرض تاريخ الـ Revisions أولًا helm history my-redis --namespace data-layer # تراجع إلى الـ Revision السابق مباشرة helm rollback my-redis --namespace data-layer # تراجع إلى رقم Revision محدد helm rollback my-redis 3 --namespace data-layer # تحقق من نجاح التراجع helm status my-redis --namespace data-layer helm history my-redis --namespace data-layer # ملاحظة: الـ rollback يُنشئ Revision جديدًا (مثلًا rev 4 = نسخة من rev 3)
الـ Rollback يُعيد ضبط مانيفستات Kubernetes فقط. إذا نفّذت ترقيتك migration لقاعدة البيانات، فإن التراجع عن الـ Helm Release لن يعكس تلك التغييرات. نسّق مع فريق التطبيق واستخدم استراتيجية النشر الأزرق/الأخضر أو Canary للخدمات ذات الحالة، بحيث يظل مخطط قاعدة البيانات متوافقًا مع الإصدار السابق طوال فترة النشر.

إلغاء تثبيت Release

يحذف إلغاء الـ Release جميع كائنات Kubernetes المُصيَّرة وسجل الـ Release بشكل افتراضي.

# أزل الـ Release (يحذف كائنات K8s + سجل التاريخ) helm uninstall my-redis --namespace data-layer # احتفظ بسجل التاريخ (مفيد لأغراض التدقيق) helm uninstall my-redis --namespace data-layer --keep-history

أنماط الإنتاج بنظرة سريعة

  • حدّد إصدارات الـ Chart دائمًا في ملف القيم أو pipeline الـ CI — عامل إصدارات الـ Chart كإصدارات تبعيات البرنامج.
  • خزّن ملفات -f values.yaml في Git جنبًا إلى جنب مع كود التطبيق. ملف قيم واحد لكل بيئة (values-staging.yaml، values-prod.yaml).
  • استخدم --atomic في CI حتى يتراجع النشر الفاشل تلقائيًا ولا يترك Release في حالة منقوصة.
  • لا تستخدم --set للأسرار أبدًا. مرّر الأسرار عبر Kubernetes Secrets موجودة مسبقًا (يُنشئها Vault أو External Secrets Operator أو Sealed Secrets) وأشر إليها في ملف القيم.
  • شغّل helm diff upgrade (يتطلب إضافة helm-diff) في pipeline الـ CI لإظهار ما سيتغير قبل التطبيق — الأمر المكافئ لـ terraform plan في عالم Kubernetes.
الدرس السابق لماذا نحتاج إلى تعبئة تطبيقات Kubernetes؟
الدرس التالي تشريح الـ Chart
العودة للدورة