Seite 2: Cloud-Native-Integration

Inhaltsverzeichnis

Mit zunehmender Verbreitung Cloud-nativer Ansätzen stellt sich die Frage, was die passende Variante von Integrationstechniken wie ESBs (Enterprise Service Bus) ist. Der Wettbewerb um gute Ideen ist im vollen Gange. Eine äußerst charmante verfolgt WSO2 mit einer eigenen Sprache (Ballerina), die speziell für die Systemintegration ausgelegt ist und deren Ausführungsumgebung Container sind. Dabei handelt es sich um eine Sprache, die für die leidigen Mapping-Logiken, Ablaufsteuerungen und Protokollanbindungen bei der Systemintegration eine elegante Notation bietet. Sie ist textuell, und zusätzlich existiert eine grafische Notation. Für Ballerina sind eine dedizierte Entwicklungsumgebung sowie ein Plug-in für Visual Studio Code verfügbar.

CloudFoundry herzt Kubernetes

Trotz seiner großen Verbreitung wird CloudFoundry bei einem Kampf mit Kubernetes um die Container-Orchestrierung vermutlich den Kürzeren ziehen. Kubernetes ist dort schlicht zu dominant und hat das größere und aktivere Ökosystem. Daher bleibt nur die Umarmung, die sich durch mehrere Open-Source-Projekte andeutet:

• Das Projekt Eirini im CloudFoundry-Inkubator lässt die CloudFoundry-Kommandozeile auf ein Kubernetes-Cluster zeigen. Damit können Entwickler transparent mit demselben Befehl ein Deployment sowohl auf einem CloudFoundry- als auch auf einem Kubernetes-Cluster durchführen.
• Das Projekt CF Containerization hat das Ziel, CloudFoundry auf Kubernetes laufen zu lassen.
• Das buildpacks.io-Projekt entwickelt einen Standard für Buildpacks. Ein Buildpack erzeugt aus dem Anwendungscode ein lauffähiges Container-Image. Es erkennt, welche Art von Laufzeitumgebung der Code in einem Repository benötigt, baut die Anwendung und verpackt das Ergebnis schließlich in ein Image mit der passenden Umgebung – beispielsweise einen Servlet-Container. In ähnliche Richtung marschieren bereits die Projekte Draft von Microsoft und Skaffold) von Google.

Mittelfristig ist zu erwarten, dass CloudFoundry als Container-as-a-Service-Layer (CaaS) Kubernetes nutzt und darauf seine bewährten Platform-as-a-Service-Funktionen (PaaS) aufsetzt.

Cloud Native CI/CD

Obschon eine CI/CD-Toolchain (Continuous Integration/Continuous Delivery) zur Standardausstattung gehört, sind viele Nutzer sich bei der Wahl der richtigen Werkzeuge unsicher. Jenkins war lange Zeit der Platzhirsch, hat den Umschwung von CI- zu CD-Pipelines jedoch verschlafen. Zudem ist die Software nach wie vor recht sperrig auf Kubernetes zu betreiben. Beide Faktoren sprechen dafür, dass ein frischer Nachfolger das Ruder übernehmen kann. Als Ersatz bieten sich einige Projekte an:

• Drone ist ein einfach gehaltener CI/CD-Dienst, der auf den Betrieb im Container ausgelegt ist. Ein skalierbares und hochverfügbares Deployment auf einem Kubernetes-Cluster kann es jedoch noch nicht verwalten. Die Entwicklungsaktivität für Drone lässt allerdings seit einem Jahr deutlich nach beziehungsweise verlagert sich auf die kommerzielle Enterprise-Edition. Das junge zugehörige Projekt KubeCI hat das Ziel, Drone sauber auf Kubernetes laufen zu lassen und dem Projekt Schub zu geben. Ob das gelingt, bleibt abzuwarten.
• Concourse von Pivotal ist ein ausgereiftes und funktional mächtiges Werkzeug für CI/CD. Wie Jenkins läuft es aktuell nur widerwillig auf einem Kubernetes-Cluster. Ein passendes Helm Chart steht jedoch zur Verfügung, und der offizielle Support von Kubernetes als Laufzeitumgebung ist angekündigt.
• Knative von Google kommt aus der Serverless-Ecke. Die Hauptfunktionsweise liegt derzeit jedoch bei der CI/CD-Strecke von Anwendungen als Source-to-Container-Build-Orchestrierung. An der Stelle verschmelzen Serverless und CI/CD-Ansätze. Das ist genau betrachtet kein Wunder, denn Serverless ist die radikal einfachste Form von CI/CD: Eine standardisierte, vollautomatisierte Pipeline, in die auf der einen Seite Code hinein- und auf der anderen eine laufende Anwendung herauskommt.
• Spinnaker positioniert sich im Bereich Continuous Delivery (Release, Deploy, Rollback) und nicht im Bereich Continuous Integration (Build, Analyze, Package). Spinnaker ist im CI/CD-Angebot der Google Cloud verbaut: CI übernimmt Google Cloud Build, CD Spinnaker. Die Stärke des Tools liegt in komplexen Release-Workflows, die vor allem größere Unternehmen benötigen: von Vieraugenfreigaben über Green/Blue-Deployments bis hin zu Canary-Releases.

Mehr Infos

Serverless Computing London

heise Developer veranstaltet zusammen mit The Register vom 12. bis zum 14. November in London eine englischsprachige Konferenz zum Thema Serverless Computing und Cloud Native. Der Autor dieses Artikels hat das Programm im Beirat der Entwicklerkonferenz mitgestaltet.

Neben den Herausforderern findet sich auch in der Jenkins Foundation kräftiger Cloud-Native-Schub: Nach dem Vorbild der Kubernetes-Community entstand eine Special Interest Group Cloud Native mit dem Ziel, Jenkins Schritt für Schritt besser auf Kubernetes lauffähig zu machen. Mit dem JenkinsX-Projekt entstand zudem eine CI/CD-Anwendung, die ähnlich wie Knative ausgerichtet ist. Es besteht aus einem Kommandozeilenwerkzeug zur Steuerung der CI/CD-Arbeitsabläufe und einer vorgefertigten Toolchain rund um Jenkins, Nexus und Helm, die sich auf Kubernetes deployen lässt.

Im Schatten der CI/CD-Ansätze sind mittlerweile wichtige Bausteine für einen reibungslosen CI/CD-Workflow auf Kubernetes entstanden wie Image Builder, die ohne Docker Daemon auskommen (Buildah, Kaniko) und Image-Tester (CST, dgoss).