Continuous Delivery – nicht nur für Container

Autor: Christian Sanabria

Es wird also davon geredet, Applikationen in einen Container zu verpacken und automatisiert über alle Stages zu verteilen. Nach wie vor, sind jedoch Plattformen, wie zbsp. Security Gateways oder Messaging Systeme, welche nur über ein Deployment von Konfigurationen kontrolliert werden, vorhanden. Wie sind solche Plattformen ebenfalls in einen modernen Deployment-Prozess mit Continuous Delivery Pipelines zu integrieren? Der nachfolgende Blog beantwortet genau diese Frage und zeigt auf, wie man den Business Value aus seinem Applikationsportfolio erhöhen kann.

Schnittstellen

Bedingung für die Integration von Plattformen in eine Pipeline ist das Vorhandensein einer Schnittstelle ausserhalb einer grafischen Benutzeroberfläche. Dies kann sowohl ein klassisches Rest API sein. Aber auch Befehle auf der Kommandozeile oder das Austauschen von Konfigurati-onsdateien fallen in diese Kategorie. Über diese Schnittstellen können Konfigurationsänderun-gen eingespielt werden. Mit der Integration in eine Pipeline sollte die grafische Benutzeroberflä-che nicht mehr oder nur noch in Support-Fällen genutzt werden.

Beispiel: Ein Web Service kann auf einem Security Gateway über eine SOAP Schnittstelle konfiguriert werden.

Abstraktion

Nun sollte nicht jede Person Zugriff auf solche Plattform-Schnittstellen und damit auch nicht auf die Plattform direkt erhalten. Mit einem Automatisierungs-Tool wie Ansible von Red Hat können solche Aufrufe remote durchgeführt werden. Die Aufrufe selbst werden durch eine spezifische Beschreibungssprache abstrahiert und in Skripten zusammengefasst. Bei Ansible heissen diese Skripte Playbooks.

Beispiel: Die SOAP Schnittstelle darf nicht von Entwicklern direkt aufgerufen werden, weshalb der Aufruf über einen speziellen Ansible User remote ausgeführt wird. Der Aufruf wird über ein Ansible Playbook abstrahiert, was das Handling von Request und Response stark vereinfacht. Das Playbook wird durch den Plattform-Betrieb erstellt.

Kontrolle

Der Aufruf eines solchen Playbooks sollte, gerade in einem betriebs- oder sicherheitskritischen Umfeld limitiert und vor allem überwacht werden. Dazu haben praktisch alle Tool-Hersteller erweiterte Funktionen für Unternehmen in ihrem Portfolio. Solche Features beinhalten zentrale Authentisierung und Autorisierung, Auditing und Monitoring sowie Konfigurationsmanagement. Für Ansible gibt es als Beispiel Ansible Tower von Red Hat, welches solche Unternehmens-Funktionen über eine grafische Benutzeroberfläche anbietet.

Beispiel: Das Playbook darf nur in Non-Production Stages direkt durch Entwickler ausgeführt werden. Für eine Ausführung auf der Production Stage ist hingegen ein Approval nötig. Dafür werden in Ansible Tower Rollen und Regeln definiert, über welche der Zugriff auf die einzelnen Stages kontrolliert wird. Diese Rollen und Regeln werden ebenfalls durch den Plattform-Betrieb verwaltet und vergeben. Die Konfiguration für die einzelnen Stages wird durch Entwickler definiert.

Orchestrierung

Idealerweise lässt sich ein Playbook über Ansible Tower nicht nur über die grafische Oberfläche, sondern auch über ein Rest API aufrufen. Dieses API spielt die zentrale Rolle bei der Integration in einen bestehenden Entwicklungs- und Deployment-Prozess. Entwickler, gerade in einem agi-len Umfeld, möchten ihre Continuous Delivery Pipeline über ein zentrales Tool steuern. Über ein API lassen sich Automatisierungs-Tools einfach in ein Pipeline-Tool (zbsp. Jenkins) integrieren.

Beispiel: Beim Release des Web Services wird in Jenkins die Continuous Delivery Pipeline angestossen. Die Pipeline startet über das Ansible Tower API die Deployments der Konfiguration in die einzelnen Stages des Security Gateways. Da der Jenkins User keine Berechtigung für den Production Stage hat, wartet die Pipeline auf das Approval in Ansible Tower. Sobald der Plattform-Betrieb das Approval gegeben hat, wird der Web Service auch auf den Production Stage des Security Gateways deployed.

Fazit

Auch ohne Container und PaaS ist es möglich, DevOps und Continuous Delivery einzuführen. Der Aufwand ist dabei oftmals hoch, da viele Plattformen eigene Schnittstellen ohne Standards anbieten und diese zuerst in einem Automatisierungs-Tool abstrahiert werden müssen. Sobald dieser Initialaufwand jedoch umgesetzt wurde, rechtfertigt sich die Investition sehr schnell.

Entwickler können ihre bestehenden Continuous Delivery Pipelines weiterverwenden und sich voll auf die Umsetzung von Business Features fokussieren. Plattform-Betreiber müssen Konfigurationen nicht mehr manuell auf Zuruf einspielen, sondern können sich ganz der Plattform zuwenden.

Dadurch verkürzt sich die Time-to-Market von neuen Features und die Qualität nimmt durch automatisierte Tests in der Pipeline zu. Beides erhöht den Business Value. Einerseits können so Business Ideen schneller veröffentlicht werden, was zu einem Marktvorteil führen kann. Andererseits steigt die Reputation durch stabile Software, wodurch neue Kunden gewonnen werden können.

ipt unterstützt Ihr Unternehmen dabei bei jedem Schritt in der Umsetzung von Automatisierungen und der Einführung von Continuous Delivery Pipelines. Angefangen bei der Erstellung eines Konzepts über die Evaluation der passenden Tools sowie die Integration der Tools in Ihre bestehende IT-Landschaft.