How-To

Besser entwickeln mit Devops-Praktiken: Continuous Delivery mit Kubernetes

(Grafik: Irina Strelnikova/ Shutterstock)

In der Software-Industrie sind die Reaktionsfähigkeit auf neue Markt­anforderungen und kurze Produkteinführungszeiten entscheidende ­Wett­­­­b­ewerbs­faktoren. Viele Entwicklungs­teams führen daher Devops-Praktiken wie etwa ­Continuous Delivery ein und nutzen aktuelle Technologien wie Kubernetes als unterstützende ­Werkzeuge.

Der Begriff Continuous Delivery beschreibt den Wechsel von ­konstanten Release-Zyklen („neue Versionen werden immer zum Quartalsende veröffentlicht“) hin zu einem kontinuierlichen Ausrollen neuer Versionen einer Software. Damit Continuous Delivery in der Praxis funktioniert, müssen mehrere Voraus­setzungen erfüllt sein: Zum einen benötigt das Entwicklungsteam einen gewissen Spielraum, in dem es selbstständig und eigenverantwortlich agieren kann; Abhängigkeiten von anderen Teams oder Abteilungen sollten möglichst vermieden werden. Viele Teams greifen zu einer Devops-­Organisationsstruktur, in der die (ansonsten oft klaren) Grenzen zwischen Entwicklung (Development) und Betrieb (Operations) verschwimmen – etwa in Form von Entwicklern, die gleichzeitig auch für den operativen Betrieb ihrer Applikationen verantwortlich sind.

Zum anderen benötigt es einen schnellen, wiederholbaren und gut automatisierbaren Prozess zur Auslieferung und zum Betrieb der Software. Diese Anforderungen werden von aktuellen Technologien wie Docker und Kubernetes gut bedient, die Devops-Teams passende (und gut automatisierbare) Werkzeuge zum Bauen, Ausliefern und Betreiben von Applikationen an die Hand geben. Wie das mit Kubernetes gelingen kann, zeigen wir euch im Folgenden.

Deployment nach Kubernetes

Am Anfang jeden Deployments steht zunächst das Erstellen eines Container-Images, das beispielsweise mithilfe eines ­Dockerfiles und dem Befehl docker build erstellt werden kann (im Folgenden nehmen wir das Image your-app:v1.2.3 als Beispiel an).

Zum Starten einer Applikation auf Kubernetes kann am besten ein Deployment-Objekt benutzt werden. Dieses wird in Form einer YAML-Datei definiert, die wie folgt aussehen könnte:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-application
spec:
  replicas: 4
  template:
    containers:
    - name: app
      image: "your-app:v1.2.3"
      ports:
      - containerPort: 8080
        name: http

Das Deployment kann mit dem Befehl kubectl apply erstellt werden. In diesem Fall startet Kubernetes vier „Replicas“ des angegebenen (und zuvor gebauten) Container-Images:

> kubectl apply -f your-deployment.yaml

Die gestarteten Instanzen (Pods) können im Anschluss mit dem Befehl kubectl get pods abgefragt werden:

> kubectl get pods
NAME                    READY  STATUS   RESTARTS  AGE
my-app-351368469-brjcd  1/1    Running  0         1m
my-app-351368469-nrzxh  1/1    Running  0         1m
my-app-351368469-owkfz  1/1    Running  0         1m
my-app-351368469-bhaz6  1/1    Running  0         1m

Zukünftige Versionen der Software können nun als jeweils neues Image veröffentlicht werden. Um eine neue Version zu releasen, kann das Deployment über den folgenden Befehl bearbeitet werden:

> kubectl set image deployment/your-application app=your-app:v1.2.4
deployment.apps/your-application image updated

Kubernetes führt in diesem Fall ein Rolling Update der ­Applikation aus. Das bedeutet, dass die Container mit der ­vorherigen Version des Images einer nach dem anderen heruntergefahren werden. Für jeden gestoppten Container der Vorversion wird ein ­neuer Container mit der neuen Version gestartet. Auf diese Weise werden alle laufenden Instanzen der Applikation nach und nach ausgetauscht. Die Applikation als Ganzes bleibt dabei erreichbar. Allerdings muss berücksichtigt werden, dass für einen kurzen Zeitraum zwei Versionen parallel laufen. Sollte die neue Version der Software nicht so laufen wie gewünscht, kann das Ganze über den kubectl rollout undo-Befehl wieder rückgängig gemacht werden:

> kubectl rollout undo deployment/your-application

Der Helm-Paketmanager

Die Methode, Deployments über den kubectl set image-Befehl zu aktualisieren, funktioniert in vielen einfachen Fällen, stößt ­jedoch schnell an ihre Grenzen. Häufig besteht eine auf ­Kubernetes betriebene Applikation nicht nur aus einem Deployment-Objekt, sondern aus zahlreichen weiteren Objekten (beispielsweise aus Service- und Ingress-Objekten, die definieren, wie eingehender Traffic die Applikation erreicht oder Configmap- und Secret-Ressourcen, die Konfigurationsdaten für die Applikation beinhalten). Änderungen an solchen Ressourcen können in einer Deployment-­Pipeline über den obigen kubectl set image-Befehl nicht abgebildet werden.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.