Erste Schritte mit Helm Chart

Installieren und Konfigurieren von Helm 3
Magnolien Helmkarte
Bereitstellen eines Helm-Diagramms auf dem Cluster
Nächste Schritte

Starten Sie mit Magnolia

Unser Expertenteam zeigt Ihnen gerne, was Magnolia kann.

Kubernetes entwickelt sich zum Standard-Orchestrierungssystem für die automatische Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Bei der Arbeit mit Kubernetes ist es wahrscheinlich, dass Sie Objekte wie Deployments, Volumes, Services und Config-Maps während des Lebenszyklus einer Anwendung viele Male einsetzen. Helm ist ein Tool zur Standardisierung der Bereitstellung von Anwendungen und deren Paketierung und bietet gleichzeitig Flexibilität und Konfigurierbarkeit.

In meinem vorherigen Artikel "Aufbau einer Continuous-Delivery-Pipeline mit GitHub und Helm zum Deployment von Magnolia in Kubernetes" haben wir uns mit dem Deployment einer containerisierten Magnolia-Anwendung in einem Kubernetes-Cluster (K8S) beschäftigt. In diesem Artikel gehen wir näher auf Helm ein.

Helm beschreibt sich selbst als "Anwendungspaketmanager für Kubernetes", aber es kann so viel mehr, als diese Beschreibung vermuten lässt: Helm verwaltet Anwendungen, die in einem Kubernetes-Cluster laufen, und koordiniert deren Download, Installation, Bereitstellung, Aktualisierung und Löschung.

In der Welt von Helm definieren Helm-Diagramme Anwendungen als eine Sammlung von Kubernetes-Ressourcen mithilfe von YAML-Konfigurationsdateien und Vorlagen. Ein Diagramm besteht jedoch nicht nur aus Metadaten, die die Anwendung beschreiben, sondern verwaltet auch die Infrastruktur für den Betrieb der Anwendung in Übereinstimmung mit den Kubernetes-Primitiven.

Sobald eine Instanz eines Diagramms im Cluster installiert ist, wird sie als "Release" bezeichnet. Ein Diagramm kann mehrmals im selben Cluster installiert werden. Jedes Mal, wenn es installiert wird, wird eine neue Version erstellt.

Installieren und Konfigurieren von Helm 3

Um Helm v3.x zu installieren, führen Sie die folgenden Befehle aus:

  $ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 > get_helm.sh $ chmod 700 get_helm.sh $ ./get_helm.sh

Um zu sehen, was Helm kann, führen Sie helm --help aus.

Um ein Gerüst eines Helm-Diagramms mit Vorlagedateien zu erstellen, führen Sie $ helm create my-first-chart aus.

Schauen wir uns nun ein echtes Diagramm an, das Magnolia Helm Diagramm.

Magnolien Helmkarte

Ich werde das Magnolia Helm-Diagramm aus meinem vorherigen Artikel wiederverwenden. Es befindet sich im Verzeichnis helm-chart/ des magnolia-docker-Repositorys auf GitHub und hat die folgende Struktur:

  . ├── Chart.yaml ├── templates │ ├── configmap.yaml │ ├── _helpers.tpl │ ├── ingress.yaml │ ├── service.yaml │ ├── statefulset.yaml │ └── tests │ └── test-connection.yaml └── values.yaml 2 Verzeichnisse, 8 Dateien

Chart.yaml definiert das Diagramm und values.yaml gibt die Werte an, die während der Bereitstellung verwendet werden sollen.

Diagramm.yaml

  apiVersion: v2 name: magnolia Beschreibung: Bereitstellen eines Basis-Magnolia-CMS-Containers Typ: Anwendung Version: 0.1.0 appVersion: 6.2.3

Der erste Teil enthält apiVersion, einen obligatorischen Parameter, der die API-Version angibt, die das Diagramm verwendet, den Name des Diagramms und seine Beschreibung. Der nächste Abschnitt beschreibt den Typ des Diagramms - standardmäßig eine Anwendung oder alternativ eine Bibliothek -, die Version des Diagramms und appVersion, die Version der Anwendung, die Sie erhöhen sollten, wenn Sie Änderungen vornehmen.

Werte.yaml

Vorlagedateien holen Einsatzinformationen aus values.yaml ab. Um Ihr Helm-Diagramm anzupassen, können Sie entweder die vorhandene Datei bearbeiten oder eine neue Datei erstellen.

  replicaCount: 1 image: repository: ghcr.io/magnolia-sre/magnolia-docker/magnolia-docker pullPolicy: Immer tag: "latest" service: name: http port: 80 targetPort: 8080 ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx kubernetes.io/tls-acme: "true" Pfad: / authorHost: github-magnolia-docker-author.experimentation.magnolia-cloud.com publicHost: github-magnolia-docker-public.experimentation.magnolia-cloud.com tls: - secretName: github-magnolia-docker-author-tls hosts: - github-magnolia-docker-author.experimentation.magnolia-cloud.com - secretName: github-magnolia-docker-public-tls hosts: - github-magnolia-docker-public.experimentation.magnolia-cloud.com resources: limits: memory: 1000Mi requests: cpu: 500m memory: 1000Mi liveness: httpGet: path: /.rest/status port: http timeoutSeconds: 4 periodSeconds: 5 failureThreshold: 3 initialDelaySeconds: 90 readiness: httpGet: path: /.rest/status port: http timeoutSeconds: 4 periodSeconds: 6 failureThreshold: 3 initialDelaySeconds: 90 env: Autor: - Name: JAVA_OPTS Wert: >- -Dmagnolia.bootstrap.authorInstance=true -Dmagnolia.update.auto=true -Dmagnolia.home=/opt/magnolia public: - name: JAVA_OPTS value: >- -Dmagnolia.bootstrap.authorInstance=false -Dmagnolia.update.auto=true -Dmagnolia.home=/opt/magnolia

Die obige Datei definiert einige wichtige Parameter für unsere Einsätze:

replicaCount: Anzahl der Replikate für Autoren- und öffentliche Pods
der Standardwert ist 1
image: Container-Image-Repository und Tag
service: Quell- und Zielport des exponierten Dienstes
ingress: Hostnamen
Routing-Regeln und TLS-Terminierung für die Anwendung
resources:limits und resources:requests: Ressourcen und Ressourcenlimits für die Anwendung
liveness und readiness: Tests
die K8S verwendet
um festzustellen
ob die Anwendung bereit ist
Anfragen anzunehmen oder neu gestartet werden muss
Benutzerdefinierte Konfigurationen: andere anwendungsspezifische Konfigurationen
z. B. JVM OPTS

Schablonen

Der wichtigste Bestandteil eines Diagramms ist das Verzeichnis templates/ Es enthält die Konfigurationsdateien der Anwendung, die in den Cluster deployed werden. Magnolias Verzeichnis templates/ enthält configmap.yaml, ingress.yaml, service.yaml und statefulset.yaml sowie ein Testverzeichnis mit einem Verbindungstest für die Anwendung.

Building a Continuous Delivery Pipeline with GitHub and Helm to deploy Magnolia to Kubernetes

Do you want to set up a CD pipeline to deploy a containerized application to Kubernetes? Learn how to use GitHub and Helm using the Magnolia application as an example.

Jetzt lesen

Arbeitsbelastung

Ein Workload ist eine Anwendung, die in einem Kubernetes-Cluster ausgeführt wird. Jeder Workload besteht aus einer Gruppe von Pods, wobei jeder Pod eine Gruppe von Containern ist.

Umgekehrt: Ein oder mehrere Container bilden einen Pod; ein oder mehrere Pods bilden einen Workload.

Workloads können als separate Dienste bereitgestellt werden, wobei sie über das clusterinterne DNS problemlos miteinander interagieren. Sie verfügen auch über separate Datenpersistenzschichten.

StatefulSet

StatefulSet und Deployment sind Controller-Objekte in Kubernetes. Während Deployment für zustandslose Anwendungen gilt, bei denen alle Instanzen austauschbar sind, sind StatefulSet-Instanzen nicht austauschbar. StatefulSet bietet außerdem Garantien für die Reihenfolge und Einzigartigkeit seiner Pods.

Ein Pod in StatefulSet hat seine eigene sticky identity. Er wird mit einem Index benannt, zum Beispiel pod-0 und pod-1. Jeder Pod kann individuell adressiert werden und behält seinen Namen auch nach einem Neustart. Er hat auch seine eigenen persistenten Volumes und seine eigene Datenbankschicht.

StatefulSet passt zu Magnolias Interkommunikationsmodell, da jede Instanz ihre eigene Datenpersistenzschicht benötigt.

Der folgende Auszug beschreibt die typische Struktur eines StatefulSet, einschließlich wichtiger Parameter wie der Anzahl der Replikate, des Container-Images und der Ports sowie der Liveness- und Readiness-Probes:

  apiVersion: apps/v1 kind: StatefulSet metadata: name: {{ include "magnolia.fullname" . }}-öffentlich labels: {{- include "magnolia.labels" . | nindent 4 }}-öffentlich spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "magnolia.selectorLabels" . | nindent 6 }}-öffentliche Vorlage: metadata: {{- mit .Values.podAnnotations }} annotations: {{- toYaml . | nindent 8 }} {{- end }} labels: {{- include "magnolia.selectorLabels" . | nindent 8 }}-public spec: containers: - name: {{ .Chart.Name }}-public image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}" imagePullPolicy: {{ .Values.image.pullPolicy }} env: {{- toYaml .Values.env.public | nindent 12 }} ports: - name: http containerPort: {{ .Values.service.targetPort }} protocol: TCP livenessProbe: {{- toYaml .Values.liveness | nindent 12 }} readinessProbe: {{- toYaml .Values.readiness | nindent 12 }} startupProbe: {{- toYaml .Values.startupProbe | nindent 12 }}

service.yaml

Service konfiguriert den Netzwerkzugriff auf eine Reihe von Pods von innerhalb und von außerhalb des Clusters. Im Gegensatz zu ephemeren Pods hat ein Dienst einen Namen und eine eindeutige IP-Adresse, clusterIP. Seine IP ändert sich nie, es sei denn, er wird explizit zerstört.

Nachfolgend finden Sie ein Beispiel für den Dienst, der den Magnolia Public-Pod repräsentiert. Es definiert den Selektor des Pods mit einer Reihe von Pod-Labels sowie den Port und das Protokoll, das zwischen dem Dienst und den zugrunde liegenden Pods verwendet wird:

  apiVersion: v1 kind: Service metadata: name: {{ include "magnolia.fullname" . }}-öffentliche Labels: {{- include "magnolia.labels" . | nindent 4 }}-öffentlich spec: ports: - port: {{ .Werte.service.port }} targetPort: {{ .Werte.service.targetPort }} protocol: TCP name: {{ .Werte.service.name }}-öffentlicher Selektor: {{- include "magnolia.selectorLabels" . | nindent 4 }}-öffentlich

ingress.yaml

ingress ist ein Objekt, das den Zugriff auf einen Kubernetes-Dienst von außerhalb des Clusters ermöglicht. Es definiert und konsolidiert Routing-Regeln, um den Zugriff externer Benutzer auf den Dienst zu verwalten, normalerweise über HTTPS/HTTP.

Hinweis: Um Ingress-Objekte zu erfüllen, benötigen Sie einen Ingress-Controller in Ihrem Cluster, z. B. den NGINX Ingress Controller.

  apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: {{ $fullName }} labels: {{ include "magnolia.labels" . | Einzug 4 }} {{- mit .Values.ingress.annotations }} annotations: {{- toYaml . | nindent 4 }} {{- end }} spec: {{- if .Values.ingress.tls }} tls: {{- range .Values.ingress.tls }} - hosts: {{- range .hosts }} - {{ . | quote }} {{- end }} secretName: {{ .secretName }} {{- end }} {{- end }} rules: - host: {{ .Values.ingress.authorHost }} http: paths: - path: / backend: serviceName: {{ $fullName }}-author servicePort: http-author - host: {{ .Values.ingress.publicHost }} http: paths: - path: / backend: serviceName: {{ $fullName }}-public servicePort: http-public

Das obige Objekt ingress enthält einige wichtige Attribute:

tls: TLS-Offloading
verwendet Zertifikate von Kubernetes secret
jedes Zertifikat kann mit einer Liste von Hosts verbunden werden.
rules: Traffic-Routing zum Backend-Dienst
jede Regel kann für einen bestimmten Hostnamen
eine Liste von Pfaden und das Backend als Kombination aus Dienst und Port definiert werden.

configmap.yaml

ConfigMap ermöglicht es Ihnen, eine umgebungsspezifische Konfiguration von Pods und Containern zu entkoppeln. Sie speichert Daten als Schlüssel-Wert-Paare, die an anderen Stellen verwendet werden können. Eine ConfigMap kann zum Beispiel als Umgebungsvariable referenziert oder als Pod-Volume verwendet werden, das in Containern gemountet wird.

  apiVersion: v1 Art: ConfigMap metadata: name: {{ template "magnolia.fullname" . }} labels: app: {{ template "magnolia.name" . }} chart: {{ template "magnolia.chart" . }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} data: magnolia-cloud.decorations.publishing-core.config.yaml: |- Empfänger: !override public0: url: https://{{ .Values.ingress.publicHost }}

Diese ConfigMap wird zum Beispiel in statefulset.yaml als Pod-Volume referenziert:

  container: - name: {{ .Chart.Name }}-author ... volumeMounts: - name: magnolia-home mountPath: /opt/magnolia volumes: - name: mounted-config configMap: name: {{ template "magnolia.fullname" . }}

Im Container wird die Konfigurationsdatei magnolia-cloud.decorations.publishing-core.config.yaml unter dem Verzeichnis /opt/magnolia/ eingebunden.

Benannte Vorlagen

Die Magnolia-Vorlagen nutzen benannte Vorlagen mit einer Syntax wie {{- include "magnolia.labels" }} Eine benannte Vorlage ist eine Go-Vorlage, die in einer Datei definiert und mit einem Namen versehen ist. Einmal in _helpers.tpl. definiert, können benannte Vorlagen in anderen Vorlagen verwendet werden, wodurch Boilerplates und wiederholter Code vermieden werden.

Chart Syntax

Wenn Sie ein Helm-Diagramm entwickeln, empfehle ich Ihnen, es durch den Linter laufen zu lassen, um sicherzustellen, dass Ihre Vorlagen wohlgeformt sind und den Best Practices entsprechen.

Führen Sie den Befehl helm lint aus, um den Linter in Action zu sehen:

  $ helm lint ./helm-chart/ ==> Linting ./helm-chart/ [INFO] Chart.yaml: Symbol wird empfohlen 1 Chart(s) gelintet, 0 Chart(s) fehlgeschlagen

Um zu überprüfen, ob alle Vorlagen wie erwartet definiert sind, können Sie Diagrammvorlagen lokal rendern und die Ausgabe mit dem Befehl template anzeigen:

  $ helm template ./helm-chart/

Bereitstellen eines Helm-Diagramms auf dem Cluster

Machen wir uns die Hände mit einem Einsatz schmutzig.

Erstellen eines Kubernetes-Clusters

Wir werden einen Minikube-Cluster für unseren Testeinsatz verwenden. Die Installationsanweisungen finden Sie unter https://minikube.sigs.k8s.io/docs/start/.

Sobald Sie minikube auf Ihrem Rechner installiert haben, können Sie Ihren Cluster mit einer bestimmten Kubernetes-Version starten:

  $ minikube start --kubernetes-version=1.16.0 😄 minikube v1.6.2 auf Darwin 10.14.5 ✨ Automatisch den 'virtualbox'-Treiber ausgewählt (Alternativen: []) 🔥 Virtualbox-VM erstellen (CPUs=2, Memory=2000MB, Disk=20000MB) ... 🐳 Vorbereiten von Kubernetes v1.16.0 auf Docker '19.03.5' ... 💾 Herunterladen von kubeadm v1.16.0 💾 Herunterladen von kubelet v1.16.0 🚜 Ziehen von Images ... 🚀 Starten von Kubernetes ... 
⌛ Warten darauf, dass der Cluster online geht ... 🏄 Geschafft! kubectl ist jetzt so konfiguriert, dass es "minikube" verwendet

Installation der Magnolia-Karte

Installieren Sie das Magnolia-Diagramm aus Ihrem lokalen Git-Repository und prüfen Sie das Release:

  $ helm install test-mgnl-chart ./helm-chart/ NAME: test-mgnl-chart LAST DEPLOYED: Fri Jan 15 16:56:42 2021 NAMESPACE: default STATUS: deployed REVISION: 1 $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION test-mgnl-chart default 1 2021-01-15 16:56:42.981924 +0700 +07 deployed magnolia-0.1.0 6.2.3

Zugriff auf die Anwendung

Verwenden Sie den Befehl port-forward, um z.B. einen lokalen Port auf den Service-Port der Magnolia-Autoreninstanz weiterzuleiten:

  $ kubectl port-forward svc/test-mgnl-chart-magnolia-author 8080:80

Sie können jetzt auf die Magnolia-Anwendung unter http://localhost:8080 zugreifen .

Nächste Schritte

Wir haben die Grundlagen des Magnolia Helm-Diagramms erkundet und das Diagramm in einem lokalen Cluster eingesetzt. Von hier aus können Sie noch viel mehr tun, zum Beispiel Änderungen an den Diagrammvorlagen vornehmen, Ihre eigene values.yaml-Datei erstellen, Ingress mit einem Ingress-Controller konfigurieren und das Diagramm in Ihrem eigenen Cluster bereitstellen.