إدارة إصدار Helm

مكتمل

كيفية استخدام الدالات في قالب Helm

تحدد لغة القالب Helm functions التي تستخدمها لتحويل القيم من values.yamlالملف. يتبع بناء جملة دالة بنية {{ functionName arg1 arg2 ... }} . دعونا ننظر إلى الدالة quote كمثال لرؤية بناء الجملة هذا قيد الاستخدام.

تقوم quote الدالة بتضمين قيمة بعلامات اقتباس للإشارة إلى استخدام string. لنفترض أنك قمت بتعريف الملف التالي values.yaml :

apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
  enabled: true

قررت أنك تريد استخدام ingress.enabled القيمة كقيمة منطقية عند تحديد ما إذا كان يجب إنشاء بيان دخول. لاستخدام enabled القيمة كقيمة منطقية، يمكنك الرجوع إلى القيمة باستخدام {{ .Values.ingress.enabled }}.

لاحقا، قررت عرض الحقل كسلسلة في templates/Notes.txt الملف. نظرا لأن قواعد الإكراه من نوع YAML يمكن أن تؤدي إلى أخطاء يصعب العثور عليها في القوالب، فإنك تقرر اتباع الإرشادات وأن تكون صريحا عند تضمين السلاسل في القوالب. على سبيل المثال، enabled: false لا يساوي enabled: "false".

لعرض القيمة كسلسلة، يمكنك استخدام {{ quote .Values.ingress.enabled }} للإشارة إلى القيمة المنطقية كسلسلة.

كيفية استخدام البنية الأساسية لبرنامج ربط العمليات التجارية في قالب Helm

يمكنك استخدام البنية الأساسية لبرنامج ربط العمليات التجارية عندما تحتاج أكثر من دالة واحدة إلى العمل على قيمة. يسمح لك المسار بإرسال قيمة أو نتيجة دالة إلى دالة أخرى. على سبيل المثال، يمكنك إعادة كتابة الدالة أعلاه quote ك {{ .Values.ingress.enabled | quote }}. لاحظ كيف يشير | إلى أن يتم إرسال القيمة إلى quoteالدالة.

إليك مثالاً آخر. لنفترض أنك تريد تحويل قيمة إلى أحرف كبيرة والتفافها في علامات الاقتباس. يمكنك كتابة العبارة ك {{ .Values.ingress.enabled | upper | quote }}. لاحظ كيفية معالجة القيمة بواسطة الدالة upper ثم الدالة quote .

تتضمن لغة القالب أكثر من 60 دالة تسمح لك بكشف القيم والكائنات والبحث فيها وتحويلها في القوالب.

كيفية استخدام التحكم في التدفق الشرطي في قالب Helm

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

if / else الكتلة هي مثل بنية تدفق عنصر التحكم وتتوافق مع التخطيط التالي:

{{ if | pipeline | }}
  # Do something
{{ else if | other pipeline | }}
  # Do something else
{{ else }}
  # Default case
{{ end }}

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

{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{ end }}

تذكر أنه يمكنك استخدام العناصر النائبة لتعبئة بيانات التعريف في القالب. يتم تحليل ملفات القالب وتقييمها بشكل تسلسلي بواسطة لغة القالب من أعلى إلى أسفل. في المثال السابق، ينشئ محرك القالب محتويات ملف البيان فقط إذا كانت .Values.ingress.enabled القيمة هي true.

عندما يعالج محرك القالب العبارة، فإنه يزيل المحتوى المعلن داخل بناء الجملة {{ }} ويترك المسافة البيضاء المتبقية. يؤدي بناء الجملة هذا إلى تضمين مشغل القالب سطرا جديدا لخط العبارة if . إذا تركت محتويات الملف السابق كما هي، فستلاحظ خطوطا فارغة في YAML، ويتم إنشاء ملف بيان الدخول.

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

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{- end }}

لاحظ استخدام - الحرف كجزء من تسلسل البداية {{- والنهاية -}} من العبارة. يوجه - الحرف المحلل لإزالة أحرف المسافة البيضاء. {{- يزيل المسافة البيضاء في بداية السطر وفي -}} نهاية السطر، بما في ذلك حرف السطر الجديد.

كيفية التكرار من خلال مجموعة من القيم في قالب Helm

يسمح لك YAML بتحديد مجموعات العناصر واستخدام العناصر الفردية كقيم في قوالبك. يمكن الوصول إلى العناصر في مجموعة باستخدام مفهرس. ومع ذلك، تدعم لغة قالب Helm تكرار مجموعة من القيم باستخدام range عامل التشغيل .

لنفترض أنك تحدد قائمة بالقيم في ملفك values.yaml للإشارة إلى مضيفي دخول إضافيين. فيما يلي مثال على القيم:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

يمكنك استخدام عامل تشغيل النطاق للسماح لمحرك القالب بالتكرار من خلال .Values.ingress.extraHosts. يظهر مقتطف التعليمات البرمجية التالي مثالا مكثفا باستخدام range عامل التشغيل:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  ...
spec:
  rules:
    ...
    {{- range .Values.ingress.extraHosts }}
    - host: {{ .name }}
      http:
        paths:
          - path: {{ .path }}
            ...
    {{- end }}
  ...
{{- end }}

كيفية التحكم في نطاق القيم في قالب Helm

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

تذكر أن . المستخدم في قالب Helm يشير إلى النطاق الحالي. على سبيل المثال، يرشد .Values محرك القالب للعثور على كائن القيم في النطاق الحالي. لنفترض أنك تستخدم values.yaml الملف من وقت سابق لإنشاء ملف بيان خريطة تكوين:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

بدلا من الوصول إلى قيمة مسار كل عنصر باستخدام {{ .Values.ingress.extraHosts.path }}، يمكنك استخدام with الإجراء . يظهر مقتطف التعليمات البرمجية التالي مثالا باستخدام range عامل التشغيل لإنشاء ملف بيان خريطة تكوين:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  {{ end }}

يحد {{- with .Values.ingress.extraHosts }} نطاق القيم من .Values.ingress.extraHosts الصفيف.

يقيد with الإجراء النطاق. لا يمكنك الوصول إلى كائنات أخرى من النطاق الأصل. لنفترض أنك تريد أيضا الوصول إلى {{ .Release.Name }} المخطط في كتلة التعليمات البرمجية with . للوصول إلى الكائنات الأصل، تحتاج إلى الإشارة إلى نطاق الجذر باستخدام $ الحرف أو إعادة كتابة التعليمات البرمجية الخاصة بك. إليك التعليمات البرمجية المحدثة لإظهار كيفية تضمين العناصر الأصل باستخدام $ الحرف :

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  release: {{ $.Release.Name}}
  {{ end }}

إشعار

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

كيفية تعريف Helm لتبعيات المخطط

يسمح المخطط لإعلان التبعيات لدعم التطبيق الرئيسي ويشكل جزءًا من الإصدار المثبت.

A diagram shows how Helm deploys all subcharts as dependencies of the main chart to a Kubernetes cluster.

يمكنك إما إنشاء مخطط فرعي باستخدام helm create الأمر ، أو تحديد موقع المخطط الجديد في /charts المجلد ، أو استخدام helm dependency الأمر . تذكر أن /charts المجلد قد يحتوي على مخططات فرعية تم نشرها كجزء من إصدار المخطط الرئيسي.

helm dependency يسمح لك الأمر بإدارة التبعيات المضمنة من مستودع Helm. يستخدم الأمر بيانات التعريف المعرفة في dependencies قسم من ملف قيم المخطط. يمكنك تحديد الاسم ورقم الإصدار والمستودع الذي تريد تثبيت المخطط الفرعي منه. فيما يلي استخراج لملف values.yaml يحتوي على مخطط MongoDB مدرج كتبعية:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
  - name: mongodb
    version: 10.27.2
    repository: https://marketplace.azurecr.io/helm/v1/repo

بمجرد تعريف بيانات تعريف التبعية، يمكنك تشغيل helm dependency build الأمر لجلب المخطط المحزم بالطرب. يقوم أمر إنشاء المخطط بتنزيل المخطط في charts/ المجلد.

helm dependency build ./app-chart

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

helm dependency update ./app-chart

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

كيفية ترقية إصدار Helm

يسمح Helm بترقية الإصدارات الموجودة كدلتا لكل التغييرات التي تنطبق على المخطط وتبعياته.

A diagram shows how the Helm upgrade command creates a delta of all changed items in a Helm chart to upgrade a release and create a new release revision on a Kubernetes cluster.

على سبيل المثال، لنفترض أن فريق التطوير للمثال webapp في هذه الوحدة يقوم بإجراء تغييرات التعليمات البرمجية التي تؤثر فقط على وظائف موقع الويب. يقوم الفريق بإجراء التحديثات التالية على Chart.yaml الملف لتعكس الإصدار الجديد من التطبيق:

  • التحديثات صورة حاوية تطبيق الويب وعلامات الصورة كما هو الحال webapp: linux-v2 عند دفع الصورة إلى سجل الحاوية.
  • dockerTag التحديثات القيمة إلى linux-v2 وقيمة إصدار المخطط في 0.2.0 ملف قيم المخطط.

فيما يلي مثال على الملف المحدث values.yaml :

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes

type: application

version: 0.2.0
appVersion: 1.0.0

registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"

بدلا من إلغاء تثبيت إصدار حالي، يمكنك استخدام helm upgrade الأمر لترقية إصدار Helm الموجود.

helm upgrade my-app ./app-chart

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

بمجرد اكتمال الترقية، يمكنك مراجعة محفوظات نشر الإصدار باستخدام helm history الأمر باسم الإصدار.

helm history my-app

يرجع أمر المحفوظات عدة حقول تصف الإصدار، كما هو موضح في إخراج المثال التالي:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        deployed        aspnet-core-1.3.18      3.1.19          Install complete

لاحظ الحقل في revision النتيجة. يتعقب Helm معلومات الإصدار من كل الإصدارات التي تم تنفيذها لمخطط Helm. عند تثبيت إصدار جديد من مخطط Helm، يزيد عدد المراجعة بمقدار واحد، وتتم مطابقة معلومات الإصدار الجديد مع تلك المراجعة.

فيما يلي مثال على تشغيل نفس أمر المحفوظات بعد تثبيت إصدار جديد من تطبيق الويب:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

كيفية العودة إلى الحالة السابقة لإصدار Helm

يسمح Helm بالعودة إلى الحالة السابقة لإصدار Helm الموجود بالإصدار الذي تم تثبيته مسبقًا. تذكر من وقت سابق أن Helm يتعقب معلومات الإصدار لجميع إصدارات مخطط Helm.

يمكنك استخدام helm rollback الأمر للعودة إلى مراجعة إصدار Helm محددة. يستخدم هذا الأمر معلمتين. تحدد المعلمة الأولى اسم الإصدار، وتحدد الثانية عدد مراجعة الإصدار.

helm rollback my-app 2

يعيد helm rollback الأمر إصدار إصدار التطبيق إلى المراجعة المحددة ويحدث محفوظات إصدار التطبيق. يظهر تشغيل helm history متابعة الأمر أحدث رقم مراجعة نشط كإصدار أحدث إدخال.

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

helm rollback my-app 1

بمجرد اكتمال العودة إلى الحالة السابقة، يمكنك مراجعة محفوظات النشر باستخدام helm history الأمر .

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        superseded      aspnet-core-1.3.18      3.1.19          Rolled back to 1
3               Mon Oct 11 17:38:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

لاحظ كيفية عرض حقل الوصف لعدد مراجعة العودة إلى الحالة السابقة لتسهيل تعقب التغييرات.

‏‫اختبر معلوماتك

1.

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

2.

لنفترض أن لديك حل برامج يحتوي على موقع ويب كأحد مكوناته الهامة. موقع الويب هو المكون الوحيد الذي يعتمد على خدمة التخزين المؤقت. ما الاستراتيجية التي تناسب توزيع هذين التطبيقين باستخدام Helm على أفضل نحو؟