Helm وتغليف Kubernetes

نشر وإصدار Charts في Helm

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

نشر وإصدار Charts في Helm

الـ Chart الذي يعيش فقط على حاسوبك المحلي ما هو إلا مكتبة قوالب. أما الـ Chart المنشور في سجلّ (Registry)، فهو أداة إصدار موثّقة يمكن لمنظّمتك بأكملها — ولخطوط CI/CD ومتحكّمات GitOps والمهندسين في الساعة الثالثة صباحاً — أن تسحبها وتتحقّق منها وتنشرها بأمر واحد. يتناول هذا الدرس كل شيء بدءاً من بروتوكول مستودع الـ Charts عبر HTTP الكلاسيكي، مروراً بسجلات OCI الحديثة، وانتهاءً بضبط الإصدارات الدلالية والمصادقة التشفيرية التي تُرضي المراجعين.

نموذجا التوزيع: مستودعات HTTP مقابل سجلات OCI

يدعم Helm آليتَين مختلفتَين جوهرياً لتوزيع الـ Charts.

مستودعات HTTP الكلاسيكية تتبع عقداً بسيطاً: يستضيف خادم HTTP دليلاً يحتوي على أرشيفات .tgz وملف index.yaml يُدرج فيه كل Chart مع إصداره وبصمته ورابط تحميله. أي خادم ملفات ثابتة — S3 أو GCS أو GitHub Pages أو Nginx — يمكنه العمل كمستودع Helm. تتفاعل معه عبر helm repo add وhelm repo update وhelm search repo.

سجلات OCI (أُدرجت كميزة مستقرة في Helm 3.8 في فبراير 2022) تخزّن الـ Charts كـ OCI artifacts إلى جانب صور الحاويات في نفس بنية السجل. تدعم كل من ECR وGCR وACR وHarbor وDocker Hub هذه الصيغة. بدلاً من helm repo add، تستخدم helm push وhelm pull oci://. لا حاجة لـ index.yaml — السجلّ نفسه يتولّى الاكتشاف والبيانات الوصفية.

اتجاه الصناعة: لجأت Google وAWS وMicrosoft إلى توحيد سجلات OCI كآلية التوزيع المفضّلة لـ Helm. إن كنت تبدأ مستودع Charts جديداً اليوم، استخدم OCI. تبقى مستودعات HTTP شائعة في المنظومة مفتوحة المصدر (ArtifactHub وBitnami)، لكن الأدوات الداخلية الجديدة في كبرى الشركات التقنية تعتمد بصورة رئيسية على OCI.
HTTP Repo vs OCI Registry distribution flows HTTP Chart Repository helm package myapp-1.2.0.tgz S3 / GCS index.yaml + .tgz رفع helm repo add helm install سحب OCI Registry helm package myapp-1.2.0.tgz ECR / GCR / ACR OCI artifact layer helm push helm pull oci:// helm install oci:// سحب
يساراً: سير عمل مستودع HTTP — تعبئة، رفع، تسجيل، تثبيت. يميناً: سير عمل OCI — تعبئة، دفع مباشر، تثبيت عبر URI بصيغة oci://.

الإصدارات الدلالية للـ Charts

يحمل كل Helm Chart نصَّين مستقلَّين للإصدار في Chart.yaml:

  • version — إصدار الـ Chart بصيغة semver. ارفعه عند تغيّر القوالب أو مخطط القيم أو الإعدادات الافتراضية.
  • appVersion — إصدار التطبيق الذي ينشره الـ Chart (مثلاً وسم صورة Docker). تغيير appVersion دون تغيير version خطأ شائع يحول دون التراجع الفعّال.

الانضباط الصارم في semver أمر لا مساومة فيه في الإنتاج:

  • PATCH (1.2.3 → 1.2.4) — إصلاح خطأ في القوالب، تحديث توثيق، تغيير افتراضي غير كاسر.
  • MINOR (1.2.3 → 1.3.0) — إضافة قيمة اختيارية جديدة، ميزة قالب جديدة، تغيير متوافق مع الإصدارات السابقة.
  • MAJOR (1.2.3 → 2.0.0) — تغيير كاسر: إعادة تسمية مفاتيح القيم، حذف مخرجات القوالب، تغيير أنواع الحقول الإلزامية. رفع MAJOR إشارة للمستهلكين: ملفات values.yaml الخاصة بك قد لا تعمل.
فخ إنتاجي — appVersion المجمّد: تحدّث إحدى الفرق وسم صورة Docker في خط النشر بتمرير --set image.tag=v2.3.1 عند الترقية لكنها لا تحدّث أبداً appVersion أو version في Chart.yaml. بعد ستة أشهر، يُظهر helm list الإصدار 1.0.0 في كل بيئة، مما يجعل ربط حالة الكلاستر بـ Git commit أمراً مستحيلاً. تعامل دائماً مع appVersion وversion كجزء من أداة الإصدار — وأتمتة تحديثهما في CI.
# Chart.yaml — حقلا إصدار مستقلان apiVersion: v2 name: myapp description: Production-grade microservice chart type: application version: 1.4.2 # إصدار الـ Chart — ارفعه عند تغيير القوالب/القيم appVersion: "2.3.1" # إصدار التطبيق — يطابق وسم صورة Docker # في CI، أتمتة رفع الإصدار باستخدام yq (معالج YAML) # رفع إصدار الـ Chart (minor) ومزامنة appVersion مع وسم الصورة: IMAGE_TAG="$(git rev-parse --short HEAD)" yq e ".appVersion = \"${IMAGE_TAG}\"" -i charts/myapp/Chart.yaml yq e ".version = \"$(semver bump minor $(yq e .version charts/myapp/Chart.yaml))\"" \ -i charts/myapp/Chart.yaml

النشر إلى مستودع HTTP (نمط S3)

نمط S3 مع helm repo index معتمد وموثوق للمستودعات الداخلية. سير العمل هو: تعبئة الـ Chart، إعادة توليد الفهرس، والمزامنة مع S3. يؤتمت الإضافة helm-s3 هذا السير.

# الإعداد لمرة واحدة: تثبيت إضافة helm-s3 وتهيئة الـ bucket helm plugin install https://github.com/hypnoglow/helm-s3.git helm s3 init s3://my-company-charts/charts # إضافة المستودع محلياً (مرة واحدة لكل آلة مطوّر / عداء CI) helm repo add company s3://my-company-charts/charts # تعبئة Chart ودفعه helm package charts/myapp --destination /tmp/ helm s3 push /tmp/myapp-1.4.2.tgz company # التحقق helm repo update helm search repo company/myapp --versions # NAME CHART VERSION APP VERSION DESCRIPTION # company/myapp 1.4.2 2.3.1 Production-grade microservice chart # company/myapp 1.4.1 2.2.8 ... # تثبيت إصدار محدد (التثبيت على إصدار بعينه إلزامي في الإنتاج) helm upgrade --install myapp company/myapp \ --version 1.4.2 \ --values prod-values.yaml \ --namespace myapp \ --atomic

النشر إلى سجل OCI (نمط ECR)

AWS ECR هو سجل OCI للـ Charts الأكثر انتشاراً في البيئات المؤسسية. سير العمل يشبه دفع صور الحاويات — مصادقة، تعبئة، دفع عبر URI.

# مصادقة Helm مع ECR (تُشغَّل قبل كل دفع في CI) AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) AWS_REGION=us-east-1 aws ecr get-login-password --region ${AWS_REGION} \ | helm registry login \ --username AWS \ --password-stdin \ ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com # إنشاء مستودع ECR للـ Chart (مرة واحدة) aws ecr create-repository \ --repository-name helm-charts/myapp \ --region ${AWS_REGION} # تعبئة ودفع helm package charts/myapp helm push myapp-1.4.2.tgz \ oci://${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/helm-charts # التثبيت مباشرة من OCI (لا حاجة لـ helm repo add) helm upgrade --install myapp \ oci://${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/helm-charts/myapp \ --version 1.4.2 \ --values prod-values.yaml \ --namespace myapp \ --atomic # فحص بيانات الـ Chart دون تثبيت helm show chart \ oci://${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/helm-charts/myapp \ --version 1.4.2
اللاتغيّر ميزة وليس قيداً: اضبط سجل OCI (أو حاوية S3) لجعل إصدارات الـ Charts المنشورة غير قابلة للتعديل — بمجرد دفع myapp:1.4.2 لا يمكن الكتابة فوقه. هذا يوازي أفضل ممارسات صور Docker. إن اكتُشف خطأ، يذهب الإصلاح إلى 1.4.3، لا إلى كتابة صامتة فوق 1.4.2. يدعم ECR ثبات وسوم الصور على مستوى المستودع؛ فعّله بـ --image-tag-mutability IMMUTABLE في أمر create-repository أعلاه.

مصادقة الـ Chart والتوقيع الرقمي

للصناعات الخاضعة للرقابة (التمويل والرعاية الصحية والحكومة) ولكل منظمة مهتمة بسلسلة التوريد، لا تكفي بصمة SHA للـ Chart — أنت بحاجة إلى توقيع تشفيري يُثبت أن الـ Chart صادر من مؤلّف موثوق ولم يُعبَث به أثناء النقل. يدعم Helm التوقيع عبر ملفات مصادقة GPG.

حين تشغّل helm package --sign، ينشئ Helm ملف .prov إلى جانب .tgz. يحتوي ملف المصادقة على SHA-256 لأرشيف الـ Chart وكتلة PGP-clearsigned. يشغّل المستهلكون helm verify أو يمرّرون --verify إلى helm install للتحقق من التوقيع قبل أي نشر.

# توليد مفتاح GPG لتوقيع الـ Charts (مرة واحدة لكل منظمة/فريق) gpg --full-generate-key # اختر: RSA 4096، بلا انتهاء صلاحية (أو صلاحية طويلة)، الاسم = "Helm Charts CI" # تصدير المفتاح العام وتوزيعه على المستهلكين (عبر خادم المفاتيح أو PKI الداخلي) gpg --export --armor "Helm Charts CI" > helm-signing-pub.asc # تعبئة وتوقيع في CI helm package charts/myapp \ --sign \ --key "Helm Charts CI" \ --keyring ~/.gnupg/pubring.gpg \ --destination /tmp/ # ينشئ هذا ملفَّين: # /tmp/myapp-1.4.2.tgz # /tmp/myapp-1.4.2.tgz.prov # دفع الملفَّين إلى مستودع الـ Chart helm s3 push /tmp/myapp-1.4.2.tgz company helm s3 push /tmp/myapp-1.4.2.tgz.prov company # يثبّت المستهلكون مع التحقق من التوقيع helm install myapp company/myapp \ --version 1.4.2 \ --verify \ --keyring /etc/helm/helm-signing-pub.gpg
Sigstore / Cosign لـ Charts بصيغة OCI: يعمل توقيع GPG مع مستودعات HTTP فقط. للسجلات OCI، المعيار الناشئ هو Cosign (من مشروع Sigstore، بدعم من Google وRed Hat وChainguard). يستطيع Cosign توقيع OCI artifacts (بما في ذلك Helm Charts المدفوعة كطبقات OCI) بتوقيعات OIDC بلا مفاتيح مرتبطة بهوية CI بدلاً من مفتاح GPG طويل الأمد. هذا هو النموذج الذي تستخدمه المشاريع مفتوحة المصدر الكبرى (Kubernetes وcert-manager) اليوم. تدعم كل من Flux وArgoCD التحقق عبر Cosign من مصادر Charts بصيغة OCI.

التكامل مع CI/CD: أتمتة خط النشر الكامل

يربط سير عمل GitHub Actions التالي كل ما سبق معاً: رفع الإصدار، التعبئة، الدفع إلى ECR، والتوقيع الاختياري — يُشغَّل عند كل دفع إلى الفرع main حين يتغيّر مجلد charts/.

# .github/workflows/helm-publish.yml name: Publish Helm Chart on: push: branches: [main] paths: ["charts/**"] env: AWS_REGION: us-east-1 ECR_REGISTRY: ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com jobs: publish: runs-on: ubuntu-latest permissions: id-token: write # مطلوب لمصادقة OIDC مع AWS contents: read steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # السجل الكامل لاكتشاف الإصدار - name: Configure AWS credentials (OIDC — no stored secrets) uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }} aws-region: ${{ env.AWS_REGION }} - name: Install Helm uses: azure/setup-helm@v4 with: version: "3.15.x" - name: Authenticate Helm to ECR run: | aws ecr get-login-password --region ${{ env.AWS_REGION }} \ | helm registry login \ --username AWS \ --password-stdin \ ${{ env.ECR_REGISTRY }} - name: Detect changed charts and publish run: | set -euo pipefail CHANGED=$(git diff --name-only HEAD~1 HEAD -- charts/ \ | awk -F/ '{print $2}' | sort -u) for CHART in $CHANGED; do echo "=== Publishing charts/${CHART} ===" helm dependency update charts/${CHART} helm package charts/${CHART} --destination /tmp/charts/ TARBALL=$(ls /tmp/charts/${CHART}-*.tgz | tail -1) helm push ${TARBALL} \ oci://${{ env.ECR_REGISTRY }}/helm-charts done
Chart Releaser للمشاريع مفتوحة المصدر: إن كنت تدير مستودع Charts عاماً على GitHub Pages، تؤتمت أداة chart-releaser (helm/chart-releaser-action) عمليات التعبئة وإنشاء GitHub Releases وتحديث index.yaml. هي الإعداد المعياري لمستودعات Charts المجتمعية وتستخدمها مشروع Helm نفسه.

قيود إصدارات التبعيات

حين يعتمد الـ Chart على مكتبات subchart (تُغطّى في الدرس السادس)، يثبّت ملف Chart.lock الإصدارات الدقيقة لكل تبعية. تعامل مع Chart.lock كما تتعامل مع package-lock.json — اودعه في Git، وشغّل helm dependency update فقط حين ترغب عمداً في ترقية تبعية. لا تحذف Chart.lock في CI وتتركه يُعيد التحليل بحرية؛ هذا هو الطريق لنشر إصدار تبعية مختلف في الإنتاج عن الاختبار.

بنهاية هذا الدرس تمتلك الأدوات اللازمة لردم الفجوة بين "Chart على القرص" و"أداة إصدار موثّقة وموقَّعة وقابلة للمراجعة متاحة لمنظّمتك بأكملها". يتناول الدرس التالي Helm Hooks واختبارات الـ Charts — الآليات التي تُمكّنك من التحقق من عمليات النشر وتشغيل ترحيلات قاعدة البيانات بصورة ذرية ضمن الإصدار.