Container & Datenbanken

Beyond stateless Apps: Wie man Docker für Datenbanken verwendet

Dr. Mahmoud Reza Rahbar Azad, Phil Stelzer

©Shutterstock / Mathisa

Wer schon mal mit docker run nginx eine nginx-Instanz gestartet hat, wird durch den Usability-Boost von Docker motiviert, tiefer in die Materie einzusteigen. Docker macht es sehr einfach, Applikationen zu konfigurieren und zu starten. Durch einige wenige Befehle auf der Kommandozeile lassen sich viele Aspekte im Lebenszyklus einer Applikation mühelos abdecken.

Am Beispiel des nginx-Containers fällt auf, dass man in den Container noch seine eigentliche Konfiguration hineinbekommen muss. Das lässt sich entweder dadurch bewerkstelligen, dass der Entwickler ein eigenes Docker Image auf Basis des nginx Image baut oder ein Volume in den Container mountet, z. B. über: docker run -v / host/path/nginx.conf:/etc/nginx/nginx.conf:ro -d nginx. Zwar verpsricht der zweite Ansatz höhere Flexibilität, allerdings ist er in einem Container-Cluster-Umfeld wie Kubernetes ungeeignet, da der Container auf einem beliebigen Knoten gestartet werden kann, auf dem die Konfigurationsdateien nicht vorliegen. Kubernetes bietet deshalb für das Konfigurationsmanagement den speziellen Datentyp Configmaps an, um dieses Problem anzugehen. Dieses Beispiel soll verdeutlichen, dass zustandsbehaftete Anwendungen auch in einer containerisierten Umgebung nicht die Ausnahme sind, sondern die Regel. Zwar mag dieses Vorgehen mit den Prinzipien aus dem Zwölf-Faktoren-App-Manifest brechen, aber interessanterweise befinden sich aktuell fünf Datenbanken unter den Top Ten der am meisten heruntergeladenen Container-Images auf Docker Hub: Redis, MySQL, MongoDB, Elasticsearch und Postgres. Das spricht klar für ein gesteigertes Interesse an containerisierten Datenbanken. „Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.

Fairerweise muss man klarstellen, dass Twelve-Factor-Apps nicht zwingend containerisiert sein müssen. Mit Sicherheit aber sind Container als Laufzeitumgebung ein innovativer Wegbereiter für viele Aspekte von Twelve-Factor-Apps und damit zukünftig grundlegendes Know-how für Entwickler und DevOps Engineers.

Das Was und das Warum

Im Gegensatz zum Konfigurationsmanagement stehen wir bei containerisierten Datenbanken ganz anderen Herausforderungen gegenüber. Die erste Aufgabe ist, Daten über die Lebenszeit eines Containers hinweg zu persistieren. Des Weiteren sollte natürlich die Datenkonsistenz gewährleistet sein. Darüber hinaus muss eine Datenbank eine hohe Verfügbarkeit haben, da es sich um einen Kernservice handelt, dessen Zuverlässigkeit und Verfügbarkeit sich meist direkt auf andere Services übertragen. Außerdem sollte nach Möglichkeit der Datenbankcontainer skalierbar sein, sodass weitere Instanzen bei Lastspitzen gestartet werden können (horizontale Skalierung). Letztlich muss sich eine Datenbank natürlich mit gängigen Administrationswerkzeugen leicht verwalten lassen können.

Containerisierte Datenbanken und der Trend der DevOps-Kultur

Ein kurzer Entwicklungszyklus in der Anwendungsentwicklung ist heutzutage für viele Unternehmen, deren Kernbereich von Apps und Software abhängt, sowohl wünschenswert als auch notwendig. Ziel ist es, eine kurze Time-to-Market zu gewährleisten und dadurch den eigenen Wettbewerbsvorteil zu sichern. Eine Möglichkeit, diesen Zielzustand zu erreichen, besteht z. B. darin, eine Microservices-Architektur inklusive Continuous Delivery zu verwenden und Methoden der agilen Softwareentwicklung und der DevOps-Kultur im eigenen Unternehmen zu etablieren.

Die Vorteile containerisierter Datenbanken

Dev-Prod-Vergleichbarkeit: Sowohl Entwicklung als auch Betrieb profitieren davon, wenn eine hohe Vergleichbarkeit zwischen den unterschiedlichen Umgebungen wie z. B. Dev, QA und Prod herrscht. Das betrifft einerseits die eingesetzten Werkzeuge und die verwendeten Versionen und andererseits deren Kommunikation untereinander. Eine hohe Vergleichbarkeit erhöht nicht nur die Chance, Fehler schneller zu finden und produktive Fehler direkt auf Dev nachzustellen. Auch Continuous Deployment lässt sich besser umsetzen, da ein einheitlicher Standard herrscht, wie Applikationen veröffentlicht werden. Containerisierte Datenbanken machen es besonders leicht, eine solche Parität aufzubauen, weil sich der gleiche Datenbankcontainer für alle Umgebungen nutzen lässt. Die Entwicklung kann die gleiche Datenbank wie in der Produktion einsetzen und entweder einen eigenen oder einen gespiegelten Datenbestand einstellen.

Continuous Delivery: Continuous Integration (CI)
ist eine Methode, die kontinuierlich die Bestandteile einer Anwendung zusammenführt und – im Optimalfall durch eine hohe Testabdeckung abgesichert – stabile Artefakte produziert. CI ist die Vorstufe von Continuous Delivery (CD), indem Artefakte nach einer Freigabe auch gleich in eine QA- oder Produktivumgebung veröffentlicht werden. Durch das Einsetzen von containerisierten Datenbanken lassen sich diese als ein weiterer Bestandteil in einer CI/CD-Pipeline verwenden. So können wir Datenbanken einheitlich wie Anwendungen deployen, was eine höhere Standardisierung mit sich bringt. Dies hat unter anderem den Vorteil, dass sich Datenbankbereitstellungsprozesse vermeiden lassen. Eine Datenbank wird dann erzeugt, wenn sie gebraucht wird, und nicht vor Projektbeginn oder erst im Nachhinein. Es mag vielleicht ungewöhnlich anmuten, Datenbanken in eine CI/CD-Pipeline einzubinden, da Datenbankanwendungen meist einen kurzen Updatezyklus haben, aber erst durch die Einbindung in eine Deployment-Pipeline kann die Datenbank ein integraler Bestandteil in der Anwendungskette werden und somit eher den DevOps-Paradigmen entsprechen.

Microservices: Bei der Verwendung einer Microservices-Architektur stellt sich schnell die Frage, ob eine gemeinsame Datenbank für alle Services oder jeweils eine eigene Datenbank pro Service eingesetzt werden soll. Die letzte Option hat den klaren Vorteil, dass die einzelnen Services unabhängig voneinander sind und wir jeweils eine unterschiedliche Datenbank pro Einsatzszenario verwenden können. Das ist der sprichwörtliche Ansatz einer Microservices-Architektur. Der Managementaufwand, der mit einer Datenbank pro Service einhergeht, lässt sich besonders gut über eine einheitliche Containerschnittstelle in den Griff bekommen. Unterstützung lässt sich diesbezüglich besonders gut über Containerorchestrierungswerkzeuge wie Kubernetes einholen.

Die hier beschriebenen Vorteile verdeutlichen, dass containerisierte Datenbanken sich sehr gut mit modernen Entwicklungsparadigmen verbinden lassen und ihre Vorzüge besonders in einer dynamischen und automatisierten Infrastruktur entfalten. Wer sich in den oben genannten Punkten wiederfindet, dem sind containerisierte Datenbanken nachdrücklich zu empfehlen. Wie sieht es nun mit einem praktischen Einstieg in containerisierte Datenbanken aus? Das veranschaulicht eine beispielhafte Integration in einem Kubernetes-Cluster in Hinblick auf die anfänglich formulierten Anforderungen.

Wie kann man in Kubernetes mit zustandsbehafteten Anwendungen umgehen?

Kubernetes hat seine eigene Art und Weise, Container mit persistentem Speicher, in der Kubernetes-domänenspezifischen Sprache Volumes genannt, zu versehen. Möchte man an Kubernetes Pods – so heißen die Basiseinheiten, in denen die Container ausgeführt werden – Volumes anbinden, müssen diese im Vorfeld in der Pod-Definition unter dem Eintrag volumes definiert werden. Damit stehen sie für alle Container in einem Pod zu Verfügung und können von einem Container über einen Eintrag in volumeMounts eingebunden werden. Um was für einen Typ von Volume es sich handelt, ist an dieser Stelle für einen Container nicht einsehbar. Dies wird von Kubernetes weggekapselt.

Einmal von hostbasierten Volumes abgesehen, unterteilt Kubernetes das Einbinden von Volumes in einen zweistufigen Prozess. Möchten wir einem Container ein Volume zur Verfügung stellen, muss zuvor ein PersistentVolumeClaim erstellt werden, in dem ausgedrückt wird, wie viele Ressourcen benötigt werden. Diese Forderung muss von einem PersistentVolume erfüllt werden. Dieser Prozess lässt sich über ein neues Storage-Class-Konzept vereinfachen, indem dynamisch PersistentVolumes provisioniert werden.

Kubernetes unterstützt zurzeit mit Version 1.7 über zwanzig verschiedene Volume-Plug-ins, die in Tabelle 1 zusammengefasst sind. Sie reichen vom einfachen Einbinden eines Hostpfads und Cloud-Storage bis hin zu Anbietern von speziellen Container-Storage-Lösungen.

Block Storage Verteiltes Dateisystem
  • awsElasticBlockStore
  • gcePersistentDisk
  • azureDisk
  • vspehereVolume
  • isci
  • Hostbasiert:
  • emptyDir
  • hostDir
  • local
  • nfs
  • cephfs
  • glusterfs
  • azureFileVolume
  • Weitere:
    • Quobyte
    • PortworxVolume
    • StorageOS
    • gitRepo

Tabelle 1: Eine Übersicht an Kubernetes-Volume-Plug-ins

Welches Plug-in das passende ist, hängt natürlich vom Einsatzszenario und am Ende auch von den Möglichkeiten der Infrastruktur ab. Wird z. B. der Kubernetes-Cluster in einer Public Cloud betrieben, bietet es sich an, Storage-Services wie Amazons EBS (Elastic Block Store) zu nutzen. Wird der Kubernetes-Cluster jedoch in einer Private Cloud wie OpenStack betrieben, lässt sich gut Cinder, der Block-Storage-Dienst von OpenStack, Ceph oder GlusterFS verwenden. Schließlich ist die Nutzung von Kubernetes auf VMs auch eine weitverbreitete Variante. Hierbei muss man sich bezüglich seiner Prioritäten im Vorfeld im Klaren sein. Es könnte womöglich wichtig sein, eine bestehende Storage-Lösung auf Basis von NFS oder eines proprietären Produkts wiederzuverwenden oder eine Storage-Lösung zu benutzen, die eine gute Skalierbarkeit hat und ausreichende Performance gewährleistet.

Wie fängt man bei einer solchen Vielfalt an Möglichkeiten an? Ein stabiles Storage-System ist die Grundvoraussetzung, um containerisierte Datenbanken zu betreiben. Deshalb schauen wir uns an, wie sich mithilfe von Heketi ein GlusterFS-Cluster mit dynamischer Provisionierung erstellen und in einen Demowebshop einbinden lässt. Die Besonderheit von Heketi dabei ist, dass es eine REST-Schnittstelle zum Managen von GlusterFSVolumes anbietet, womit sich der Aufwand hinsichtlich Installation und Betrieb wesentlich reduziert.

Case Study: Ein Webshop in Kubernetes

Der in Abbildung 1 dargestellte Webshop ist aus mehreren Microservices aufgebaut.

Abb. 1: Schematische Darstellung des Demowebshops

Abb. 1: Schematische Darstellung des Demowebshops

Eine Frontend-Komponente bietet eine Weboberfläche für Artikel- und Bestelldaten an. Dazu greift sie auf den Order- bzw. Article-Service zu. Diese Services haben jeweils eine eigene Datenbank zur Persistierung ihrer Daten. Die Stammdaten werden durch den Masterdata-Service zur Verfügung gestellt. Dieser hat die Aufgabe, die Stammdaten zu Artikeln und Artikelgruppen aktuell zu halten und bietet eine Schnittstelle zur Abfrage an. Bei den Services handelt es sich um Spring-Boot-Anwendungen, als Datenbank kommt Postgres zum Einsatz. Die Volumes für die Datenbankcontainer werden über das zuvor diskutierte GlusterFS-Cluster provisioniert.

Postgres bietet die Möglichkeit, weitere redundante Datenbankinstanzen in einem Cluster hinzuzufügen, um eine gewisse Ausfallsicherheit zu gewährleisten. Für Kubernetes gibt es eine Reihe von Projekten (Patroni, Stolon, Crunchy-Containers), mit denen sich ein solches Hochverfügbarkeits-Set-up aufsetzen lässt.

Abb. 2: Continuous-Delivery-Pipeline für den Demowebshop

Abb. 2: Continuous-Delivery-Pipeline für den Demowebshop

Die Services sind in eine CI-Pipeline eingebunden (Abb. 2). Nach jedem erfolgreichen Build auf dem master-Branch wird ein Deployment auf eine Testumgebung angestoßen. Für das Deployment wird Helm, der Paketmanager von Kubernetes, genutzt. Für die Testumgebung wird jedes Mal ein neuer Datenbankcontainer gestartet, mit einem Datenbank-Snapshot aus der QAoder Produktionsumgebung. Der Service verbindet sich beim Hochfahren mit seiner dedizierten Datenbank und führt gegebenenfalls Migrationsskripte aus. Nachdem Kubernetes den Service über ein readinessProbe freigegeben hat, steht er für etwaige Post-Deployment- bzw. Lasttests bereit.

An dieser Stelle lässt sich entweder automatisch oder manuell ein Release erstellen, das anschließend auf die QA-Umgebung, entsprechend wie die Testumgebung, deployt wird. Diesmal verwendet der Service sinnvollerweise die bestehende Datenbank. Der Übergang in Produktion entspricht dann nur noch einem Redeployment in diese Umgebung. Die einzelnen Umgebungen entsprechen in Kubernetes einzelnen Namespaces. Dadurch ist eine hohe Parität zwischen den Umgebungen gegeben.

Wie können wir nun die Datenbankcontainer administrieren? Kubernetes stellt für zustandsbehaftete Container den Deployment-Typ StatefulSets zu Verfügung. Dieser Typ erfüllt einige Bedingungen, die gerade für das Managen von Datenbanken wünschenswert sind. Einerseits erhalten die Pods in einem StatefulSet einen festen Namen, sodass die einzelnen Instanzen gezielt über die Service Discovery von Kubernetes angesprochen werden können. Dadurch lassen sich bestehende Administrationswerkzeuge wie gewohnt verwenden. In unserem Beispiel kann man pgAdmin in Kubernetes betreiben und die Serviceadresse oder psql nutzen, indem eine weitere Ingress-Definition über die Serviceadresse angelegt wird.

Stateful Sets haben aber noch weitere Vorzüge. Die Spezifikation beinhaltet unter anderem die volumeClaimTemplates-Deklaration. In unserem Beispiel wird dadurch automatisch über Heketi ein GlusterFS Volume erstellt und dem Pod zugewiesen, mit dem es direkt verknüpft ist. Wird der Pod neu gestartet, wird sein bestehendes Volume an seinem neuen Knoten gemountet und steht dem Pod wieder zur Verfügung. Außerdem garantiert Kubernetes die Reihenfolge beim Hoch- und Herunterfahren von einzelnen Instanzen in einem Stateful Set.

Mit den Features von Stateful Sets ist es aber alleine nicht getan. Die Verantwortung für Datenbank-Backups oder eine Strategie beim Versionsupdate liegt immer noch beim Datenbankadministrator. Eine zukünftige Möglichkeit, dessen Herr zu werden, bietet sich mit Kubernetes Operator. Dahinter steckt ein Konzept, das eine Softwareeinheit, die selbst in Kubernetes läuft, sich um die speziellen Lebenszyklusaktionen einer zustandsbehafteten Anwendung kümmert. Operators kommen zurzeit in unterschiedlichen Facetten vor. Es gibt sie für Datenbanken (Postgres-Operator, etcd Operator), Storage-Lösungen und sogar für OpenStack. Wer mehr über die Funktionsweise von Operators wissen möchte, kann das im Blogbeitrag von Brandon Philips gut nachlesen

Deployment einer Webanwendung inklusive Datenbank

Abb. 3: Verzeichnisstruktur eines Helm-Charts und Inhalt von „requirements.yaml“

Abb. 3: Verzeichnisstruktur eines Helm-Charts und Inhalt von „requirements.yaml“

Für das Deployment wird ein Helm-Chart entwickelt, der als Vorlage für reale Projekte dienen kann. Voraussetzung dafür ist selbstverständlich ein funktionierendes Volume-Plug-in. Bei der Applikation handelt es sich um eine einfache Webanwendung, die eine Oberfläche für CRUD-Operationen auf einer Datenbankentität zulässt. Das Git-Repository lässt sich selbstverständlich in GitHub auschecken.

In Abbildung 3 ist die Verzeichnisstruktur eines Helm-Charts dargestellt. Im Hauptverzeichnis befindet sich die Chart.yaml-Datei, in der allgemeine Metadaten wie Name, Version und Beschreibung zum Chart stehen. In der Datei values.yaml stehen überschreibbare Variablen. Zusätzlich können in requirements.yaml weitere Charts aufgeführt werden, auf die eine Abhängigkeit besteht, sodass diese ebenfalls von Helm deployt werden. In unserem Beispiel verwenden wir eine PostgreSQL-Datenbank. Dazu greifen wir auf das offizielle PostgreSQL-Chart zurück. Das Ausschalten der Abhängigkeit zur PostgreSQL-Datenbank wurde mit der Bedienung postgresql.enabled ermöglicht.

$ cat chart/templates/deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ template "appname" . }}
  labels:
    app: {{ template "appname" . }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ template "appname" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        env:
        - name: SPRING_DATASOURCE_URL
          value: "jdbc:postgresql://{{ .Values.application.database_url }}:5432/{{ .Values.postgresql.database }}"
        - name: SPRING_DATASOURCE_USERNAME
          valueFrom:
            secretKeyRef:
              name: webapp-db-secret
              key: username
        - name: SPRING_DATASOURCE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: webapp-db-secret
              key: password
        - name: SPRING_PROFILES_ACTIVE
          value: {{ .Release.Namespace  | quote }}
        ports:
        - name: "{{ .Values.service.name }}"
          containerPort: {{ .Values.service.internalPort }}
        livenessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        readinessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        resources:
          limits:  
            cpu: 100m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 128Mi

In Listing 1 ist die Deployment-Definition der Applikation dargestellt. Über Templatevariablen werden unter anderem die Version und die Anzahl an Replicas des Containers sowie unterschiedliche Metadaten aus der Definition ausgelagert, sodass sie während der Ausführung von Helm überschrieben werden können. In einer CI-Pipeline lassen sich so die Version der Applikation und die aktuelle Umgebung (Dev, QA, Prod) setzen. Neben den üblichen sinnvollen Einträgen wie livenessProbe, readinessProbe und resources enthält die Deployment-Definition eine Umgebungsvariable mit der Datenbankadresse. Die Applikation kann so dynamisch zur Startzeit konfiguriert werden.

Um den Helm-Chart jetzt erstmalig in Kubernetes zu deployen, kann der Befehl aus Listing 2 verwendet werden. Helm orchestriert das Deployment und legt die im Chart beschriebenen Ressourcen in Kubernetes an. Das Ergebnis wird anschließend wie in Listing 3 dargestellt aussehen.

$ helm upgrade --install --wait webapp \
  --set image.repository="registry.kubernetes.acando-cloud.de/acando/webapp" \
  --set image.tag="0.0.1" \
  --set application.database_url="webapp-postgresql” \
  --set postgresql.postgresUser="user" \
  --set postgresql.postgresPassword="password" \
  --set postgresql.postgresDatabase="db" \
  --namespace="prod" \
  chart/
$ kubectl -n prod get pods -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase
NAME                                                    STATUS
webapp-87f8c44d9-xshbz                      Running
webapp-postgresql-5ff98cd6cd-p9zp9   Running

$ kubectl -n prod get pvc -o=custom-columns=NAME:.metadata.name,CAPACITY:.status.capacity.storage,PHASE:.status.phase
NAME                       CAPACITY   PHASE
webapp-postgresql   9Gi               Bound


$ kubectl -n prod get svc -o=custom-columns=NAME:.metadata.name,IP:.spec.clusterIP,PORT:.spec.ports[*].port
NAME                                                     IP                          PORT
glusterfs-dynamic-webapp-postgresql    10.254.94.127      1
webapp                                                   10.254.239.255    80
webapp-postgresql                                 10.254.104.54      5432

$ kubectl -n prod get ing -o=custom-columns=NAME:.metadata.name,HOSTS:spec.rules[*].host
NAME             HOST                                                     
webapp           webapp.kubernetes.acando-cloud.de    
postgresql       postgres.kubernetes.acando-cloud.de

Beim ersten Ausführen des Charts wird automatisch über Heketi ein GlusterFS Volume erstellt und dem PostgreSQL Pod zugewiesen. Bei einem späteren Update des Helm-Charts wird das PostgreSQL Volume nicht neu erstellt, sondern das schon vorhandene Volume wiederverwendet. Die Trennung des PostgreSQL-Service und der PostgreSQL-Daten gewährleistet eine entsprechende Datensicherheit. Das Verhalten bei einem Failover, wenn der PostgreSQL Pod ausfällt, lässt sich durch das manuelle Neustarten des Datenbank-Pods simulieren. Diese zugegebenerweise rabiate Methode verdeutlicht die Stärke von Kubernetes. Der PostgreSQL Pod wird automatisch einem neuen Knoten zugewiesen. Davor wird zuerst das Volume an den entsprechenden Knoten angebunden, sodass der PostgreSQL-Service mit dem vorherigen Datenbestand starten kann.

Um auf die Webanwendung und die Datenbank zuzugreifen, werden entsprechende Ingress-Regeln in Kubernetes angelegt. In Abbildung 4 ist das User Interface der Webanwendung zu sehen. Testweise lassen sich jetzt Einträge und Änderungen über die Webanwendung machen. Um zu prüfen, ob die angezeigten Daten auch tatsächlich in der Datenbank vorhanden sind, können wir das SQL Statement aus Listing 4 verwenden.

Abb. 4: Das User Interface der Webanwendung bietet die Möglichkeit, Nachrichten zu erstellen und zu bearbeiten

Abb. 4: Das User Interface der Webanwendung bietet die Möglichkeit, Nachrichten zu erstellen und zu bearbeiten

$ psql -h postgres.kubernetes.acando-cloud.de -U user db
Password for user user:
psql [9.6.1, server 9.6.2]

db=# select * from messages;
id | summary             | text                                        | created
---+---------------------+---------------------------------------------+-----------------
1 | Chaos engineering .. | Chaos engineering is not about causing chaos  | 2017-11-24 16:43:21.424

Dieses einfache Beispiel zeigt, wie schnell und unkompliziert es sein kann, eine Anwendung inklusive Datenbank in Betrieb zu nehmen. Für die Datenbankadministration lassen sich bestehende Werkzeuge wie gewohnt verwenden. Das Beispiel ist allerdings zu simpel aufgebaut, um den Anforderungen an eine produktive Umgebung gerecht zu werden. Demgegenüber kann sich dieses Set-up für die Dev- und QA-Umgebung als brauchbare Vorlage erweisen.

Fazit

Die Vorteile des Einsatzes von containerisierten Datenbanken im Vergleich mit einer traditionellen Betriebsweise sind eindeutig. Sie kommen besonders gut in einer dynamischen Infrastruktur zur Geltung. Insbesondere, wenn das Thema Agilität und DevOps ernst genommen wird, liegt der Mehrwert auf der Hand. Es gibt technisch keine Limitierung, aufgrund derer Datenbanken nicht in Containern betrieben werden sollten. Allerdings eignen sich nicht alle Datenbanken für eine horizontale Skalierung. Deshalb sollte im Vorfeld neben den eingangs erwähnten Anforderungen dieses Thema bei der Datenbankauswahl mit berücksichtigt werden.

Was die Integration und den Betrieb von containerisierten Datenbanken in Kubernetes angeht, stehen dafür jetzt schon viele erprobte Konzepte zur Verfügung. Der wohl wichtigste Punkt ist die Einbindung einer geeigneten Storage-Lösung. Diesbezüglich wurde in letzter Zeit das Standard Container Storage Interface (CSI) entwickelt, das über alle populären Containerorchestrierungslösungen einheitlich ist und es vereinfachen soll, eine bestehende Storage-Lösung anzubinden, zwischen unterschiedlichen zu migrieren oder mehrere parallel zu nutzen.

Wer überlegt, mit dem Full-Stack auf Container zu wechseln, kann das bereits jetzt tun. Es bietet sich an, mit einem ersten Microservice Erfahrungen zu sammeln und die Infrastruktur vorzubereiten, damit anschließend weitere Services leichter nachgezogen werden können.

Geschrieben von
Dr. Mahmoud Reza Rahbar Azad
Dr. Mahmoud Reza Rahbar Azad
Dr. rer. nat. Mahmoud Reza Rahbar Azad arbeitet als Consultant bei der Acando GmbH. Er verfügt über langjährige Erfahrungen im Bereich der Anwendungsentwicklung sowohl für Backend als auch für Frontend-Applikationen. Seine Interessensfelder umfassen zudem Cloud-Architekturen als auch Containersysteme wie Kubernetes.
Phil Stelzer
Phil Stelzer
Phil Stelzer ist studierter Informatiker und seit 2016 als Berater für die Acando GmbH tätig. Als Backend-Entwickler und Cloud-Architekt fokussiert er sich auf Infrastruktur- und Container Technologien wie OpenStack und Kubernetes. Innerhalb der Acando baut er neue Cloud-Dienstleistungen auf und interessiert sich für Automatisierung, CI/CD und dynamische Infrastruktur.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: