1. Einleitung

Die CaaS-Plattform stellt das Bindeglied zwischen FirstSpirit und der Endanwendung des Kunden dar. Die REST-Schnittstelle empfängt Informationen und aktualisiert diese in der internen Persistenzschicht der CaaS-Plattform. Eine Aktualisierung der Daten in der Endandwendung des Kunden erfolgt durch Requests an die REST-Schnittstelle.

Die CaaS-Plattform umfasst folgende Komponenten, die als Docker-Container vorliegen:

REST-Schnittstelle (caas-rest-api)

Die REST-Schnittstelle dient sowohl der Übertragung als auch der Abfrage von Daten in das bzw. aus dem CaaS-Repository. Dafür stellt sie einen REST-Endpoint bereit, der vom CaaS Admin Interface, dem FirstSpirit-Server oder weiteren Diensten verwendet werden kann. Sie unterstützt zudem Authentifizierung und Autorisierung.

Zwischen CaaS Version 2.11 und 2.13 (inklusive) wurde die Authentifizierungs- und Autorisierungsfunktionalität durch einen separaten Security Proxy bereitgestellt.

CaaS-Repository (caas-mongo)

Das CaaS-Repository ist nicht vom Internet aus erreichbar und ist innerhalb der Plattform nur von der REST-Schnittstelle aus erreichbar. Es dient als Ablage aller Projektdaten sowie interner Konfiguration.

CaaS Admin Interface (caas-admin-webapp)

Das CaaS Admin Interface ermöglicht die Verwaltung der in den CaaS übertragenen Informationen und stellt eine einfache, webbasierte Administrationsoberfläche bereit. Dafür kommuniziert es über die REST-Schnittstelle mit dem Repository und ist selbst per HTTP(S) erreichbar.

2. Technische Voraussetzungen

Der Betrieb der CaaS-Plattform ist mit Kubernetes zu realisieren.

Sollten Sie sich nicht in der Lage fühlen, einen Kubernetes-Cluster betreiben, konfigurieren, überwachen und Betriebsprobleme der Cluster-Infrastruktur entsprechend analysieren und beheben zu können, so raten wir ausdrücklich von einem On-Premises Betrieb ab und verweisen auf unser SaaS-Angebot.

Da die CaaS-Plattform als Helm-Artefakt ausgeliefert wird, muss Helm als Client verfügbar sein.

Es ist wichtig, dass Helm auf sichere Art und Weise installiert ist. Nähere Informationen dazu sind in der Helm-Installationsanleitung enthalten.

Für die Systemvoraussetzungen konsultieren Sie bitte das technische Datenblatt der CaaS-Plattform .

3. Installation und Konfiguration

Die Einrichtung der CaaS-Plattform für den Betrieb mit Kubernetes erfolgt über den Einsatz von Helm-Charts. Diese sind Bestandteil der Auslieferung und enthalten bereits alle erforderlichen Komponenten.

Die nachfolgenden Unterkapitel beschreiben die erforderlichen Installations- und Konfigurationsschritte.

3.1. Import der Images

Die Einrichtung der CaaS-Plattform erfordert im ersten Schritt den Import der Images in Ihre zentrale Docker-Registry (z. B. Artifactory). Die Images sind in der Auslieferung in der Datei caas-docker-images-2.16.5.zip enthalten.

Die Credentials für den Zugriff des Clusters auf die Registry müssen bekannt sein.

Die für den Import notwendigen Schritte entnehmen Sie bitte der Dokumentation der von Ihnen eingesetzten Registry.

3.2. Konfiguration des Helm-Charts

Nach dem Import der Images ist die Konfiguration des Helm-Charts notwendig. Dieser ist Bestandteil der Auslieferung und in der Datei caas-2.16.5.tgz enthalten. Eine Standardkonfiguration des Charts ist bereits in der values.yaml-Datei vorgenommen. Alle Parameter, die in dieser values.yaml angegeben sind, können mit einer manuell anzulegenden custom-values.yaml durch einen spezifischen Wert überschrieben werden.

3.2.1. Authentifizierung

Alle Authentifizierungs-Einstellungen zur Kommunikation mit bzw. innerhalb der CaaS-Plattform werden im credentials-Block der custom-values.yaml festgelegt.

So finden sich hier Benutzernamen und Standard-Passwörter sowie der CaaS-Master API Key. Es wird dringend empfohlen, die Standard-Passwörter und den CaaS-Master API Key anzupassen.

Alle gewählten Passwörter müssen alphanumerisch sein. Andernfalls treten Probleme in Verbindung mit dem CaaS auf.

Der CaaS-Master API Key wird während der Installation der CaaS-Plattform automatisch angelegt und ermöglicht demnach die direkte Benutzung der REST-Schnittstelle.

3.2.2. CaaS-Repository (caas-mongo)

Die Konfiguration des Repositories umfasst zwei Parameter:

storageClass

Die Möglichkeit des Überschreibens von Parametern aus der values.yaml-Datei betrifft vor allem auch den Parameter mongo.persistentVolume.storageClass.

Aus Performance-Gründen empfehlen wir, dass das unterliegende Dateisystem der MongoDB mit XFS provisioniert ist.

clusterKey

Für den Authentifizierungsschlüssel des Mongo-Cluster wird eine Standardkonfiguration mit ausgeliefert. Der Schlüssel kann im Parameter credentials.clusterKey festgelegt werden. Es wird dringend empfohlen, für den Produktivbetrieb mit dem folgenden Befehl einen neuen Schlüssel zu erzeugen:

openssl rand -base64 756

Dieser Wert darf nur während der initialen Installation verändert werden. Wird er zu einem späteren Zeitpunkt geändert, kann dies zu einer dauerhaften Nichtverfügbarkeit der Datenbank führen, die nur noch manuell reparierbar ist.

3.2.3. Docker-Registry

Eine Anpassung der Parameter imageRegistry und imageCredentials ist notwendig, um die verwendete Docker-Registry zu konfigurieren.

Beispielkonfiguration in einer custom-values.yaml
imageRegistry: docker.company.com/e-spirit

imageCredentials:
   username: "username"
   password: "special_password"
   registry: docker.company.com
   enabled: true

3.2.4. Ingress Konfigurationen

Ingress-Definitionen steuern den eingehenden Datenverkehr auf die jeweilige Komponente und werden standardmäßig nicht von der Auslieferung erstellt. Die Parameter adminWebapp.ingress.enabled und restApi.ingress.enabled erlauben die Ingress-Konfiguration für die REST-Schnittstelle und das CaaS Admin Interface.

Die Ingress-Defintionen des Helm-Charts setzen den NGINX Ingress Controller voraus, da Annotationen dieser konkreten Implementierung verwendet werden. Sollten Sie eine abweichende Implementierung einsetzen, so müssen Sie die Annotationen der Ingress-Definitionen in Ihrer custom-values.yaml-Datei entsprechend an Ihre Gegebenheiten anpassen.

Ingress-Erzeugung in einer custom-values.yaml
adminWebapp:
   ingress:
      enabled: true
      hosts:
         - caas-webapp.company.com

restApi:
   ingress:
      enabled: true
      hosts:
         - caas.company.com

Sind die Einstellungsmöglichkeiten für den spezifischen Anwendungsfall nicht ausreichend, lässt sich der Ingress auch selbst eigenständig erzeugen. In diesem Fall ist der entsprechende Parameter auf den Wert enabled: false zu setzen. Das folgende Codebeispiel bietet eine Orientierung für die Definition.

Ingress-Definition für die REST-Schnittstelle
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   labels:
   name: caas
spec:
   rules:
      - http:
      paths:
      - backend:
         serviceName: caas-rest-api
         servicePort: 80
   host: caas-rest-api.mydomain.com

3.2.5. Preview-CaaS

Der Preview-CaaS dient zur Vorschau von nicht freigegebenen Inhalten unter Vermeidung einer Vermischung mit dem Freigabe-Stand. Ist die Funktionalität eines Preview-CaaS gewünscht, so kann sie über zwei Wege realisiert werden:

  • es wird eine separate Instanz der CaaS-Plattform aufgesetzt, welche unabhängig von der Instanz für freigegebene Inhalte betrieben wird

  • für die CaaS-Plattform wird in den Helm-Charts der Preview-CaaS-Ingress aktiviert

Dieses Kapitel behandelt im Folgenden die Umsetzung mittels Preview-CaaS-Ingress.

Konfiguration

Das Helm-Chart ermöglicht die Konfiguration einer zusätzlichen Ingress-Definition, um die Funktionalität des Preview-CaaS abzubilden, ohne jedoch eine zweite CaaS-Plattform deployen zu müssen. Hierzu werden die gleichen Parameter konfiguriert, die auch bei der Definition des Ingress für die REST-Schnittstelle verfügbar sind:

restApi:
  ingressPreview:
    enabled: false
    # you can activate usage of the cert-manager for this ingress to automatically issue SSL certificates see below (certManager:) for more details
    certManager:
      enabled: false
    #if you want to manage tls on your own, you can add the relevant data here. See https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for more info.
    #tls:
    #  - secretName: caas-rest-api-preview-tls
    #    hosts:
    #      - caas-preview
    hosts:
      - caas-preview
    annotations:
      kubernetes.io/ingress.class: "nginx"
      nginx.ingress.kubernetes.io/rewrite-target: /
      nginx.ingress.kubernetes.io/proxy-body-size: "100m"
      #We're setting cors defaults as described in https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors here.
      #If you want to customize cors settings, please take a look at the link and add your custom entries here.
      nginx.ingress.kubernetes.io/enable-cors: "true"
      #nginx.org/hsts: false
      #ingress.kubernetes.io/ssl-redirect: false
    configurationSnippet: |-
      set $caas_protocol 'https';
      if ($https = "") {
        set $caas_protocol 'http';
      }
      if ($request_uri ~ ^/([^/]+)(/.*)?$) {
        return 308 $caas_protocol://{{ index .Values.restApi.ingress.hosts 0 -}}/$1Preview$2;
      }
      return 308 $caas_protocol://{{ index .Values.restApi.ingress.hosts 0 -}}/;

Das Feature wird über den Parameter ingressPreview.enabled aktiviert. Zudem ist in dem Parameter ingressPreview.hosts die gewünschte URL, unter der der Preview-CaaS erreicht werden kann, anzugeben.

Sofern SSL bereits vor dem Preview-CaaS-Ingress terminiert wird, sind möglicherweise Anpassungen des Parameters configurationSnippet an Ihre Netwerkkonfiguration nötig.

Funktionsweise

Der Ingress des Preview-CaaS leitet alle Requests, die an den Preview-CaaS gerichtet sind, mittels HTTP-Redirect (Response Code 308) an die reguläre CaaS-Plattform um und nimmt gleichzeitig ein URL-Rewriting auf Ebene der CaaS-Datenbank vor. Der Datenbankname wird in diesen Fällen um das Suffix Preview ergänzt.

Bitte stellen Sie sicher, dass Ihr HTTP-Client die Eigenschaften follow redirects und redirect authentication unterstützt und aktiviert hat. Andernfalls wird die HTTP-Weiterleitung nicht oder ohne Authorization-Header durchgeführt.

Beispiel: Requests aus einem FirstSpirit-Projekt mit dem Namen MyProject, welche über den Preview-CaaS-Ingress laufen, werden daher auf die CaaS-Datenbank MyProjectPreview umgeleitet.

Alle anderen Requests aus diesem Projekt, welche vom regulären Ingress der REST-Schnittstelle bedient werden, werden nicht beeinflusst. So werden Konflikte zwischen freigegebenen und nicht freigegebenen Inhalten aus demselben Projekt vermieden.

Es kann zu Daten-Konflikten zwischen FirstSpirit-Projekten kommen, falls ein Projektname auf Preview endet und ein zweites Projekt mit aktiviertem Preview-CaaS genauso heißt wie das erste Projekt, aber ohne Preview Suffix.

Beispiel:

  • Projekt 1: MyProjectPreview

    • Der Name der CaaS-Datenbank wird zu MyProjectPreview für freigegebene Inhalte (Konflikt)

  • Projekt 2: MyProject

    • Der Name der CaaS-Datenbank wird zu MyProject für freigegebene Inhalte

    • Der Name der CaaS-Datenbank wird zu MyProjectPreview für nicht freigegebene Inhalte (Konflikt)

3.3. Installation des Helm-Charts

Nach der Konfiguration des Helm-Charts ist dieser in den Kubernetes-Cluster zu installieren. Die Installation erfolgt über die nachfolgenden Befehle, die im Verzeichnis des Helm-Charts ausgeführt werden müssen.

Installation des Chart
kubectl create namespace caas
helm install RELEASE_NAME . --namespace=caas --values /path/to/custom-values.yaml

Der Name des Release kann frei gewählt werden.

Soll der Namespace einen anderen Namen tragen, müssen Sie die Angaben innerhalb der Befehle entsprechend ersetzen.

Soll ein bereits existierender Namespace verwendet werden, so entfällt die Erstellung und der gewünschte Namespace ist innerhalb des Installationsbefehls anzugeben.

Da die Container zunächst von der verwendeten Image-Registry heruntergeladen werden, kann die Installation einige Minuten in Anspruch nehmen. Im Idealfall sollte eine Zeitspanne von fünf Minuten jedoch nicht überschritten werden, bevor die CaaS-Plattform einsatzfähig ist.

Der Status der einzelnen Komponenten ist mit dem folgenden Befehl abrufbar:

kubectl get pods --namespace=caas

Sobald alle Komponenten den Status Running besitzen, ist die Installation abgeschlossen.

NAME                                 READY     STATUS        RESTARTS   AGE
caas-admin-webapp-1055845989-0s4pg   1/1       Running       0          5m
caas-mongo-0                         2/2       Running       0          4m
caas-mongo-1                         2/2       Running       0          3m
caas-mongo-2                         2/2       Running       0          1m
caas-rest-api-1851714254-13cvn       1/1       Running       0          5m
caas-rest-api-1851714254-13cvn       1/1       Running       0          4m
caas-rest-api-1851714254-xs6c0       1/1       Running       0          4m

3.4. TLS

Die Kommunikation der CaaS-Plattform nach außen ist standardmäßig nicht verschlüsselt. Soll sie per TLS geschützt werden, existieren zwei Konfigurationsmöglichkeiten:

Verwendung eines offiziell signierten Zertifikats

Für die Verwendung eines offiziell signierten Zertifikats wird ein TLS-Secret benötigt, das zunächst zu erzeugen ist. Dieses muss die Schlüssel tls.key und das Zertifikat tls.crt enthalten.

Die für die Erzeugung des TLS-Secrets notwendigen Schritte sind in der Kubernetes Ingress-Dokumentation beschrieben.

Automatisierte Zertifikatsverwaltung

Alternativ zur Verwendung eines offiziell signierten Zertifikats ist es möglich, die Verwaltung mithilfe des Cert-Managers zu automatisieren. Dieser ist innerhalb des Clusters zu installieren und übernimmt die Erzeugung, Verteilung sowie Aktualisierung aller benötigten Zertifikate. Die Konfiguration des Cert-Managers ermöglicht dabei beispielsweise die Verwendung und automatische Erneuerung von Let’s-Encrypt-Zertifikaten.

Die notwendigen Schritte zur Installation sind in der Cert-Manager-Dokumentation erläutert.

3.5. Skalierung

Um die in den CaaS übertragenen Informationen schnell verarbeiten zu können, muss die CaaS-Plattform jederzeit eine optimale Lastverteilung gewährleisten. Aus diesem Grund sind die REST-Schnittstelle und die Mongo-Datenbank skalierbar und hinsichtlich des Aspekts der Ausfallsicherheit bereits so konfiguriert, dass jeweils mindestens drei Instanzen deployed werden. Diese Mindestanzahl von Instanzen ist insbesondere für den Mongo-Cluster zwingend erforderlich.

REST-Schnittstelle

Die Skalierung der REST-Schnittstelle erfolgt mithilfe eines Horizontal Pod Autoscalers. Dessen Aktivierung sowie Konfiguration ist in der custom-values.yaml-Datei vorzunehmen, um die in der values.yaml-Datei definierten Standard-Werte zu überschreiben.

Standard-Konfiguration der REST-Schnittstelle
restApi:
  horizontalPodAutoscaler:
    enabled: false
    minReplicas: 3
    maxReplicas: 9
    targetCPUUtilizationPercentage: 50

Der Horizontal Pod Autoscaler ermöglicht die Herunter- bzw. Heraufskalierung der REST-Schnittstelle in Abhängigkeit der aktuellen CPU-Last. Der Parameter targetCPUUtilizationPercentage gibt dabei an, ab welchem Prozentwert eine Skalierung stattfinden soll. Gleichzeitig definieren die Parameter minReplicas und maxReplicas die minimale und maximal Anzahl der möglichen REST-Schnittstellen-Instanzen.

Der Schwellwert für die CPU-Last ist mit Bedacht zu wählen:
Ist ein zu niedriger Prozentwert gewählt, skaliert die REST-Schnittstelle im Fall ansteigender Last zu früh hoch. Ist ein zu hoher Prozentwert gewählt, kann die Skalierung der REST-Schnittstelle im Fall ansteigender Last nicht schnell genug erfolgen.

Eine falsche Konfiguration kann somit die Stabilität des Systems gefährden.

Die offizielle Kubernetes Horizontal Pod Autoscaler-Dokumentation sowie die in ihr aufgeführten Beispiele enthalten weitere Informationen zum Einsatz eines Horizontal Pod Autoscalers.

Mongo-Datenbank

Im Gegensatz zur REST-Schnittstelle ist die Skalierung der Mongo-Datenbank nur manuell möglich. Sie kann daher nicht automatisch mithilfe eines Horizontal Pod Autoscalers durchgeführt werden.

Die Skalierung der Mongo-Datenbank erfolgt über den Parameter replicas. Dieser ist in die custom-values.yaml-Datei einzutragen, um den in der values.yaml-Datei definierten Standard-Wert zu überschreiben.

Für den Betrieb des Mongo-Clusters sind mindestens drei Instanzen notwendig, da sonst kein Primary-Knoten zur Verfügung steht und die Datenbank nicht schreibbar ist. Unterschreitet die Anzahl verfügbarer Instanzen einen Wert von 50% der konfigurierten Instanzen, kann kein Primary-Knoten mehr gewählt werden. Dieser ist für die Funktionsfähigkeit der REST-Schnittstelle jedoch unerlässlich.

Das Kapitel Consider Fault Tolerance der MongoDB-Dokumentation beschreibt, wie viele Knoten explizit ausfallen können, bis die Bestimmung eines neuen Primary-Knoten unmöglich ist. Die in der Dokumentation enthaltenen Informationen sind bei der Skalierung der Installation zu berücksichtigen.

Weitere Informationen zur Skalierung und Replizierung der Mongo-Datenbank sind in den Kapiteln Replica Set Deployment Architectures und Replica Set Elections enthalten.

Definition des Replica-Parameters
mongo:
  replicas: 3

Ein Herunterskalieren der Mongo-Datenbank ist nicht ohne einen direkten Eingriff möglich und erfordert eine manuelle Verkleinerung des Replicasets der Mongo-Datenbank. Die MongoDB-Dokumentation beschreibt die dafür notwendigen Schritte.

Ein solcher Eingriff erhöht das Risiko eines Ausfalls und wird daher nicht empfohlen.

Übernahme der Konfiguration

Die aktualisierte custom-values.yaml-Datei muss nach den Konfigurationsänderungen für die REST-Schnittstelle bzw. die Mongo-Datenbank mit dem folgenden Befehl übernommen werden.

Upgrade-Befehl
helm upgrade -i RELEASE_NAME path/to/caas-<VERSIONNUMBER>.tgz --values /path/to/custom-values.yaml

Der Release-Name ist mit dem Befehl helm list --all-namespaces ermittelbar.

3.6. Monitoring

Die CaaS-Plattform ist eine Microservice-Architektur und setzt sich daher aus unterschiedlichen Komponenten zusammen. Um ihren Status jederzeit ordnungsgemäß überwachen und im Fehlerfall kurzfristig reagieren zu können, ist für den Betrieb mit Kubernetes die Einbindung in ein clusterweites Monitoring zwingend notwendig.

Die CaaS-Plattform ist für ein Monitoring mit Prometheus-Operator bereits vorkonfiguriert, da dieses Szenario im Kubernetes-Umfeld weit verbreitet ist. Es sind sowohl Prometheus-ServiceMonitors zum Erfassen von Metriken, Prometheus-Alerts zur Benachrichtigung bei Problemen als auch vordefinierte Grafana-Dashboards zur Visualisierung der Metriken enthalten.

3.6.1. Voraussetzungen

Es ist unerlässlich, ein Monitoring und eine Persistenz der Logs für den Kubernetes-Cluster einzurichten. Ohne diese Voraussetzungen sind im Fehlerfall kaum Analyse-Möglichkeiten gegeben und dem Technical Support fehlen wichtige Informationen.

Metriken

Zur Installation des Prometheus-Operator nutzen Sie bitte das offizielle Helm-Chart, so dass darauf aufbauend das Cluster-Monitoring eingerichtet werden kann. Weitere Informationen entnehmen Sie bitte den entsprechenden Dokumentationen.

Sollten Sie keinen Prometheus-Operator betreiben, so müssen Sie die Prometheus-ServiceMonitors sowie die Prometheus-Alerts abschalten.

Logging

Mit dem Einsatz von Kubernetes ist es möglich, diverse Container bzw. Dienste automatisiert sowie skalierbar bereitzustellen. Damit die Logs in einem solchen dynamischen Umfeld auch nach der Beendung einer Instanz bestehen bleiben, muss eine Infrastruktur eingebunden werden, die diese zuvor persistiert.

Daher empfehlen wir die Verwendung eines zentralen Logging-Systems, wie zum Beispiel des Elastic-Stacks. Der Elastic- bzw. ELK-Stack ist eine Sammlung von Open-Source Projekten, die dabei helfen, Log-Daten in Echtzeit zu persistieren, durchsuchen sowie analysieren.

Auch hierfür können Sie für die Installation auf ein bestehendes Helm-Chart zurückgreifen.

3.6.2. Prometheus-ServiceMonitors

Das Deployment des von der CaaS-Plattform mitgelieferten ServiceMonitors für die REST-Schnittstelle und die Mongo-Datenbank, wird über die custom-values.yaml-Datei des Helm-Charts gesteuert.

Der Zugriff auf die Metriken der REST-Schnittstelle ist mittels HTTP Basic Auth und der Zugriff auf die Metriken der MongoDB über einen entsprechenden MongoDB-Benutzer gesichert. Die jeweiligen Zugangsdaten sind im Credentials-Block der values.yaml-Datei des Helm-Charts enthalten.

Bitte passen Sie die Zugangsdaten aus Sicherheitsgründen in ihrer custom-values.yaml-Datei an.

Typischerweise ist Prometheus so konfiguriert, dass nur ServiceMonitors mit bestimmten Labels berücksichtigt werden. Die Labels können daher in der custom-values.yaml-Datei konfiguriert werden und gelten für alle ServiceMonitors des CaaS Helm-Charts. Des Weiteren ermöglicht der Parameter scrapeInterval eine Definition der Häufigkeit, mit welcher die jeweiligen Metriken abgerufen werden.

monitoring:
  prometheus:
    # Prometheus service monitors will be created for enabled metrics. Each Prometheus
    # instance has a configured serviceMonitorSelector property, to be able to control
    # the set of matching service monitors. To allow defining matching labels for CaaS
    # service monitors, the labels can be configured below and will be added to each
    # generated service monitor instance.
    metrics:
      serviceMonitorLabels:
        release: "prometheus-operator"
      mongo:
        enabled: true
        scrapeInterval: "30s"
      caas:
        enabled: true
        scrapeInterval: "30s"

Die Metriken der MongoDB werden über einen Sidecar-Container bereitgestellt und mit Hilfe eines separaten Datenbank-Benutzers abgerufen. Die Konfiguration des Datenbank-Benutzers können Sie im credentials-Block der custom-values.yaml vornehmen. Der Sidecar-Container ist mit folgender Standard-Konfiguration hinterlegt:

mongo:
  metrics:
    image: mongodb-exporter:0.11.0
    syncTimeout: 1m

3.6.3. Prometheus-Alerts

Das Deployment der von der CaaS-Plattform mitgelieferten Alerts wird über die custom-values.yaml-Datei des Helm-Charts gesteuert.

Typischerweise ist Prometheus so konfiguriert, dass nur Alerts mit bestimmten Labels berücksichtigt werden. Die Labels können daher in der custom-values.yaml-Datei konfiguriert werden und gelten für alle Alerts des CaaS Helm-Charts:

monitoring:
  prometheus:
    alerts:
      prometheusRuleLabels:
        app: "prometheus-operator"
        release: "prometheus-operator"
      caas:
        enabled: true

3.6.4. Grafana-Dashboards

Das Deployment der von der CaaS-Plattform mitgelieferten Grafana-Dashboards wird über die custom-values.yaml-Datei des Helm-Charts gesteuert.

Typischerweise ist der Grafana Sidecar Container so konfiguriert, dass nur Configmaps mit bestimmten Labels und in einem definierten Namespace berücksichtigt werden. Die Labels der Configmap sowie der Namespace, in welchen diese deployed wird, können daher in der custom-values.yaml-Datei konfiguriert werden:

monitoring:
  grafana:
    dashboards:
      enabled: true
      configmapNamespace: ""
      configMapLabels: {}

4. Entwicklungsumgebung

Während Kubernetes die Basis aller produktiven Installationen bildet, können für Entwicklungsszenarien auch Docker oder Minikube genutzt werden.

Der Betrieb von Minikube unter Windows ist aktuell als experimentell gekennzeichnet und nicht in jeder Situation stabil.

Dieses Kapitel beschreibt die Umsetzung mit Docker.

Für die lokale Entwicklungsumgebung enthält die CaaS-Auslieferung die folgenden zwei Zip-Dateien:

  • caas-docker-images-2.16.5.zip

  • caas-docker-configuration-2.16.5.zip

Diese beinhalten zum einen die benötigten Docker-Images und zum anderen die benötigte Konfiguration des Docker Compose-Stacks.

Importieren Sie zunächst die Docker-Images in Ihre lokale Docker-Registry. Führen Sie dafür je nach Betriebssystem entweder das Skript install.cmd oder install.sh aus. Das Skript ist Teil der ZIP-Datei mit den Docker-Images.

Nach der Durchführung der in den folgenden Absätzen beschriebenen Konfigurationen kann die Docker Compose-Konfiguration mit dem Befehl docker-compose config überprüft und mittels docker-compose up gestartet werden.

Weitere Parameter zur Steuerung der CaaS-Plattform per Docker Compose können Sie der Docker Compose Dokumentation entnehmen.

Ressourcenlimits

Falls Sie die in der Datei docker-compose.yml hinterlegten Ressourcenlimits anpassen möchten, so beachten Sie bitte, dass die Werte der Java-Optionen Xms und Xmx jeweils niedriger sein müssen als die Werte der Parameter mem_reservation und mem_limit. Um wie viel niedriger die Werte einzustellen sind, hängt vom konkreten Lastszenario ab. Es wird ein Wert von mindestens 76 MiB für alle Komponenten empfohlen.

Authentifizierung

Das in der Auslieferung enthaltene Verzeichnis Configuration beinhaltet die Konfigurationsdatei caas-docker.env. Sie enthält alle sicherheitsrelevanten Authentifizierungsdaten, die über die Container hinweg geteilt werden.

Alle in dieser Datei gewählten Passwörter müssen alphanumerisch sein. Andernfalls treten Probleme in Verbindung mit dem CaaS auf.

CaaS Admin Interface

Das CaaS Admin Interface besitzt die Konfigurationsdatei env.js, die im Verzeichnis Configuration der Auslieferung enthalten ist. Die Datei enthält verschiedene Parameter, aus denen sich die URL der REST-Schnittstelle zusammensetzt:

Konfigurationsdatei env.js
(function (window) {
  window.__caas_config = window.__caas_config || {};
  window.__caas_config.host = 'http://CHANGE_ME';
  window.__caas_config.port = '8080';
  window.__caas_config.path = '/';
}(this));

Es ist zwingend der Parameter window.__caas_config.host anzupassen, welcher definiert, unter welchem Hostnamen die REST-Schnittstelle zu erreichen ist. Dabei ist zu beachten, dass der eingetragene Host für alle Benutzer des CaaS Admin Interfaces erreichbar sein muss. Für die lokale Entwicklung sollte daher entsprechend localhost verwendet werden

5. REST-Schnittstelle

5.1. Speicherung von Inhalten

Über die REST-Schnittstelle lassen sich Inhalte über HTTP verwalten und werden in sogenannten Collections abgelegt, die Datenbanken unterstellt sind. Es gilt dabei das folgende dreiteilige URL-Schema:

http://Servername:Port/Database/Collection/Document

Binäre Inhalte (Medien) bilden insofern eine Ausnahme, als dass sie in sogenannten Buckets gespeichert werden. Die zugehörigen Collections enden immer mit das Suffix .files:

http://Servername:Port/Database/MediaCollection.files/Media

5.2. Authentifizierung

Jede Anfrage an die REST-Schnittstelle muss einen HTTP-Header in der Form Authorization: apikey="<UUID>" enthalten. Als Wert von apikey wird eine UUID erwartet, die der CaaS-Plattform als API Key bekannt ist.

Die API Keys steuern die Zugriffsrechte auf Projekte und können im CaaS Admin Interface definiert werden. Eine Anfrage, die keinen oder einen fehlerhaften Header besitzt, wird daher abgewiesen.

5.3. HAL-Format

Die Schnittstelle liefert alle Ergebnisse im HAL-Format zurück. Es handelt sich bei ihnen somit nicht um schlichte Rohdaten, wie zum Beispiel traditionell unstrukturierte Inhalte im JSON-Format.

Das HAL-Format bietet den Vorteil einer einfachen, aber mächtigen Strukturierung. Neben den geforderten Inhalten enthalten die Ergebnisse zusätzliche Meta-Informationen zur Struktur dieser Inhalte.

Beispiel

{  "_size": 5,
   "_total_pages": 1,
   "_returned": 3,
   "_embedded": { CONTENT }
}

In diesem Beispiel wurde eine gefilterte Abfrage abgesetzt. Ohne die genauen Inhalte zu kennen, ist ihre Struktur aufgrund der Meta-Informationen direkt ablesbar. Die REST-Schnittstelle liefert an dieser Stelle aus einer Menge von fünf Dokumenten drei den Filterkriterien entsprechende Ergebnisse zurück und stellt diese auf einer einzigen Seite dar.

Handelt es sich bei einem angefragten Element um ein Medium, ermittelt die URL lediglich dessen Metadaten. Das HAL-Format enthält entsprechende Links, welche auf die URL mit den eigentlichen Binärdaten verweisen. Weitere Informationen entnehmen Sie bitte der Dokumentation.

5.4. Einsatz von Filtern

Filter kommen immer dann zum Einsatz, wenn Dokumente nicht über ihre Id, sondern über deren Inhalt ermittelt werden sollen. Auf diesem Weg lassen sich sowohl einzelne als auch mehrere Dokumente abrufen.

Die Abfrage aller englischsprachiger Dokumente aus der Collection products besitzt beispielsweise folgenden Aufbau:

http://Servername:Port/Database/products?filter={fs_language:"EN"}

Über dieses Beispiel hinaus existieren weitere Filtermöglichkeiten. Weitere Informationen hierzu finden Sie in der Query-Dokumentation.

6. CaaS Admin Interface

Das CaaS Admin Interface dient der Verwaltung der übertragenen Inhalte und bietet dafür eine einfache, webbasierte Administrationsoberfläche an. Diese gliedert sich in die Bereiche Projects, Browser und API Keys (vgl. Abbildung CaaS Admin Interface).

Beim ersten Aufruf der Anwendung muss sich der Benutzer mit den während der Installation gewählten Zugangsdaten authentifizieren. Nach einer validen Eingabe wird der Benutzer automatisch auf die Administrationsoberfläche weitergeleitet. Eine erneute Authentifizierung ist erst nach einer expliziten Abmeldung oder nach dem Ablauf einer Sitzung erforderlich.

home
Abbildung 1. CaaS Admin Interface

6.1. Projekte

Innerhalb des Bereichs Projects wird eine Liste aller ermittelten Projekte angezeigt (vgl. Abbildung Projects). Neben dem Projektnamen befindet sich zu jedem Eintrag in der Liste ein roter Button, mit dem der Anwender das jeweilige Projekt löschen kann. Derselbe Button wird auch vor jeder Collection dargestellt. Die Übersicht der Collections des Projekts erscheint beim Anklicken des Projektnamens. Jeder Eintrag enthält neben dem Namen der Collection eine Information über die Anzahl der in ihr enthaltenen Dokumente.

Weder ein gelöschtes Projekt noch eine gelöschte Collection kann über das CaaS Admin Interface wiederhergestellt werden. Der Benutzer muss das Löschen daher zuvor bestätigen.

projects
Abbildung 2. Projects

6.2. Browser

Der Browser bietet eine Übersicht aller in die CaaS-Plattform übertragenen Projekte, ihrer Collections und den in ihnen enthaltenen Dokumenten. Er ermöglicht darüber hinaus direkte Anfragen an die REST-Schnittstelle.

browser selected
Abbildung 3. Übersicht über den Browser

Nach einem Klick auf ein Projekt erscheint eine Liste zugehöriger Collections. Eine Tabelle von Dokumenten blendet sich wiederum nach der Auswahl einer Collection ein (vgl. Abbildung Übersicht über den Browser). Die alphabetisch nach DOCUMENT ID sortierte Tabelle stellt nur einige Metadaten des Dokuments dar, namentlich die DOCUMENT ID, die REVISION ID, die LAST DOCUMENT CHANGES, den FIRSTSPIRIT OBJECT TYPE und das GENERATION DATE.

Das komplette Dokument (das JSON) wird bei einem Klick auf eine Zeile sichtbar.

browser json
Abbildung 4. JSON eines Dokuments

Enthält eine Collection sehr viele Dokumente, so werden die Ergebnisse auf mehrere Seiten aufgeteilt.

6.2.1. Eigene Abfrage absetzen

Eine eigene Abfrage lässt sich direkt über das Textfeld Query realisieren.

browser query
Abbildung 5. Query-Feld

Der Aufbau der Query sieht folgendermaßen aus:

Projectname/Collection?filter= {key:"value"}

Eine Query, welche alle englischen Dokumente einer Collection content innerhalb des Projekts MithrasEnergy auflistet, sähe folgendermaßen aus:

MithrasEnergy/content?filter={fs_language:"EN"}

Diese Beispiel-Query lässt sich außerdem über den Show Example-Link im CaaS Admin Interface ausgeben.

browser query selected elements
Abbildung 6. Ausgewähltes Projekt mit Collection

Ist eine eigene Abfrage auf der momentan selektierten Collection gewünscht, so lässt sich der aktuelle Pfad mit Hilfe des Apply XY to query-Links (vgl. Abbildung Query-Feld) übernehmen. Es müssen dann nur noch entsprechende Parameter ergänzt werden.

Eine Übersicht über die möglichen Filter ist auf der folgenden Seite zu finden: https://restheart.org/learn/query-documents/#filtering

Es werden - auch bei der eigenen Abfrage - automatisch Parameter für das Paging angehängt. Diese selbst anzuhängen, führt zu einer fehlerhaften Anfrage an die REST-Schnittstelle.

6.3. API Keys

Für jedes Projekt lassen sich API Keys definieren, die den Zugriff auf das Projekt über die REST-Schnittstelle ermöglichen. Standardmäßig besitzt ein API Key keine Rechte. Diese müssen daher zunächst entsprechend gesetzt werden, um den Zugriff zu gewährleisten (vgl. Abbildung API Keys).

API Keys werden im System gecached. Es kann also vorkommen, dass geänderte Rechte bereits bestehender API Keys erst mit einer kurzen Zeitverzögerung Auswirkungen haben.

api keys
Abbildung 7. API Keys

Die API Keys werden in einer vierspaltigen Tabelle aufgelistet:

API Key

Die Spalte enthält neben dem technischen Key (eine UUID) den bei der Erzeugung vergebenen Namen sowie eine optionale Beschreibung. Sowohl der Name als auch die Beschreibung können nachträglich per Inline-Bearbeitung verändert werden. Mit Hilfe des Keys wird ein Zugriff auf die ausgewählten Projekte gewährt. Vor jedem Key wird außerdem ein roter Button angezeigt, der die Löschung des jeweiligen Keys ermöglicht.

PROJECT

Die Spalte enthält für jeden API Key eine Liste aller Projekte, für die er Rechte besitzt. Über die Schaltfläche + Add Project unterhalb einer solchen Liste können weitere Projekte ergänzt werden. Im Gegensatz dazu dient der rote Button vor jedem Projektnamen dazu, das jeweilige Projekt aus der Auswahl zu entfernen und dem API Key so den Zugriff zu entziehen.

READ / WRITE

Die beiden Spalten zeigen an, ob der API Key lesenden bzw. schreibenden Zugriff auf das jeweilige Projekt besitzt. Über die Schieberegler lassen sich die Rechte unabhängig voneinander setzen oder entfernen.

Diese und weitere Funktionen werden in den folgenden Unterkapiteln detaillierter beschrieben.

6.3.1. Filtern der angezeigten API Keys

Bei einer hohen Anzahl von API Keys und Projekten kann es vorkommen, dass nicht alle API Keys bzw. Projekte von Interesse sind und die Übersicht unnötig vergrößern. Um die API Keys-Übersicht zu filtern, befinden sich über der Liste deshalb zwei Eingabekomponenten: Filter Projects und Show unused API Keys.

Wenn ein Projekt in Filter Projects ausgewählt ist, werden API Keys mit Rechten auf diesem Projekt in der Übersicht angezeigt. Andernfalls werden die entsprechenden API Keys ausgeblendet.

Standardmäßig sind in Filter Projects alle Einträge ausgewählt, so dass die Übersicht alle API Keys enthält, die auf mindestens einem Projekt Rechte besitzen. Dies bedeutet gleichzeitig, dass API Keys, die auf keinem Projekt Rechte besitzen, standardmäßig ausgeblendet sind. Aus diesem Grund gibt es die Schaltfläche Show unused API Keys, mit der ebendiese Keys ein- bzw. ausgeblendet werden können.

Mit dem Eintrag All Projects lassen sich die API Keys anzeigen, die auf allen und nicht nur einzelnen Projekten Zugriffsrechte besitzen. Der Eintrag entspricht explizit nicht der Anzeige aller Projekte.

6.3.2. Anlegen eines neuen API Keys

Zum Anlegen eines neuen API Keys existiert ein spezieller Dialog (siehe Abbildung Dialog zum Hinzufügen eines neuen API Keys). Dieser wird durch einen Klick auf die Schaltfläche +Add API Key aufgerufen.

new api key
Abbildung 8. Dialog zum Hinzufügen eines neuen API Keys

Innerhalb des Dialogs ist für den zu erzeugenden API Key zuerst ein Name zu bestimmen. Darüber hinaus kann eine optionale Beschreibung hinzugefügt werden. Durch einfaches Anklicken lässt sich der Key sowohl allen als auch einzelnen Projekten zuordnen. Die ausgewählten Elemente werden grün hinterlegt und können durch einen weiteren Klick wieder deselektiert werden. Soll der Vorgang abgebrochen und alle Eingaben verworfen werden, ermöglicht dies der Button Cancel. Andernfalls speichert der Button Save die getroffene Auswahl und generiert einen neuen API Key.

Ein weiterer Dialog informiert den Anwender anschließend über die erfolgreiche Erstellung des neuen API Keys, der automatisch in die Übersicht einsortiert wird (vgl. Abbildung Bestätigungsdialog).

api key created
Abbildung 9. Bestätigungsdialog

API Keys ohne Projektzuordnung sind in der Übersichtsliste standardmäßig ausgeblendet. Wurde für den neuen API Key bei der Erstellung keine Auswahl getroffen, ist er in der Übersicht daher nicht sichtbar. Die Schaltfläche Show unused API Keys ermöglicht jedoch die Einblendung.

6.3.3. Erteilung von Rechten

Ein API Key besitzt initial keinerlei Rechte, sondern lediglich eine Projektzuordnung. Dies bedeutet, dass die Schieberegler in den Spalten Read und Write auf der Übersichtsseite zunächst den Status OFF besitzen. Mit den Schiebereglern lassen sich die Rechte unabhängig voneinander setzen oder entfernen.

Soll ein API Key Zugriff auf weitere Projekte erhalten, so können diese per Auswahldialog hinzugefügt werden. Der Dialog öffnet sich über den Button + Add Project. Er listet lediglich die Projekte auf, die dem API Key bisher nicht zugewiesen sind.

API Keys ohne Projektzuordnung sind in der Übersichtsliste standardmäßig ausgeblendet. Die Schaltfläche Show unused API Keys ermöglicht jedoch ihre Einblendung.

Es besteht die Möglichkeit, einen API Key sowohl allen als auch gleichzeitig spezifischen Projekten zuzuordnen (vgl. Abbildung Rechtevergabe ). In diesem Fall ist zu beachten, dass die Rechte nicht additiv sind. Dies bedeutet, dass die für ein spezfisches Projekt gesetzten Rechte stets die allgemeine Definition überschreiben.

Beispiel

In der nachfolgenden Abbildung besitzt ein API Key das Leserecht auf alle Projekte. Für das Projekt MithrasEnergy verfügt er jedoch lediglich über das Schreibrecht. Der Key besitzt somit auf das Projekt MithrasEnergy ausschließlich schreibenden Zugriff, während er alle anderen Projekte nur lesen kann.

interface permissions
Abbildung 10. Rechtevergabe

6.3.4. Entzug von Rechten

Auf der Übersichtsseite wird für jeden API Key eine Liste der ihm zugeordneten Projekte angezeigt. Jedes dieser Projekte besitzt außerdem zwei Schieberegler (vgl. Abbildung Rechte eines API Keys). Sie definieren, ob der API Key über lesenden bzw. schreibenden Zugriff auf das jeweilige Projekt verfügt. Die beiden Rechte können unabhängig voneinander gesetzt bzw. entfernt werden. Das Umschalten eines Schiebereglers auf den Status OFF entzieht dem Key das entsprechende Recht für das zugehörige Projekt.

key permissions
Abbildung 11. Rechte eines API Keys

Darüber hinaus besteht die Möglichkeit, einem API Key nicht nur ein einzelnes Recht, sondern den gesamten Zugriff auf ein Projekt zu entziehen. Dafür muss es über den roten Button, der vor jedem Projektnamen sichtbar ist, aus der dem Key zugehörigen Projektliste gelöscht werden.

Wurde ein Projekt versehentlich aus der Projektliste des API Keys entfernt, lässt es sich ganz einfach über den Button + Add Project wieder hinzufügen.

add projects panel
Abbildung 12. Hinzufügen von Projekten zu einem API Key

Ein ebensolcher Lösch-Button wird auch vor jedem API Key angezeigt. Durch die Löschung wird der Key aus der Übersicht entfernt. Er verliert seine Gültigkeit und damit jegliche Zugriffsmöglichkeit auf die ihm zuvor zugeordneten Projekte.

Die Löschung eines API Keys kann nicht rückgängig gemacht werden. Er ist anschließend nicht wiederherstellbar.

7. Metriken

Metriken dienen der Überwachung (Monitoring) und der Fehleranalyse der CaaS-Komponenten im laufenden Betrieb und sind über HTTP-Endpunkte abrufbar. Sofern Metriken im Prometheus-Format vorliegen, werden dafür entsprechende ServiceMonitors erzeugt, siehe auch Prometheus-ServiceMonitors.

7.1. REST-Schnittstelle

Healthcheck

Der Healthcheck-Endpunkt stellt Informationen über die Funktionsfähigkeit der entsprechenden Komponente in Form eines JSON-Dokuments bereit. Dieser Zustand wird aus mehreren Prüfungen berechnet. Sind alle Prüfungen erfolgreich, hat die JSON-Antwort den HTTP-Status 200. Sobald mindestens eine Prüfung den Wert false besitzt, erfolgt eine Antwort mit dem HTTP-Status 500.

Die Abfrage erfolgt unter der URL: http://REST-HOST:PORT/_logic/healthcheck

Die Funktionsfähigkeit der REST-Schnittstelle hängt sowohl von der Erreichbarkeit des MongoDB-Clusters als auch von der Existenz eines Primary Nodes ab. Besitzt der Cluster keinen Primary Node, ist die Durchführung von Schreiboperationen auf der MongoDB nicht möglich.

HTTP-Metriken

Metriken zu den HTTP-Anfragen und Antworten der REST-Schnittstelle können als JSON-Dokument oder im Prometheus-Format unter der folgenden URL abgerufen werden: http://REST-HOST:PORT/_metrics

Weitere Informationen sind in der RESTHeart-Dokumentation enthalten.

7.2. MongoDB

Die Metriken der MongoDB werden über einen Sidecar Container zu Verfügung gestellt. Dieser greift mit einem separaten Datenbank-Benutzer auf die Metriken der MongoDB zu und stellt diese über HTTP bereit.

Die Metriken können unter der folgenden URL abgerufen werden: http://MONGODB-HOST:METRICS-PORT/metrics

Bitte beachten Sie, dass die Metriken der MongoDB über einen separaten Port ausgeliefert werden. Dieser Port ist nicht von außerhalb des Clusters zugreifbar und daher auch nicht durch Authentifizierung geschützt.

8. Wartung

Die Übertragung von Daten in den CaaS kann nur funktionieren, wenn die einzelnen Komponenten einwandfrei arbeiten. Treten Störungen auf oder ist eine Aktualisierung notwendig, sind daher stets alle CaaS-Komponenten zu betrachten. Die nachfolgenden Unterkapitel beschreiben die notwendigen Schritte einer Fehleranalyse bei einer vorliegenden Störung sowie die Durchführung eines Backups bzw. Updates.

8.1. Fehleranalyse

Der CaaS ist ein verteiltes System und basiert auf dem Zusammenspiel unterschiedlicher Komponenten. Jede einzelne dieser Komponente kann potentiell Fehler erzeugen. Tritt während der Verwendung des CaaS eine Störung auf, können dieser daher verschiedene Ursachen zugrunde liegen. Nachfolgend werden die grundlegenden Analyseschritte zur Ermittlung von Störungsursachen erläutert.

Zustand der Komponenten

Der Zustand des einzelnen Komponenten der CaaS-Plattform lässt sich mithilfe des Befehls kubectl get pods --namespace=<namespace> überprüfen. Weicht der Status einer Instanz vom Status Running bzw. ready ab, ist es empfehlenswert, die Fehlersuche an dieser Stelle zu beginnen und die zugehörigen Logfiles zu überprüfen.

Bestehen Probleme mit der Mongo-Datenbank, ist zu prüfen, ob ein Primary-Knoten existiert. Unterschreitet die Anzahl verfügbarer Instanzen einen Wert von 50% der konfigurierten Instanzen, kann kein Primary-Knoten mehr gewählt werden. Dieser ist für die Funktionsfähigkeit der REST-Schnittstelle jedoch unerlässlich. Das Fehlen eines Primary-Knotens führt dazu, dass die Pods der REST-Schnittstelle nicht mehr den Status ready besitzen und somit unerreichbar sind.

Das Kapitel Consider Fault Tolerance der MongoDB-Dokumentation beschreibt, wie viele Knoten explizit ausfallen können, bis die Bestimmung eines neuen Primary-Knoten unmöglich ist.

Analyse der Logs

Im Problemfall sind die Logfiles einen guten Ausgangspunkt für die Analyse. Sie bieten die Möglichkeit, alle Vorgänge auf den Systemen nachzuvollziehen. Auf diesem Weg werden eventuelle Fehler und Warnungen ersichtlich.

Aktuelle Logfiles der CaaS-Komponenten sind mittels kubectl --namespace=<namespace> logs <pod> einsehbar, beinhalten jedoch nur Ereignisse, die innerhalb der Lebenszeit der aktuellen Instanz stattgefunden haben. Um dennoch nach einem Absturz bzw. Neustart einer Instanz die Logfiles sinnvoll analysieren zu können, empfehlen wir die Einrichtung eines zentralen Logging-Systems.

Die Logfiles sind grundsätzlich immer nur für den aktuell laufenden Container einsehbar. Aus diesem Grund ist für den Zugriff auf die Logfiles bereits beendeter oder neu gestarteter Container die Einrichtung einer persistenten Speicherung notwendig.

8.2. Backup

Die Architektur des CaaS besteht aus verschiedenen, voneinander unabhängigen Komponenten, die unterschiedliche Informationen erzeugen und verarbeiten. Besteht die Notwendigkeit einer Datensicherung, muss diese daher in Abhängigkeit der jeweiligen Komponente erfolgen.

Ein Backup der im CaaS gespeicherten Informationen muss über die Standardmechanismen der Mongo-Datenbank erfolgen. Dabei kann entweder eine Kopie der zugrundeliegenden Dateien erstellt oder mongodump verwendet werden.

8.3. Update

Der Betrieb der CaaS-Plattform mit Helm in Kubernetes bietet die Möglichkeit einer Aktualisierung auf den neuen Stand, ohne dass dabei eine Neuinstallation notwendig ist.

Vor der Aktualisierung der Mongo-Datenbank wird ein Backup dringend empfohlen.

Der Befehl helm list --all-namespaces liefert zunächst eine Liste aller bereits installierten Helm-Charts. Diese enthält sowohl die Version als auch den Namespace des entsprechenden Releases.

Beispielliste installierter Releases
\$ helm list --all-namespaces
NAME            NAMESPACE    REVISION  UPDATED             STATUS    CHART        APP VERSION
firstinstance   integration  1         2019-12-11 15:51..  DEPLOYED  caas-2.10.4  caas-2.10.4
secondinstance  staging      1         2019-12-12 09:31..  DEPLOYED  caas-2.10.4  caas-2.10.4

Für die Aktualisierung eines Releases sind nacheinander die folgenden Schritte durchzuführen:

Übernahme der Einstellungen

Um einen Verlust der bisherigen Einstellungen zu vermeiden, ist es notwendig, die custom-values.yaml-Datei, mit der die initiale Installation des Helm-Charts durchgeführt wurde, vorliegen zu haben.

Übernahme weiterer Anpassungen

Bestehen Anpassungen an Dateien (z. B. im config-Verzeichnis), sind diese ebenfalls zu übernehmen.

Aktualisierung

Nach der Durchführung der vorherigen Schritte kann anschließend die Aktualisierung gestartet werden. Sie ersetzt die bestehende Installation durch die neue Version, ohne dass eine Downtime entsteht. Dafür ist der folgende Befehl auszuführen, durch den der Vorgang gestartet wird:

helm upgrade RELEASE_NAME caas-2.16.5.tgz --values /path/to/custom-values.yaml

9. Hilfe

Der Technical Support der e-Spirit AG bietet qualifizierte technische Unterstützung zu allen Themen, die FirstSpirit™ als Produkt betreffen. Weitere Hilfe zu vielen relevanten Themen erhalten und finden Sie in auch in unserer Community.