{"id":3368,"date":"2024-01-28T14:55:35","date_gmt":"2024-01-28T13:55:35","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=3368"},"modified":"2024-01-28T17:09:15","modified_gmt":"2024-01-28T16:09:15","slug":"helm-sh","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2024\/helm-sh\/","title":{"rendered":"Helm.sh"},"content":{"rendered":"
\n

Helm.sh<\/h1>\n

In der Welt der Containerorchestrierung ist effizientes Deployment entscheidend. Der Paket-Manager Helm<\/em> selbst bezeichnet sich als:<\/p>\n

„Der beste Weg, Anwendungen f\u00fcr Kubernetes zu finden, zu teilen und einzusetzen“ [1]<\/sup><\/p><\/blockquote>\n

Die Verwendung von Helm ist eng mit der Funktionsweise des Open-Source-Systems Kubernetes<\/em> (K8s) verbunden. Helm fungiert als eine Abstraktionsebene f\u00fcr Kubernetes und zielt darauf ab, Administratoren und Entwicklern die Verwaltung, Entwicklung und Bereitstellung von Software in Kubernetes-Clustern zu erleichtern. Dabei erfordert die Vermittlung des Prinzips hinter der Paketverwaltung ein grundlegendes Verst\u00e4ndnis von Kubernetes, welches im Folgenden vermittelt werden soll.<\/p>\n

Kubernetes<\/h2>\n

Kubernetes treibt als System zur Orchestrierung, Bereitstellung und allgemeinen Verwaltung von containerisierten Anwendungen seit 2014 den Paradigmenwechsel zur Containerisierung von Software und deren Abh\u00e4ngigkeiten voran. So soll eine konsistente Bereistellung von Systemen sowie eine Portabilit\u00e4t \u00fcber verschiedene Umgebungen erzielt werden.
\n\u00dcber Helm bereitgestellte Software profitiert damit von vielen leistungsf\u00e4higen nennenswerten Funktionen, die Kubernetes durch den Betrieb von Containern in einem Cluster realisiert, darunter Skalierung, Lastverteilung und allgemeine Widerstandsf\u00e4higkeit des Systems. Signifikant ist dabei nicht zuletzt der deklarative Ansatz, bei dem ein gewisser vorkonfigurierter Zielzustand beschrieben wird. Unabh\u00e4ngige, komponierbare Steuerungsprozesse treiben den aktuellen Zustand des Systems dabei kontinuierlich in Richtung des bereitgestellten Soll-Zustandes. [2]<\/sup><\/p>\n

Ein solches Kubernetes-Cluster besteht dabei grundlegend aus sogenannten Nodes<\/em>, die auf einer oder mehreren Maschinen laufen k\u00f6nnen. Dabei fungiert einer dieser Nodes als Main Node<\/em>, w\u00e4hrend die \u00dcbrigen als Worker Nodes<\/em> bezeichnet werden. Der Main Node \u00fcbernimmt eine allgemeine Steuerungsfunktion f\u00fcr die Worker Nodes und verf\u00fcgt daf\u00fcr \u00fcber verschiedene Komponenten wie den Controller-Manager oder einen API-Server als Schnittstelle f\u00fcr Administratoren.<\/p>\n

\"Grundlegender
Komponenten der Main Node und Worker Nodes in einem Kubernetes-Cluster<\/figcaption><\/figure>\n

Auch die Worker Nodes verf\u00fcgen \u00fcber essentielle Komponenten, wobei die wichtigsten die sogenannten Pods<\/em> sind. Diese Pods umfassen jeweils einen oder mehrere Container, in denen wiederum die letztendlich bereitzustellenden Anwendungen in isolierten Umgebungen laufen.
\nDer erreichte Endzustand dieser Konfiguration wird als Deployment bezeichnet und beschreibt nicht nur die Anzahl der laufenden Pods in den jeweiligen Nodes, sondern auch weitere Eigenschaften wie das Verhalten der Container beim Einspielen von Updates oder \u00e4hnliches.<\/p>\n

In der Praxis sind komplexe Anwendungen oft modular aufgebaut, was die Notwendigkeit einer Kommunikation der Pods untereinander erfordert. Daf\u00fcr werden die Anwendungen in den Pods \u00fcber sogenannte Services abgebildet, die als eine Art Reverse-Proxy dienen und die Netzwerkkomplexit\u00e4t f\u00fcr den Entwickler abstrahieren. Der Service fungiert dann als Kommunikationsendpunkt f\u00fcr eine gewisse bereitgestellte Anwendung des Clusters.<\/p>\n

\"Services
Abstrahierung durch Services in einem Kubernetes-Cluster<\/figcaption><\/figure>\n

Das illustrierte Beispiel zeigt den Betrieb eines Webserver und einer Datenbank in einem Kubernetes-Cluster. Potentielle Anfragen eines beliebigen Webserver-Pods sind dabei nicht an die Datenbank-Pods direkt gerichtet, sondern werden zun\u00e4chst an den abstrahierenden Datenbank-Service adressiert. Dieser leitet die Anfrage letztendlich an einen verf\u00fcgbaren Datenbank-Pod weiter, wobei die Auswahl des Pods von Faktoren wie der aktuellen Auslastung abh\u00e4ngen kann.<\/p>\n

Damit nun auch eine Kommunikation von extern erfolgen kann, kommt zus\u00e4tzlich ein sogenannter Ingress<\/em>-Controller zum Einsatz. Mittels Konfiguration durch Ingress-Resourcen werden bestimmte Pfade und Hostnamen auf bereitgestellte Services abgebildet. Der Ingress-Controller realisiert damit eine Verarbeitung und Weiterleitung von Anfragen aus dem Internet, sodass die betriebenen Anwendungen auch von Clients au\u00dferhalb des Clusters addressiert werden k\u00f6nnen.<\/p>\n

\"Ingress
Ingress Controller und Ingress Ressourcen<\/figcaption><\/figure>\n

Grundkonzept von Helm.sh<\/h2>\n

Damit Kubernetes Ressourcen nicht manuell angelegt werden m\u00fcssen kann Helm verwendet werden, ein auf Go basierender Paketmanager f\u00fcr Kubernetes. Das Ziel besteht darin, Updates und Rollbacks effizienter zu gestalten. Daf\u00fcr verwendet es insgesamt drei Grundkonzepte<\/strong>:<\/p>\n

Charts<\/h4>\n

Diese sind vergleichbar mit Homebrew formulaes<\/em>, apt dpkg<\/em> oder yum rpm<\/em> Dateien. Charts sind praktisch eine Sammlung von Dateien, die eine zusammenh\u00e4ngende Menge von Kubernetes-Ressourcen beschreiben. Daf\u00fcr gibt es zum einen die chart.yml<\/code>. Diese beinhaltet die Definition der Metadaten des Paketes, z. B. die Angabe der apiVersion<\/code>, den Namen des Charts, sowie die Beschreibung oder den Typ des Charts, etc.
\nOptionale Parameter sind m\u00f6glich, wie zum Beispiel dependencies<\/code>, maintainers<\/code>, keyWords<\/code> oder kubeVersion<\/code>. Der Typ kann sowohl Application<\/em> (Standard) oder Library<\/em> sein. Letzteres beinhaltet \u00fcblicherweise keine Ressourcen-Objekte und ist nicht installierbar.
\nDie values.yml<\/code> stellt den zentralen Ort f\u00fcr Konfigurationen bereit und beinhaltet Standardwerte f\u00fcr Konfigurationseinstellungen. Die darin definierten Werte k\u00f6nnen anschlie\u00dfend innerhalb von Templates<\/em> verwendet werden. Die Wortseparierung erfolgt mittels CamelCase<\/em>. Eine Definition der Werte ist sowohl verschachtelt als auch flach m\u00f6glich. Zudem k\u00f6nnen definierte Standardwerte \u00fcberschrieben werden, um die Charts an unterschiedliche Umgebungen anpassen zu k\u00f6nnen. Dadurch wird eine hohe Flexibilit\u00e4t und die Wiederverwendbarkeit von Charts erm\u00f6glicht.
\nDie Dateien chart.yml<\/code> und values.yml<\/code> k\u00f6nnen dann jeweils f\u00fcr Templates verwendet werden, bspw. in einer Kubernetes deployment.yml<\/code>-Datei. Diese Templates stellen die eigentlichen Kernkomponenten eines Charts dar. Es sind Kubernetes-Manifest-Dateien, \u00fcber welche dynamische Inhalte gerendert werden k\u00f6nnen. Zudem verwenden sie verschiedene Werte aus values.yml<\/code>, um spezifische Aspekte der Kubernetes-Ressourcen zu entwickeln. Als Beispiel k\u00f6nnen hier die Anzahl der Replikate aufgef\u00fchrt werden. Insgesamt entsteht eine dynamische Gestaltung der Helm Charts durch die Verwendung von Templates. Dadurch kann der gleiche Chart f\u00fcr verschiedene Installationen mit unterschiedlichen Konfigurationen verwendet werden.<\/p>\n

Repositories<\/h4>\n

Erstellte Helm Charts k\u00f6nnen in Repositories gespeichert werden. Diese k\u00f6nnen selbst gehostet werden, wie z. B. \u00fcber das firmeninterne Nexus. Auf Wunsch kann das eigene Repository bei Artifact Hub angegeben werden. Daraufhin werden die Pakete indexiert und in der Suche angezeigt. Artifact Hub<\/a> stellt dabei eine Vielzahl von vorgefertigten Charts f\u00fcr g\u00e4ngige Anwendungen zur Verf\u00fcgung.<\/p>\n

Release<\/h4>\n

Ein Release bezeichnet eine Instanz eines installierten Charts innerhalb eines Kubernetes-Clusters. Helm erm\u00f6glicht es, verschiedene Releases des selben Charts mit unterschiedlichen Konfigurationen zu verwalten.<\/p>\n

 <\/p>\n

Beispielhafter Workflow<\/h2>\n

\"\"<\/p>\n

    \n
  1. Der Softwareentwickler entwickelt ein Chart mit den darin enthaltenen Templates.<\/li>\n
  2. Dieses wird anschlie\u00dfend in das firmeninterne Repository verschoben.<\/li>\n
  3. Die Cluster werden von einem Administrator verwaltet. Dieser nutzt Helm, muss jedoch nicht genau wissen wie der Chart aufgebaut ist. Er muss eventuell nur wissen, welche Konfigurationen notwendig sind.<\/li>\n
  4. Der Administrator kann nun per Kommandozeile der erstellte Chart herunterladen bzw. aktualisieren und in das Kubernetes-Cluster deployen. Dadurch entf\u00e4llt die Notwendigkeit des manuellen Anlegens der Kubernetes-Ressourcen<\/li>\n
  5. Das Deployment erfolgt \u00fcber den Kubernetes-API-Server, welcher auf dem Main Node l\u00e4uft und die Charts und Konfigurationen kombiniert, die zum Erstellen eines Releases ben\u00f6tigt werden. Aktualisierung und Deinstallation von Releases sind hier\u00fcber ebenfalls m\u00f6glich.<\/li>\n<\/ol>\n

     <\/p>\n

    \n

    Anwendungsbeispiel 1: \u00d6ffentliches Helm Chart
    \n<\/b><\/h2>\n<\/div>\n

    Installation von Minikube und Helm<\/h3>\n

    Es gibt verschiedene Wege, um sich ein eigenes kleines lokales Kubernetes-Cluster aufzusetzen. In diesem Fall soll Minikube<\/i> verwendet werden. In dieser Anleitung geht man davon aus, dass Minikube auf einem Linux System mit der x86-64 Prozessorarchitektur installiert werden soll. Auf der Minikube Website<\/a> findet man weitere Anleitungen f\u00fcr andere Betriebssysteme und Prozessorarchitekturen. Minikube kann dann \u00fcber folgende Kommandos installiert werden:<\/p>\n

    $ curl -LO \\\r\n\r\nhttps:\/\/storage.googleapis.com\/minikube\/releases\/latest\/minikube-linuxamd64<\/a><\/u>\r\n\r\n$ sudo install minikube-linux-amd64 \/usr\/local\/bin\/minikube<\/pre>\n
     <\/p>\n
    Um das Cluster hochzufahren, muss eine Container-Virtualisierungssoftware wie etwa Docker<\/em> installiert sein. Das Cluster kann man dann hochfahren \u00fcber die Eingabe von:<\/p>\n
    $ minikube start<\/pre>\n
     <\/p>\n
    Ab jetzt kann mit dem Kubernetes Cluster mithilfe des Kommandos kubectl<\/i> interagiert werden, welches bei der Installation von Minikube automatisch mitinstalliert wird. Um sich von der Funktionsweise von kubectl<\/i> zu \u00fcberzeugen, kann folgendes Kommando ausgef\u00fchrt werden, welches die Nodes, aus dem das Cluster besteht, auflistet:<\/p>\n
    $ kubectl get nodes\r\nNAME       STATUS   ROLES           AGE   VERSION\r\nminikube   Ready    control-plane   42d   v1.28.3<\/pre>\n
    Zudem muss noch ein Addon auf dem Minikube Cluster aktiviert werden:<\/p>\n
    $ minikube addons enable ingress<\/pre>\n
    Abschlie\u00dfend kann dann noch Helm \u00fcber die Kommandozeile installiert werden:<\/p>\n
    $ curl https:\/\/raw.githubusercontent.com\/helm\/helm\/main\/scripts\/get-helm-3 | bash<\/pre>\n<\/div>\n
    <\/h3>\n
    Installation des Nextcloud Charts<\/b><\/h3>\n
    \n
    F\u00fcr dieses Beispiel gehen wir davon aus, dass man einen Nextcloud Server auf dem Kubernetes Cluster installieren m\u00f6chte. Auf Artifact Hub bietet Nextcloud ein offizielles Nextcloud Helm Chart<\/a> an. Die Seite des Charts gibt neben Installationsanweisungen auch dar\u00fcber Auskunft, wie man der Chart bei der Installation konfigurieren kann. Die folgenden Schritte beschreiben chronologisch die Installation des Nextcloud Helm Charts, lassen sich aber theoretisch auch auf die Installation eines beliebigen anderen Charts \u00fcbertragen.<\/p>\n
    1. Verweis auf das Nextcloud Repo anlegen<\/h4>\n
    Um der Chart \u00fcber Helm auf dem lokalen Cluster zu installieren, muss zun\u00e4chst eine Referenz auf das Repo, in dem der Chart liegt, hinterlegt werden, damit Helm bei der Installation wei\u00df, welches genaue Chart installiert werden soll.<\/p>\n
    $ helm repo add nextcloud https:\/\/nextcloud.github.io\/helm\/<\/a><\/u><\/span>\r\n\"nextcloud\" has been added to your repositories<\/pre>\n
    2. Konfigurationsdatei anlegen<\/h4>\n
    Um der Chart bei der Installation zu konfigurieren, legt man eine Datei config.yaml<\/code> an, in der die angestrebte Konfiguration \u00fcber Key-Value-Paare beschrieben wird:<\/p>\n
    nextcloud:\r\n   host: mynextcloud.xyz\r\n   username: user01\r\n   password: password123\r\n\r\ningress: \r\n   enabled: true \r\n   ingressClass: \"nginx\"\r\n\r\nmariadb: \r\n   enabled: true\r\n   auth.username: \"admin\"\r\n   auth.password: \"1337H@xx0r\"\r\n   auth.rootPassword: \"1337H@xx0r\"<\/pre>\n
    Mit dieser Konfiguration sorgt man daf\u00fcr, dass der Nextcloud Server unter der Domain mynextcloud.xyz<\/em> erreichbar ist und ein Benutzer mit dem Namen user01<\/em> und dem Passwort password123<\/em> angelegt wird. Da der Server auch von au\u00dfen bspw. \u00fcber den Browser ansprechbar sein soll, wird zus\u00e4tzlich ein Ingress Objekt dazu konfiguriert. Damit die vom Server verwalteten Dateien auch nach einem Neustart des Servers noch vorhanden sind, soll neben dem Nextcloud Server abschlie\u00dfend noch eine MariaDB<\/em> installiert werden.<\/p>\n
    3. Installation des Charts<\/h4>\n
    Nun kann der Chart unter der Angabe der im vorigen Schritt erstellten Konfigurationsdatei installiert werden. Der Chart wird hierbei im demo<\/i> Namespace installiert:<\/p>\n
    $ : helm -n demo install my-nextcloud nextcloud\/nextcloud -f config.yaml\r\nNAME: my-nextcloud\r\nLAST DEPLOYED: Thu Jan 25 11:50:56 2024\r\nNAMESPACE: demo\r\nSTATUS: deployed\r\nREVISION: 1\r\nTEST SUITE: None\r\nNOTES:\r\n...\r\n<\/pre>\n
    Die Installation des Helm Charts – also das Release – tr\u00e4gt den gew\u00e4hlten Namen my-nextcloud<\/em>, was man aus der Ausgabe des Kommandos erkennen kann.<\/p>\n
    Um zu sehen, was im Hintergrund auf dem Kubernetes Cluster passiert ist, l\u00e4sst man sich die Pods, Ingress Objekte und Services im demo Namespace anzeigen:<\/p>\n
    $ kubectl -n demo get pods,ingress,svc\r\nNAME                                READY   STATUS    RESTARTS   AGE\r\npod\/my-nextcloud-688c657846-n2jzt   1\/1     Running   0          80s\r\npod\/my-nextcloud-mariadb-0          1\/1     Running   0          80s\r\n\r\nNAME                                     CLASS   HOSTS             ADDRESS        PORTS   AGE\r\ningress.networking.k8s.io\/my-nextcloud   nginx   mynextcloud.xyz   192.168.49.2   80      81s\r\n\r\nNAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE\r\nservice\/my-nextcloud           ClusterIP   10.100.85.36                  8080\/TCP   81s\r\nservice\/my-nextcloud-mariadb   ClusterIP   10.101.116.73                 3306\/TCP   81s\r\n<\/pre>\n
    Hier sieht man nun, dass durch die Installation des Charts Kubernetes Ressourcen angelegt wurden. So repr\u00e4sentieren die zwei Pods den Nextcloud Server sowie die MariaDB Instanz. Ebenso wurde ein Ingress-Objekt erstellt, das angibt, dass der Nextcloud Server unter der angegebenen Domain zu erreichen ist. Die zwei bereitgestellten Services stellen sicher, dass die Pods im Cluster erreicht werden k\u00f6nnen. Wie man an dieser Stelle sehen kann, spiegelt der Zustand des Clusters mit den angelegten Kubernetes Ressourcen genau die Konfiguration wider, die man bei der Installation des Charts mithilfe der config.yaml<\/code> \u00fcbergeben hat.<\/p>\n
    3. DNS-Eintrag anlegen<\/h4>\n
    Um den Nextcloud Server \u00fcber die angegebene Domain erreichen zu k\u00f6nnen, muss im letzten Schritt nur noch ein lokaler DNS-Eintrag angelegt werden, mit dem die Domain mynextcloud.xyz auf die IP-Adresse des Clusters aufgel\u00f6st wird. Die IP-Adresse des Clusters erh\u00e4lt man \u00fcber:<\/p>\n
    $ minikube ip\r\n192.168.49.2<\/pre>\n
    Dann erstellt man einen DNS-Eintrag in der Datei \/etc\/hosts<\/em>. Hier muss die IP-Adresse, die man aus dem Output des vorigen Commands erh\u00e4lt, gefolgt von der Domain mynextcloud.xyz eingetragen werden.
    \nEin m\u00f6gliches Beispiel sieht man in der folgenden Abbildung, in der die Domain auf die IP-Adresse 192.168.49.2 aufl\u00f6st.<\/p>\n
    127.0.0.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 localhost\r\n\r\n192.168.49.2       mynextcloud.xyz<\/pre>\n
    Damit ist die Installation des Nextcloud Helm Charts abgeschlossen und kann nun genutzt werden. Hierzu einfach mynextcloud.xyz im Browser eingeben.<\/p>\n<\/div>\n
     <\/p>\n
    Upgrade des installierten Nextcloud Charts<\/b><\/h3>\n
    \n
    Neben der Installation ist es auch m\u00f6glich, die Konfiguration eines Helm Releases nach der Installation abzu\u00e4ndern. Der installierte Nextcloud Server soll nun nicht mehr auf die MariaDB angewiesen sein. Dazu passt man zun\u00e4chst die config.yaml<\/code> an und kommentiert den nicht mehr ben\u00f6tigten Teil aus:<\/p>\n
    nextcloud:\r\n   host: mynextcloud.xyz\r\n   username: user01\r\n   password: password123\r\n\r\ningress: \r\n   enabled: true \r\n   ingressClass: \"nginx\"\r\n\r\n# mariadb: \r\n   # enabled: true\r\n   # auth.username: \"admin\"\r\n   # auth.password: \"1337H@xx0r\"\r\n   # auth.rootPassword: \"1337H@xx0r\"<\/pre>\n
    Jetzt kann man der Helm Chart mit der ge\u00e4nderten Konfiguration upgraden.<\/p>\n
    $ helm -n demo upgrade my-nextcloud nextcloud\/nextcloud -f config.yaml\r\nRelease \"my-nextcloud\" has been upgraded. Happy Helming!\r\n...\r\n<\/pre>\n
    Wenn man sich nun erneut die Pods und Services auf dem Cluster anzeigen l\u00e4sst, so f\u00e4llt auf, dass der MariaDB-Pod und der zugeh\u00f6rige Service verschwunden sind.<\/p>\n
    kubectl -n demo get pods,ingress,svc\r\nNAME                                READY   STATUS    RESTARTS   AGE\r\npod\/my-nextcloud-69ddd8f55f-5jvhh   1\/1     Running   0          113s\r\n\r\nNAME                                     CLASS   HOSTS             ADDRESS        PORTS   AGE\r\ningress.networking.k8s.io\/my-nextcloud   nginx   mynextcloud.xyz   192.168.49.2   80      8m49s\r\n\r\nNAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE\r\nservice\/my-nextcloud   ClusterIP   10.100.85.36                 8080\/TCP   8m49s\r\n<\/pre>\n
    Deinstallation des installierten Nextcloud Charts<\/b><\/h3>\n
    Abschlie\u00dfend m\u00f6chten wir das Release deinstallieren, um unser Cluster in den Ausgangszustand vor der Installation zur\u00fcckzuversetzen. Dazu folgenden Command in der Kommandozeile eingeben:<\/p>\n
    $ helm -n demo uninstall my-nextcloud\r\nrelease \"my-nextcloud\" uninstalled<\/pre>\n
    Mit der Deinstallation des Charts werden alle erstellten Kubernetes Ressourcen vollst\u00e4ndig entfernt.<\/p>\n
     <\/p>\n
    \n
    Anwendungsbeispiel 2: Eigenes Helm Chart<\/h2>\n<\/div>\n
    Scenario<\/span><\/h3>\n
    Wir arbeiten in einem Unternehmen und haben die Aufgabe jeder Abteilung des Unternehmens zu erm\u00f6glichen eine eigene Website auf dem Kubernetes-Cluster bereitzustellen. Hierzu erstellen wir ein Helm Chart, welches unternehmensintern bereitgestellt wird.\u00a0<\/span><\/p>\n
    Der Helm Chart<\/span><\/h3>\n
    Der folgende Helm Chart erstellt einen NGINX Server, welcher eine einfache HTML Website darstellt. Die Domain der Website und der Inhalt k\u00f6nnen dabei von der installierenden Person konfiguriert werden. So kann jede Abteilung mit demselben Helm Chart individuelle Webseiten bereitstellen.<\/span><\/p>\n
    Dateien:<\/span><\/h4>\n
    department-website-chart\/<\/span>\r\n  app-chart\/<\/span>\r\n    templates\/<\/span>\r\n      configmap.yaml<\/span>\r\n      deployment.yaml<\/span>\r\n      ingress.yaml<\/span>\r\n      service.yaml<\/span>\r\n    Chart.yaml<\/span>\r\n    values.yaml<\/span><\/pre>\n
    Ein Helm Chart besteht immer aus einer Chart.yaml<\/code>, einer values.yaml<\/code> und mehreren Template-Files.\u00a0<\/span><\/p>\n
    Charts.yaml<\/b><\/p>\n
    apiVersion: v2<\/span>\r\nname: bis-app<\/span>\r\ndescription: sample nginx deployment<\/span>\r\ntype: application<\/span>\r\nversion: 1.0<\/span>\r\nappVersion: 1.0<\/span><\/pre>\n
    Hier sind die Meta-Informationen des Helm Charts festgehalten, wie Name und Version unseres Charts.<\/span><\/p>\n
    Weitere Infos: https:\/\/helm.sh\/docs\/topics\/charts\/#the-chartyaml-file<\/span><\/p>\n
    <\/h2>\n
    values.yaml<\/b><\/p>\n
    host: department1.local\r\ndepartment: \"department1\"\r\nmessage: \"Welcome on our website!\"\r\nreplicas: 1<\/pre>\n
    Hier werden alle variablen Konfigurationen unseres Helm Charts mit zugeh\u00f6rigen Default-Werten festgehalten. Die hier aufgelisteten Parameter k\u00f6nnen beim Installieren und beim Upgraden des Helm Charts f\u00fcr den entsprechenden Use-Case \u00fcberschrieben werden.<\/span><\/p>\n
    templates\/configmap.yaml<\/b><\/p>\n
    apiVersion: v1<\/span>\r\nkind: ConfigMap<\/span>\r\nmetadata:<\/span>\r\n \u00a0name: {{ .Release.Name }}-nginx-config<\/span>\r\ndata:<\/span>\r\n \u00a0nginx.conf: |<\/span>\r\n \u00a0\u00a0\u00a0events {<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0worker_connections\u00a0 1024;<\/span>\r\n \u00a0\u00a0\u00a0}<\/span>\r\n \u00a0\u00a0\u00a0http {<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0server {<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0listen 80;<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0location \/ {<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return 200 \"Greeting from Department {{ .Values.department }}! {{ .Values.message }}\";<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0}<\/span>\r\n\u00a0\u00a0\u00a0\u00a0}<\/span><\/pre>\n
    Die Templates im Ordner <\/span>templates<\/span><\/em> enthalten die jeweiligen Kubernetes Ressources, welche durch den Helm Chart angelegt werden.<\/span><\/p>\n
    Eine ConfigMap ist ein Kubernetes-Objekt, welches Konfigurationen beinhaltet, die von anderen Kubernetes-Objekten genutzt werden k\u00f6nnen.<\/span><\/p>\n
    In diesem Beispiel benutzen wir die ConfigMap f\u00fcr unsere NGINX Konfiguration.<\/span><\/p>\n
    Mit <\/span>{{ .Values.department }}<\/code><\/span> und\u00a0 <\/span>{{ .Values.message }}<\/code><\/span> greifen wir hier auf die Werte unserer Eintr\u00e4ge aus der <\/span>values.yaml<\/code><\/span> zu. Beim Installieren werden die vom Nutzer festgelegten Values (bzw. die Default-Values vom Nutzer nicht \u00fcberschrieben) an die entsprechenden Stellen eingesetzt.<\/span><\/p>\n
    Neben den values k\u00f6nnen noch auf weitere Werte zur\u00fcckgegriffen werden, wie z.B. <\/span>{{ .Release.Name }}<\/code><\/span> welches uns den bei der Installation festgelegten Namen der Installation zur\u00fcckgibt.<\/span><\/p>\n
    deployment.yaml<\/b><\/p>\n
    apiVersion: apps\/v1<\/span>\r\nkind: Deployment<\/span>\r\nmetadata:<\/span>\r\n \u00a0name: {{ .Release.Name }}<\/span>\r\n \u00a0labels:<\/span>\r\n \u00a0\u00a0\u00a0app: {{ .Release.Name }}<\/span>\r\nspec:<\/span>\r\n \u00a0replicas: {{ .Values.replicas }}<\/span>\r\n \u00a0selector:<\/span>\r\n \u00a0\u00a0matchLabels:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0app: {{ .Release.Name }}<\/span>\r\n \u00a0strategy:<\/span>\r\n \u00a0\u00a0\u00a0type: RollingUpdate<\/span>\r\n \u00a0\u00a0\u00a0rollingUpdate:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0maxUnavailable: 1<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0maxSurge: 1<\/span>\r\n \u00a0template:<\/span>\r\n \u00a0\u00a0\u00a0metadata:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0labels:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0app: {{ .Release.Name }}<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0annotations:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0checksum\/config: {{ include (print $.Template.BasePath \"\/configmap.yaml\") . | sha256sum }}<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0checksum\/values: {{ printf \"%s-%s\" .Values.department .Values.message | sha256sum }}<\/span>\r\n \u00a0\u00a0\u00a0spec:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0containers:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: {{ .Release.Name }}<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0image: nginx:stable<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ports:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- containerPort: 80<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0volumeMounts:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: config<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0mountPath: \/etc\/nginx\/nginx.conf<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0subPath: nginx.conf<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0volumes:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: config<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0configMap:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: {{ .Release.Name }}-nginx-config<\/span><\/pre>\n
    Die Deployment Kubernetes-Ressource beschreibt wie der Pod welcher unseren NGINX Container ausf\u00fchrt aussehen soll und wie h\u00e4ufig er bereitgestellt werden soll. Hier wird die zuvor definierte ConfigMap verwendet, um die NGINX Konfiguration als <\/span>nginx.conf<\/code><\/span>Datei in dem Container zu erstellen.<\/span><\/p>\n
    Weitere Infos zu Deployments in der Kubernetes Dokumentation<\/a>.<\/span><\/p>\n
    <\/h2>\n
    service.yaml<\/b><\/p>\n
    apiVersion: v1<\/span>\r\nkind: Service<\/span>\r\nmetadata:<\/span>\r\n \u00a0name: {{ .Release.Name }}-service<\/span>\r\nspec:<\/span>\r\n \u00a0type: ClusterIP<\/span>\r\n \u00a0selector:<\/span>\r\n \u00a0\u00a0\u00a0app: {{ .Release.Name }}<\/span>\r\n \u00a0ports:<\/span>\r\n \u00a0\u00a0\u00a0- protocol: \"TCP\"<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0port: 80<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0targetPort: 80<\/span><\/pre>\n
    Die Service Kubernetes-Ressource erm\u00f6glicht es, innerhalb des Clusters mit den in der deployment.yaml<\/code> definierten Pods zu kommunizieren.\u00a0<\/span><\/p>\n
    ingress.yaml<\/b><\/p>\n
    apiVersion: networking.k8s.io\/v1<\/span>\r\nkind: Ingress<\/span>\r\nmetadata:<\/span>\r\n \u00a0name: {{ .Release.Name }}-ingress<\/span>\r\n \u00a0annotations:<\/span>\r\n \u00a0\u00a0\u00a0nginx.ingress.kubernetes.io\/rewrite-target: \/$1<\/span>\r\nspec:<\/span>\r\n \u00a0rules:<\/span>\r\n \u00a0\u00a0\u00a0- host: {{ .Values.host }}<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0http:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0paths:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- path: \/<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pathType: Prefix<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0backend:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0service:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: {{ .Release.Name }}-service<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0port:<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0number: 80<\/span><\/pre>\n
    Der Ingress beschreibt eine Route, \u00fcber die von extern auf den zuvor definierten Service zugegriffen werden kann. Ein Ingress-Controller sammelt alle Ingress-Ressourcen in einem Cluster und leitet eingehende Anfragen anhand dieser Regeln weiter.<\/span><\/p>\n
    In unserem Fall sagen wir, dass alle Anfragen an den Host, welcher in der values.yaml<\/code> hinterlegt ist (\u00fcber <\/span>host: {{ .Values.host }}<\/code><\/span>), an den Service, den wir in <\/span>templates\/service.yaml<\/code><\/span> definiert haben, weitergeleitet werden.\u00a0<\/span><\/p>\n
     <\/p>\n
    Helm Chart bereitstellen<\/strong><\/h3>\n
    Damit der Helm Chart von den Abteilungen unseres Unternehmens genutzt werden kann, m\u00fcssen wir diesen den Helm Chart zun\u00e4chst bereitstellen.<\/span><\/p>\n
    Hierzu erstellen wir zun\u00e4chst einen neuen Ordner <\/span>charts<\/code><\/span><\/p>\n
    department-website-chart\/<\/span>\r\n  app-chart\/<\/span>\r\n    \u2026<\/span>\r\n  charts\/<\/strong><\/pre>\n
    In diesem Ordner f\u00fchren wir in der Konsole folgenden Befehl aus:<\/span><\/p>\n
    $ helm package app-chart -d charts<\/span>\r\nSuccessfully packaged chart and saved it to: charts\/bis-app-1.tgz<\/span><\/pre>\n
    Die erstellte Datei <\/span>bis-app-1.tgz<\/code><\/span> (die 1 im Namen ist die Version des Charts) enth\u00e4lt den gesamten Helm Chart und kann so nun an einzelne Personen im Unternehmen verteilt werden.\u00a0<\/span><\/p>\n
    Gehen wir davon aus, wir haben unser Helm Chart erweitert. Dann erh\u00f6hen wir die Version des Charts in der Charts.yaml<\/code>\u00a0Datei, z.B. auf 1.1 (<\/span>version: 1.1<\/span>). Nun m\u00fcssen wir den Chart erneut packen.<\/span><\/p>\n
    $ helm package app-chart -d charts<\/span>\r\nSuccessfully packaged chart and saved it to: charts\/bis-app-1.1.tgz<\/span><\/pre>\n
    Diese neu erstellte Datei m\u00fcssten wir nun erneut an alle Personen im Unternehmen verteilen, welche bereits eine fr\u00fchere Chart Version installiert haben. Diese manuelle Verteilung des Charts ist jedoch unpraktisch und sorgt daf\u00fcr, dass alte Chart Versionen eventuell nicht geupdatet werden. Auch bei der Verwendung von CI\/CD ist ein manuelles Verteilen der Releases nicht m\u00f6glich. Daher m\u00f6chten wir uns Helm-Repositories als eine bessere L\u00f6sung anschauen, um Charts bereitzustellen.<\/span><\/p>\n
    Hierzu indizieren wir zun\u00e4chst den chart<\/code> Ordner<\/span><\/p>\n
    $ helm repo index charts<\/span><\/pre>\n
    Wir erhalten die Datei <\/span>charts\/index.yaml<\/code><\/span><\/p>\n
    <\/h2>\n
    apiVersion: v1<\/span>\r\nentries:<\/span>\r\n \u00a0bis-app:<\/span>\r\n \u00a0- apiVersion: v2<\/span>\r\n \u00a0\u00a0\u00a0appVersion: \"1\"<\/span>\r\n \u00a0\u00a0\u00a0created: \"2024-01-23T13:46:16.938718324+01:00\"<\/span>\r\n \u00a0\u00a0\u00a0description: sample nginx deployment<\/span>\r\n \u00a0\u00a0\u00a0digest: c964f1a73aa1920286359578496a52341b77d4d226ad32cd6dfdb421c59fd4cb<\/span>\r\n \u00a0\u00a0\u00a0name: bis-app<\/span>\r\n \u00a0\u00a0\u00a0type: application<\/span>\r\n \u00a0\u00a0\u00a0urls:<\/span>\r\n \u00a0\u00a0\u00a0- bis-app-1.1.tgz<\/span>\r\n \u00a0\u00a0\u00a0version: \"1.1\"<\/span>\r\n \u00a0- apiVersion: v2<\/span>\r\n \u00a0\u00a0\u00a0appVersion: \"1\"<\/span>\r\n \u00a0\u00a0created: \"2024-01-23T13:46:16.939021608+01:00\"<\/span>\r\n \u00a0\u00a0\u00a0description: sample nginx deployment<\/span>\r\n \u00a0\u00a0digest: 552c9bdf46b657dae607483912088d245c0a11b34a4ae35644c9a863ae61b10b<\/span>\r\n \u00a0\u00a0\u00a0name: bis-app<\/span>\r\n \u00a0\u00a0\u00a0type: application<\/span>\r\n \u00a0\u00a0\u00a0urls:<\/span>\r\n \u00a0\u00a0\u00a0- bis-app-1.tgz<\/span>\r\n \u00a0\u00a0\u00a0version: \"1\"<\/span>\r\ngenerated: \"2024-01-23T13:46:16.938178662+01:00\"<\/span><\/pre>\n
    Diese Datei listet alle gepackten Helm Charts in Ordner <\/span>charts<\/code><\/span> inklusive deren Metainformation auf.<\/span><\/p>\n
    Der Ordner <\/span>charts<\/code><\/span> kann nun mit einem beliebigen Webserver bereitgestellt und direkt als Helm Repository verwendet werden. Als schnelle und einfache M\u00f6glichkeit, Dateien \u00fcber einen Webserver bereitzustellen, nutzen wir f\u00fcr das Beispiel Github-Pages.<\/span><\/p>\n
    Hierzu muss der Ordner in ein Github-Repository gepusht werden und f\u00fcr das Repository Github-Pages aktiviert werden<\/a>.
    \n<\/span><\/p>\n
    Ob euer Helm Repository erreichbar ist k\u00f6nnt ihr \u00fcberpr\u00fcfen, indem ihr versucht die index.yaml<\/code> Datei von eurer Github-Page anzufragen:<\/span><\/p>\n
    $ curl https:\/\/<Username>.github.io\/<repository>\/charts\/index.yaml<\/span><\/pre>\n
    Da die Github Page \u00f6ffentlich erreichbar ist, sind auch die Helm Charts \u00f6ffentlich erreichbar. Unternehmensintern m\u00fcsste der Webserver entweder durch Zugangsdaten abgesichert werden oder nur aus dem internen Netz erreichbar sein.<\/span><\/p>\n
    Chart installieren<\/span><\/h3>\n
    Nun wollen wir den erstellten Helm Chart \u00fcber das eigene Repository installieren. Hierzu m\u00fcssen wir das neu erstellte Repository zun\u00e4chst lokal hinterlegen.<\/span><\/p>\n
    $ helm repo add bis-repo https:\/\/<Username>.github.io\/<repository>\/charts\/<\/span>\r\n\"bis-repo\" has been added to your repositories<\/span><\/pre>\n
    Mit dem folgenden Befehl kann \u00fcberpr\u00fcft werden, welche Repositories lokal hinterlegt sind:<\/span><\/p>\n
    $ helm repo list<\/span>\r\nNAME\u00a0 \u00a0 <\/span> URL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span>\r\nbis-repo<\/span> https:\/\/<Username>.github.io\/<repository>\/charts\/<\/span><\/pre>\n
    <\/h2>\n
    Mit dem hinterlegten Repository k\u00f6nnen wir nun einen Namespace erstellen und unser Helm Chart dort installieren:<\/span><\/p>\n
    $ kubectl create ns bis<\/span>\r\nnamespace\/bis created\r\n<\/span>\r\n$ helm install bis bis-repo\/bis-app -n bis<\/span>\r\nNAME: bis<\/span>\r\nLAST DEPLOYED: Tue Jan 23 14:09:25 2024<\/span>\r\nNAMESPACE: bis<\/span>\r\nSTATUS: deployed<\/span>\r\nREVISION: 1<\/span>\r\nTEST SUITE: None<\/span><\/pre>\n
    Der install<\/code> Befehl ist wie folgt aufgebaut <\/span><\/p>\n
    helm install <release-name> <repo>\/<chart>[:<chart-version>] -n <kubernetes-namespace><\/code><\/span><\/div>\n
    Wenn wir nun die einzelnen Kubernetes Ressourcen ausgeben, sehen wir, dass alles im Helm Chart Definierte erstellt wurde. Hier als Beispiel einmal die erstellten Pods und der Ingress.<\/span><\/p>\n
    $ kubectl get pod -n bis<\/span>\r\nNAME \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 READY \u00a0 STATUS\u00a0 \u00a0 RESTARTS \u00a0 AGE<\/span>\r\nbis-6ff46c7499-24bgx \u00a0 1\/1 \u00a0 \u00a0 Running \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 2m17s\r\n<\/span>\r\n$ kubectl get ingress -n bis<\/span>\r\nNAME\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 CLASS \u00a0 HOSTS \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ADDRESS\u00a0 \u00a0 \u00a0 \u00a0 PORTS \u00a0 AGE<\/span>\r\nbis-ingress \u00a0 nginx \u00a0 department1.local \u00a0 192.168.58.2 \u00a0 80\u00a0 \u00a0 \u00a0 3m50s<\/span><\/pre>\n
    Wenn wir nun die Website department1.local<\/code> aufrufen, bekommen wir folgende Antwort.<\/span><\/p>\n
    $ curl department1.local<\/span>\r\nGreeting from Department department1! Welcome on our website!<\/span><\/pre>\n
    Die angezeigte Nachricht k\u00f6nnen wir nun durch \u00dcberschreiben einiger Values unseres Helm Releases anpassen:<\/span><\/p>\n
    $ helm upgrade bis bis-repo\/bis-app -n bis --set message=\"Greetings to BIS!\" --set replicas=3<\/span>\r\nRelease \"bis\" has been upgraded. Happy Helming!<\/span>\r\nNAME: bis<\/span>\r\nLAST DEPLOYED: Tue Jan 23 14:20:55 2024<\/span>\r\nNAMESPACE: bis<\/span>\r\nSTATUS: deployed<\/span>\r\nREVISION: 2<\/span>\r\nTEST SUITE: None<\/span><\/pre>\n
    Einerseits haben wir die Replicas auf 3 gesetzt. Dadurch wurden anstelle nur eines Pods nun drei Pods gestartet.<\/span><\/p>\n
    $ kubectl get pods -n bis<\/span>\r\nNAME \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 READY \u00a0 STATUS\u00a0 \u00a0 RESTARTS \u00a0 AGE<\/span>\r\nbis-6d6549c7fb-b9wnh \u00a0 1\/1 \u00a0 \u00a0 Running \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 37s<\/span>\r\nbis-6d6549c7fb-nb68f \u00a0 1\/1 \u00a0 \u00a0 Running \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 39s<\/span>\r\nbis-6d6549c7fb-z75j4 \u00a0 1\/1 \u00a0 \u00a0 Running \u00a0 0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 40s<\/span><\/pre>\n
    Des Weiteren haben wir die Nachricht, welche vom Webserver zur\u00fcckgegeben wird, angepasst.<\/span><\/p>\n
    $ curl department1.local<\/span>\r\nGreeting from Department department1! Greetings to BIS!<\/span><\/pre>\n
    Zweite Abteilung<\/b><\/p>\n
    Jetzt wollen wir das Gleiche noch einmal f\u00fcr eine zweite Abteilung in unserem Unternehmen umsetzen. Diese soll ebenfalls eine eigene Website bekommen, welche auf demselben Kubernetes Cluster l\u00e4uft.<\/span><\/p>\n
    Hierzu erstellen wir zun\u00e4chst eine neue Datei department2-values.yaml<\/code> welche die Konfiguration f\u00fcr unser Helm Release beinhaltet.<\/span><\/p>\n
    host: department2.local<\/span>\r\ndepartment: \"department2\"<\/span>\r\nreplicas: 2<\/span><\/pre>\n
    Dann erstellen wir einen neuen Namespace und installieren den Chart f\u00fcr unsere Abteilung2<\/em>.<\/span><\/p>\n
    <\/h2>\n
    $ kubectl create ns bis2<\/span>\r\nnamespace\/bis2 created\r\n<\/span>\r\n$ helm install bis bis-repo\/bis-app -n bis2 -f department2-values.yaml<\/span>\r\nNAME: bis<\/span>\r\nLAST DEPLOYED: Tue Jan 23 14:27:25 2024<\/span>\r\nNAMESPACE: bis2<\/span>\r\nSTATUS: deployed<\/span>\r\nREVISION: 1<\/span>\r\nTEST SUITE: None<\/span><\/pre>\n
    Wir k\u00f6nnen nun beide Webseiten aufrufen.<\/span><\/p>\n
    $ curl department1.local<\/span>\r\nGreeting from Department department1! Greetings to BIS!\r\n<\/span>\r\n$ curl department2.local<\/span>\r\nGreeting from Department department2! Welcome on our website!\r\n\r\n<\/span><\/pre>\n
    Abschlie\u00dfend k\u00f6nnen wir uns von Helm noch einmal alle aktuell installierten Helm Charts anzeigen lassen<\/span><\/p>\n
    $ helm ls -A\r\nNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION\r\nbis bis 2 2024-01-23 14:20:55.470634413 +0100 CET deployed bis-app-1.1 1.1 \r\nbis bis2 1 2024-01-23 14:27:25.781652628 +0100 CET deployed bis-app-1.1 1.1<\/pre>\n
     <\/p>\n
     <\/p>\n
    Fazit
    \n<\/b><\/span><\/p>\n
    Anhand des ersten Anwendungsbeispiels, bei dem das \u00f6ffentlich zug\u00e4ngliche Helm Chart von Nextcloud auf einem Kubernetes Cluster installiert wurde, lassen sich einige der Vorteile, die Helm bietet, erkennen. Die Installation eines Charts entspricht dem geb\u00fcndelten Deployment von Kubernetes Ressourcen. Im Gegensatz zur herk\u00f6mmlichen Interaktion mit einem Cluster m\u00fcssen die Kubernetes Ressourcen nicht einzeln h\u00e4ndisch angelegt werden, sondern k\u00f6nnen \u00fcber einen einzigen Helm Command schnell und einfach auf das Cluster gebracht werden. Das Gleiche gilt f\u00fcr den Vorgang des L\u00f6schens eines Releases bei dem alle von Helm angelegten Ressourcen geb\u00fcndelt gel\u00f6scht werden. Des Weiteren kann man am ersten Anwendungsbeispiel erkennen, dass der Anwender zu keinem Zeitpunkt dazu gezwungen war, direkt mit dem Kubernetes Cluster zu interagieren. Helm schafft mit seiner Nutzerschnittstelle ein Abstraktionslevel, das den internen Aufbau und die Funktionsweise von Kubernetes vor dem Anwender versteckt. Den Entwicklern von Helm war es wichtig, dass sich Helm sowohl an mit der Funktionsweise von Kubernetes vertraute Anwender als auch an solche richtet, die \u00fcber wenig bis kaum Erfahrung und technisches Wissen im Bereich von Kubernetes verf\u00fcgen.<\/p>\n
    Am zweiten Anwendungsbeispiel kann man erkennen, dass Helm die Abdeckung verschiedener Anwendungsf\u00e4lle mit nur einem Chart erm\u00f6glicht, wodurch die Notwendigkeit f\u00fcr neue Charts entf\u00e4llt. Wir konnten problemlos zwei Webserver f\u00fcr unterschiedliche Abteilungen erstellen, indem wir lediglich Konfigurationsparameter anpassten, ohne den Code \u00e4ndern zu m\u00fcssen. Ein entscheidender Vorteil von Helm liegt zudem in seiner F\u00e4higkeit, das installierte Chart zusammen mit seiner Version auf dem Cluster zu dokumentieren. Dadurch wird eine umfassende Versionsverwaltung gew\u00e4hrleistet, die Transparenz \u00fcber den aktuellen Stand sowie potenzielle \u00c4nderungen mit einem Update oder zwischen den Deployments schafft. Diese Dokumentation erm\u00f6glicht eine klare Nachvollziehbarkeit jeder Chart Version. Des Weiteren erleichtert Helm die Reproduzierbarkeit eines bestimmten Zustands erheblich, da sowohl die Konfiguration als auch der Status des Charts als Code gespeichert werden k\u00f6nnen. Dadurch wird eine konsistente Bereitstellung und Verwaltung von Anwendungen gew\u00e4hrleistet, was wiederum die Zuverl\u00e4ssigkeit und Effizienz der Entwicklungs- und Betriebsprozesse verbessert.<\/p>\n
    Es l\u00e4sst sich festhalten, dass das Deployment von Charts \u00fcber Helm gro\u00dfe Vorteile bietet. Helm tr\u00e4gt wesentlich dazu bei, Anwendungen auf Kubernetes Clustern einfach und schnell zur Verf\u00fcgung zu stellen und spielt damit im Bereich der betrieblichen Informationssysteme eine nicht unwesentliche Rolle.<\/p>\n<\/div>\n
    \n
    <\/h2>\n
    Einzelnachweise<\/h2>\n
      \n
    1. Was ist\u00a0<\/span><\/i>Kubernetes<\/span><\/i>?<\/span><\/i>\u00a0(2022, 17. Juli).\u00a0<\/span>Kubernetes<\/span>.\u00a0<\/span>https:\/\/kubernetes.io\/de\/docs\/concepts\/overview\/what-is-kubernetes\/<\/span><\/a>\u200b<\/li>\n
    2. Helm | Helm<\/span><\/i>. (o.\u00a0D.).\u00a0<\/span>https:\/\/helm.sh\/<\/span><\/a>\u200b<\/li>\n
    3. Helm | Docs Home<\/span><\/i>. (o.\u00a0D.).\u00a0<\/span>https:\/\/helm.sh\/docs\/<\/span><\/a>\u200b<\/li>\n<\/ol>\n
       <\/p>\n
       <\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
      Helm.sh In der Welt der Containerorchestrierung ist effizientes Deployment entscheidend. Der Paket-Manager Helm selbst bezeichnet sich als: „Der beste Weg,<\/p>\n","protected":false},"author":160,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3368","post","type-post","status-publish","format-standard","hentry","category-betriebliche-informationssysteme"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3368","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/160"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=3368"}],"version-history":[{"count":38,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3368\/revisions"}],"predecessor-version":[{"id":3465,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3368\/revisions\/3465"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=3368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=3368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=3368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
    Weitere Infos zu Ingress und Ingress-Controllern in der Kubernetes Dokumentation<\/a><\/span>.<\/span><\/p>\n
    Weitere Infos zu Services in der Kubernetes Dokumentation<\/a><\/span>.<\/span><\/p>\n