Im DevOps Kontext haben sich über die Zeit verschiedene Werkzeuge entwickelt:
Waren Puppet und Chef noch frühe Vertreter mit unterschiedlichen Paradigmen (deklarativ vs. imperativ) verwendeten doch beide einen Agent. Ansible setzte sich weitgehend als imperative Lösung ohne Agent für die Provisionierung von Systemen durch, während Terraform als Infrastruktur- und Cloudwerkzeug de-factor Standard wurde.
Sowohl Ansible als auch Puppet setzen auf eine Konfiguration, die nahe an typischen Datenformaten von APIs sind (YAML bzw. JSON).

In diesem Beitrag soll es um ein neuartiges Werkzeug gehen, dass den deklarativen Ansatz verfolgt, jedoch die Kubernetes API als Schnittstelle verwendet. Crossplane geht damit einen spannenden Weg und erlaubt es, bestehende Verfahren zur Authentifizierung und Autorisierung weiter zu nutzen und sich dank zahlreicher Kubernetes Libraries auch einfach an eigene oder bestehende Anwendungen zu integrieren. Dies ermöglicht eine konsistente Verwaltung von (Cloud-)Ressourcen und Kubernetes-Workloads. Crossplane bietet somit eine engere Integration zwischen Anwendungen und Infrastruktur, was die Automatisierung und das Management vereinfacht.

Dies wird dank der erweiterbaren API von Kubernetes möglich: Alle Crossplane Ressourcen sind Custom Resource Definitions (CRDs) in Kubernetes. Die Erweiterung von Crossplane ist durch die erweiterbare API von Kubernetes ebenfalls gegeben, so können sogenannte Provider nachgerüstet werden. Dazu können vorhandene Kubernetes Konzepte wie ConfigMaps oder Secrets verwendet werden.

Aus diesem Ansatz ergeben sich folgende Vorteile von Crossplane:

Crossplane benötigt jedoch einen Kubernetes API Server als Basisinfrastruktur. Im folgenden schauen wir uns die Installation und Verwendung von Crossplane genauer an.

Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt. Als ein Option wurde in diesem Beitrag erklärt, wie PostgreSQL mit Helm in Kubernetes betrieben werden kann.
In diesem Beitrag geh es darum, wie das Kubernetes Operator Konzept den Betrieb erleichtern kann und einige prominente Vertreter von Kubernetes Operators zu vergleichen.

Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt.
Für eine einzelne Umgebung funktioniert das Verfahren soweit ganz gut. Wenn jedoch verschiedene Varianten, z.B. für mehrere Umgebungen, bereitgestellt werden sollen, steigt der Aufwand und auch das Risiko von Configuration Drift. Helm tritt an, um dabei Abhilfe zu schaffen.

Galt vor einigen Jahren noch das Motto, dass Datenbanken besser außerhalb von (Docker-)Containern oder gar eines Kubernetes Clusters betrieben werden sollten, so hat sich das Bild inzwischen stark gewandelt. Nicht nur, dass sich Kubernetes als das neue Betriebssystem von Rechenzentren und der Cloud etabliert hat, es gibt sogar unmittelbare Vorteile bei der Integration von Plattformdiensten mit Kubernetes.
Welche grundsätzlichen Optionen es gibt, und wie das Vorgehen aussehen kann, beleuchtet dieser Beitrag.

Ursprünglich war Docker konzipiert als Eierlegendewollmilchsau Probleme rund um den Betrieb von Software in der Cloud zu lösen.
Dazu gehören verschiedene Aspekte von Bereitstellung der Software als Image bis hin zur Laufzeitumgebung mit Persistenz. Im Kontext von Kubernes kann es zu Überschneidungen kommen, die sich in unangenehmen Überraschungen äußern. Worauf es zu achten gilt, wenn Docker VOLUMEs und Kubernetes im Spiel sind - zum Beispiel bei Datenbanken - wird in diesem Beitrag vorgestellt.

Nachdem DockerHub die automatischen Builds von Docker Images nicht mehr kostenlos für jeden anbietet, bieten sich GitHub Actions als eine praktische Alternative an. ( Die Umsetzung von Multi-Arch Builds mit DockerHub wurde in dem Beitrag Docker Multi Arch Images mit DockerHub behandelt.)
In diesem Beitrag wird eine Umsetzung von Multi-Arch Images am Beispiel das Angular-CLI Docker Images vorgestellt.