دليل سريع لتصميم الرسوم البيانية في هيلم

Unsplash بواسطة Frank Eiffert



Helm هي أداة قوية لتطبيق وتحديث وإدارة التطبيقات في Kubernetes. ينشئ مجتمع Helm العديد من الرسوم البيانية مفتوحة المصدر. يمكنك نشر مشغل Redis أو Nginx أو Prometheus باستخدام أمر واحد. وهم يأتون بكل ما تحتاجه ، مثل Ingress.



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

إنشاء هيكل مخطط أساسي

ابدأ بأمر بسيط سينشئ نموذجًا لهيكل الرسم البياني:

$ helm create basic
Creating basic
$ tree basic
basic/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

هذا كل ما يتطلبه الأمر لإنشاء مخطط جاهز للتشغيل. يسمح لك هذا المخطط بنشر تطبيق بكل المكونات الضرورية. إذا ألقيت نظرة على القيم yaml ، يمكنك أن ترى أن هذا التطبيق سينشر Nginx.



يعد توسيع المخطط أمرًا سهلاً مثل إنشاء:

$ helm install basic

فريق القوالب هو أفضل صديق لك

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



للتحقق مما سيتم نشره بالضبط في الكتلة ، استخدم الأمر:

$ helm template basic

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

$ helm template basic -x templates/service.yaml

ستكون النتيجة شيء من هذا القبيل:

---
# Source: basic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-basic
  labels:
    app.kubernetes.io/name: basic
    helm.sh/chart: basic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: basic
    app.kubernetes.io/instance: release-name

لاختبار قالب بقيم مخصصة ، استخدم:

$ helm template basic -x templates/service.yaml -f \ mypath/tocustomvalues.yaml

يمكن اختبار القالب الذي تم إنشاؤه على الكتلة باستخدام الأمر:

$ helm install basic --dry-run --debug

لينت!

قبل التقديم إلى المستودع ، يمكنك إضافة خطوة أخرى للتحقق بوضوح من الرمز - الفحص (التحليل الإحصائي):

$ helm lint basic/
==> Linting basic/
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures

يعمل هيلم مع الوظائف

إذا نظرت في دليل قوالب المخططات ، يمكنك رؤية _helpers.tpl. هنا يمكنك إضافة وظائفك ، وسوف تكون متاحة في جميع أنحاء الرسم البياني. قد تبدو دالة المثال كما يلي:

{{/*
Expand the name of the chart.
*/}}
{{- define "basic.name" -}} 
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} 
{{- end -}}

يُشار إلى استخدام وظيفة في قالب باستخدام وظيفة include:

app.kubernetes.io/name: {{ include "basic.name" . }}

تسميات ميتا

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

{{/*
Common labels
*/}}
{{- define "basic.labels" -}} 
app.kubernetes.io/name: {{ include "basic.name" . }}
helm.sh/chart: {{ include "basic.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

والآن أصبح من السهل إضافة بعض العلامات إلى الرسم البياني:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "basic.fullname" . }}
  labels:
{{ include "basic.labels" . | indent 4 }}
...

إذا كنت تريد العثور على الخدمات التي تم إنشاؤها باستخدام هذا المخطط ، فاستخدم الأمر:

$ kubectl get svc -l helm.sh/chart=basic-0.1.0

التعليقات ستوفر لك

هناك نوعان من التعليقات:

• # هو تعليق بسيط يبقى في YML الناتج بعد المعالجة.
• {{- / * ... * / -}} هو تعليق تم تجاهله بواسطة محرك النموذج.

# app files volume
        {{- /*
          App files are configmaps created by cloud-app-play-files chart.
          App files contains files specific for app and environment.
          App name should be same as in deployment of cloud-app-play-files chart.
        */ -}} 
        {{- if .Values.include.appDir }}
        - name: {{ $appName }}-files
          configMap:
            name: {{ $appName }}-files

سيكون إخراج النموذج كما يلي:

       # app files volume
       - name: app-notification-files
         configMap:
           name: app-notification-files

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



من المهم أيضًا تذكر أن التعليقات التي تبدأ بـ # يتم تحليلها أيضًا. إذا وضعت نموذج Go في تعليق ، فسيتم تقييمه. لذلك يمكن أن تكون التعليقات قوالب أيضًا.

تأكد من الاحتفاظ بالوثائق

توثيق المخططات أمر لا غنى عنه ، خاصة إذا كنت ترغب في نشر مخطط. أسهل طريقة لإنشاء المستندات والاحتفاظ بها هي استخدام حزمة Golang المسماة helm-docs . باستخدامه يمكنك إنشاء README.md يحتوي على جداول القيم والإصدارات والأوصاف من القيم. yaml و chart.yaml ، أو استخدام ملفات مخصصة أخرى.





^{مثال مأخوذ من https://github.com/norwoodj/helm-docs}



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

$ helm-docs
INFO[2020-07-23T15:30:38+02:00] Found Chart directories [.]                 
INFO[2020-07-23T15:30:38+02:00] Generating README Documentation for chart .

سحر المخططات الفرعية

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



يتم نشر المخططات الفرعية في نفس وقت الرسم البياني الرئيسي. يمكن توفير قيم المخططات الفرعية في نفس ملف القيم. yaml كما هو الحال في المخطط الرئيسي. يمكنك أيضًا توصيلهم من GitHub ، ولكن بالنسبة للمقال سأقوم بإنشاء مخطط فرعي محليًا.



لبدء استخدام مخطط فرعي جديد يعتمد عليه المخطط الرئيسي ، قم بإنشاء دليل مخططات داخل مجلد المخطط الرئيسي. ثم قم بإنشاء مخطط أساسي:

$ mkdir charts
$ cd charts
$ helm create subbasic

لتوصيل مخطط فرعي ، قم بتغيير تعريف المخطط الرئيسي:

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: basic
version: 0.1.0
dependencies:
  - name: subbasic       

الآن ، في كل مرة يتم فيها تشغيل الأمر helm install، لا يتم توسيع المخطط الرئيسي فحسب ، بل يتم أيضًا توسيع المخطط الفرعي. لتجاوز اسم مرجع المخطط الفرعي عند النشر في الخدمة ، أضف الأوامر التالية إلى القيم. yaml في المخطط الرئيسي:

subbasic:
 service:
   type: NodePort
 nameOverride: "jojo"

قم الآن بتشغيل الأمر templateوشاهد الإخراج المعدل لخدمة المخطط الفرعي. سيتغير نوع الخدمة مع الاسم:

---
# Source: basic/charts/subbasic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-jojo
  labels:
    app.kubernetes.io/name: jojo
    helm.sh/chart: subbasic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: jojo
    app.kubernetes.io/instance: release-name

ملاحظة مهمة: لا يمكن للمخططات الفرعية قبول القيم من المخططات الأصلية.

اللحظات التي غالبًا ما تُنسى

بضع نقاط أخرى:

1. أسماء الموارد - 63 حرفًا كحد أقصى.
2. يمكن أن تكون أسماء الموارد أرقامًا أو أحرفًا صغيرة فقط أو "-" أو ".".
3. حجم الرسم البياني - لا يزيد عن 1 ميغا بايت . هذا مهم بشكل خاص إذا كنت تستخدم مرفقات الملفات.
4. يحتوي المخطط على وظيفة التحليل .tpl.
5. يمكنك تحديد الموارد التي ستبقى بعد قيام الأمر بإزالة نشر المخطط helm delete.

حسنا هذا كل شيء!

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



Helm هي أداة صغيرة إلى حد ما ، ولكن لديها الكثير من الإمكانات. لا تنسَ أن الفحص ، وإنشاء الوثائق ، وحتى قوالب التشغيل الجاف على مجموعة يمكن أن تكون جزءًا من CI. Helm Workflow متاح بالفعل لـ GitHub .



حظا سعيدا!



ماذا تقرأ:

1. جهاز خوذة ومزالقها .
2. التوليد التلقائي للأسرار في هيلم .
3. قناتنا حول Kubernetes في Telegram .