Continuous Delivery, Cloud & Agilität – das Dreamteam?

Die Deklaration von Zielzuständen ermöglicht dem Benutzer, sich voll und ganz auf das Was zu fokussieren, ohne das Wie kennen zu müssen. Beispiel 1 verdeutlicht dies – ein CF-Template wird in der Amazon-Cloud ausgerollt, der Benutzer benötigt kein Wissen, wie der Deployment-Prozess im Detail funktioniert (am Beispiel gitlab-ci). Der Mehrwert von deklarativem Arbeiten entsteht durch die Testbarkeit der Pipeline-Manifeste sowie die Wiederverwendbarkeit von Artefakten über verschiedene Pipelines hinweg, zeigt sich für den Benutzer allerdings erst bei häufiger Nutzung.

Ein konkretes Problem stellt sich bei CF-Templates: Es ist vom Hersteller nicht vorgesehen, Templates zu parametrisieren. Diese Funktionalität kann wichtig sein, wenn wir in der Pipeline zwischen Test- und Produktionsumgebung unterscheiden wollen, aber gleichzeitig sicherstellen wollen, dass exakt der gleiche Stand des CF-Templates ausgerollt wird – als Beispiel sei hier der Datenbankname für unsere Anwendung genannt, der sich in den verschiedenen Umgebungen unterscheidet. Hier hilft uns ein Tool wie cfnsphere [1], welches die fehlende Parametrisierung nachrüstet und unsere Arbeit erheblich vereinfacht.

Alles wird Code – Wissen automatisieren

Findet sich die Beschreibung der Cloud-Infrastrukturen als Manifest wieder (YAML oder JSON seien hier als Beschreibungssprachen genannt), gewinnen wir die Möglichkeit dazu, diese Dateien vor dem Deployment auf Muster- bzw. Regelverletzungen zu untersuchen. Setzen wir die vom Unternehmen erstellten Governance-Richtlinien ebenfalls in Code um, können wir beispielsweise CF-Templates mit diesem Code überprüfen – die automatisierte Governance-Ausübung entsteht.

Listing 1 zeigt eine einfache Regel, implementiert in CFN_NAG [2], die überprüft, dass im CF-Template keine Standard-Benutzernamen für RDS-Datenbanken verwendet werden. Ähnliche Tools stehen für Kubernetes bereit [3], sind aber noch unreif für den Produktionseinsatz, da sie noch nicht alle relevanten Ressourcentypen unterstützen. In der Kubernetes-Welt ist die automatisierte Governance eher in der Plattform anzusiedeln, beispielsweise durch die Nutzung von Admission Controllers oder dem Operator Framework.

Listing 1:

require 'spec_helper'
require 'cfn-model'
require 'cfn-nag/custom_rules/RDSInstanceMasterUsernameRule'

describe RDSInstanceMasterUsernameRule, :rule do
  context 'RDS instance with NoEcho username' do
    it 'returns offending logical resource id' do
      cfn_model = CfnParser.new.parse read_test_template('json/rds_instance/rds_instance_no_echo_username.json')

      actual_logical_resource_ids = RDSInstanceMasterUsernameRule.new.audit_impl cfn_model
      expected_logical_resource_ids = %w[]

      expect(actual_logical_resource_ids).to eq expected_logical_resource_ids
    end
  end

  context 'RDS instance with literal username' do
    it 'says all is well' do
      cfn_model = CfnParser.new.parse read_test_template('json/rds_instance/rds_instance_literal_username.json')

      actual_logical_resource_ids = RDSInstanceMasterUsernameRule.new.audit_impl cfn_model
      expected_logical_resource_ids = %w[BadDb]

      expect(actual_logical_resource_ids).to eq expected_logical_resource_ids
    end
  end

  context 'RDS instance with NoEcho parameter that has default' do
    it 'says all is well' do
      cfn_model = CfnParser.new.parse read_test_template('json/rds_instance/rds_instance_no_echo_with_default_username.json')

      actual_logical_resource_ids = RDSInstanceMasterUsernameRule.new.audit_impl cfn_model
      expected_logical_resource_ids = %w[BadDb2]

      expect(actual_logical_resource_ids).to eq expected_logical_resource_ids
    end
  end
end

Grundvoraussetzung für die Implementierung von Governance-Richtlinien ist das Vorhandensein eben jener, im Idealfall in einer Fassung, die für alle im Unternehmen Gültigkeit besitzt und uns eine Möglichkeit bietet, über Änderungen am Regelwerk automatisiert informiert zu werden. Die einfachste Implementierung ist hier, das Regelwerk-Dokument als einfache Textdatei in einem Git-Repository abzulegen und bei jeder Änderung eine Mail-Benachrichtigung zu erzeugen.

Das Team welches das Continuous-Delivery-Produkt verantwortet, konvertiert in unserem Beispiel die menschenlesbaren Richtlinien in Code – es ist ebenfalls denkbar, dass die Veröffentlichung der Regeln direkt als Code stattfindet und die Verantwortung für die Codifizierung der Regeln mit der Verantwortung für die Regeln selbst zusammenfällt. So sparen wir uns Interpretations- und Übersetzungsfehler, Rückfragen und unklare Verantwortlichkeiten.

Continuous-Delivery-as-a-Service: Integrationsschicht erzeugt den Mehrwert

Nach der Entscheidung, welche Arbeitsweise wir den Teams zukünftig anbieten wollen und der Implementierung der Governance-Richtlinien in Code können wir uns an die Integration der einzelnen Elemente wagen, entsteht hier doch der eigentliche Mehrwert: durch die Vollautomatisierung des Prozesses und die nahtlose Integration der Werkzeuge in die Pipeline, bringen wir die Interessen des Unternehmens in Einklang mit den Interessen der Teams. Zunächst sollten wir uns Gedanken machen, welches CD-Tool als Grundlage zum Einsatz kommen soll – hierbei gilt es verschiedene Entscheidungskriterien zu berücksichtigen:

• Haben wir schon CD-Tool(s) im Einsatz?
• Welche Erfahrungen haben wir mit diesen Tools hinsichtlich Wartbarkeit und Integration gemacht und wieviel Wissen haben wir im Haus?
• Integrations- und Beschaffungskosten,
• Ggfs. weitere, individuelle Kriterien.

Die folgenden Beispiele sind mit Hilfe von gitlab-ci, dem CI/CD-Tool von gitlab [4], aufgebaut – eine andere Option kann auch der Microsoft Visual Studio Team Service [5] oder Travis CI [6] sein. Das Setup bzw. die Integration von CD-Tools in bestehende Landschaften wird hier nicht weiter beschrieben.

Im folgenden Beispiel zeigen wir den Aufbau eines Continuous-Delivery-as-a-Service-Produktes für das Deployment von Ressourcen in der Amazon Cloud AWS. Der Gesamtaufbau in Abb. 2 beschrieben.

Für das Gesamtprodukt ergibt sich die Auswahl folgender Bestandteile:

• Gitlab-ci als CD-Tool für die eigentliche Pipeline,
• CFN_NAG als Linting-Tool für CF-Templates,
• Cfnsphere für die Parametrisierung von CF-Templates,
• Docker-Container als Laufzeitumgebung und
• Awscli für die Interaktion mit der API der Amazon Cloud.

Gitlab-ci nutzt Docker-Container für die Ausführung der Pipeline-Artefakte – ein Umstand, den wir uns für die Implementierung zu Nutze machen können, in dem wir CFN_NAG, cfnspere und die AWS CLI in einem Container verpacken (im weiteren AWS-Deployment-Container genannt). Wichtig hierbei ist der Container Entry Point [7], über den wir sicherstellen, dass ein ganz bestimmtes Programm im Container gestartet wird – im Beispiel ein Shellscript-Wrapper, der cfnsphere aufruft und den weiteren Prozess steuert. Über den Entrypoint stellen wir sicher, dass immer der Wrapper ausgeführt wird, der seinerseits sicherstellt, dass die Governance-Überprüfung stattfindet, die somit forciert wird. Der Workflow im AWS-Deployment-Container ist in Abb. 3 beschrieben.

Der Wrapper im Container Entry Point sorgt ebenfalls dafür, dass wir in der Pipeline selbst deklarativ arbeiten können. Wir geben noch den Container an, der gestartet werden soll (cdaas_aws_deploy) – und die Stacks-Datei von cfnsphere, die ihrerseits die Parameter selbst enthält und das eigentliche CF-Template referenziert (vgl. Abb. 4 & 5).

Der Container als solches ist aber nur ein Teil der Lösung – es fehlt die Laufzeitumgebung, der gitlab runner. Vergleichbar mit Build Slaves in Jenkins, stellen die Runner in gitlab eine Laufzeitumgebung bereit, in der unsere Pipeline ausgeführt wird, konkret: in der unsere Container laufen. Um Deployments in die Amazon Cloud durchführen zu können, brauchen wir einen Runner pro Ziel-Account, mehrere Repositories an einem Runner oder mehrere Runner an einem Repository sind ebenfalls möglich. Unsere Container legen wir in einer Docker Registry oder kompatiblen Services wie Artifactory ab. Um sicher zu stellen, dass nur unsere Container in der Pipeline laufen können, limitieren wir den Runner auf unsere Registry/ unser Artifactory-Repository (s. Abb. 6).

Mit Container und Runner findet nun also der Interessenausgleich zwischen Unternehmen (Governance u. a.) und den Teams (Zugänglichkeit u. a) statt – wir stellen sicher, dass die Governance-Richtlinien eingehalten werden, während die Lösung für den Endbenutzer einfach und zugänglich bleibt.  

In ähnlicher Weise zur Anbindung von AWS können Anbindung für Azure, Kubernetes und andere Cloud-Provider und -Services geschaffen werden.