SwiftDeploy: Infrastruktur wird automatisch generiert – so funktioniert das Tool

SwiftDeploy ist ein Open-Source-Tool, das die manuelle Erstellung von Infrastruktur-Konfigurationen überflüssig macht. Statt dutzende Konfigurationsdateien wie nginx.conf oder docker-compose.yml manuell zu pflegen, reicht eine zentrale Datei – das Manifest. Aus dieser werden alle weiteren Dateien automatisch generiert. Ein zentrales Prinzip des Tools: Der Manifest-Datei kommt die Rolle der einzigen verlässlichen Quelle zu. Jede Änderung im Manifest führt zur Neugenerierung aller abhängigen Dateien. So bleibt die Infrastruktur konsistent und frei von manuellen Fehlern.

Eine neue Perspektive: Infrastruktur als Code – aber automatisiert

Die meisten DevOps-Prozesse basieren darauf, Konfigurationen manuell zu schreiben oder anzupassen. SwiftDeploy dreht dieses Prinzip um. Statt selbst Hand anzulegen, beschreibt man die gewünschte Infrastruktur in einer einzigen Datei – manifest.yaml. Das Tool liest diese Datei und generiert daraus alle notwendigen Konfigurationen. Die Vorteile liegen auf der Hand:

• Einheitliche Quelle: Alle Konfigurationen stammen aus einer Datei. Keine versteckten Abhängigkeiten oder manuelle Anpassungen.
• Automatische Konsistenz: Jede Änderung im Manifest führt zur Neugenerierung aller Dateien. Keine manuellen Anpassungen mehr nötig.
• Wiederholbare Prozesse: Durch das Löschen und Neugenerieren der Konfigurationen kann die Infrastruktur jederzeit reproduziert werden.

Die technische Umsetzung basiert auf Vorlagen mit Platzhaltern. SwiftDeploy nutzt zwei Vorlagendateien:

• templates/nginx.conf.tmpl enthält Platzhalter wie {{NGINX_PORT}} und {{SERVICE_PORT}}.
• templates/docker-compose.yml.tmpl nutzt Platzhalter wie {{SERVICE_IMAGE}} und {{SERVICE_MODE}}.

Beim Ausführen von swiftdeploy init ersetzt das Tool diese Platzhalter durch die tatsächlichen Werte aus dem Manifest. Ein Beispiel für die Umsetzung zeigt dieser Befehl:

sed -e "s|{{NGINX_PORT}}|8080|g" templates/nginx.conf.tmpl > nginx.conf

Dadurch wird sichergestellt, dass keine Werte hartkodiert sind. Änderungen im Manifest führen zu frischen Konfigurationen – ohne manuellen Eingriff.

Sicherheit durch isolierte Entscheidungsmechanismen

SwiftDeploy setzt auf den Open Policy Agent (OPA) als externe Entscheidungsinstanz. OPA ist ein separates Tool, das Regeln in der Sprache Rego ausführt und Ja/Nein-Entscheidungen trifft. Der entscheidende Vorteil: Die Logik für Sicherheits- und Compliance-Regeln ist vollständig von der Hauptanwendung getrennt. Das bedeutet:

• Flexible Anpassungen: Änderungen an Richtlinien erfordern keine Anpassungen im Hauptcode. Es reicht, die Rego-Regeln in einer separaten Datei zu bearbeiten und OPA neu zu starten.
• Zentrale Steuerung: Alle Richtlinien und Schwellenwerte sind in einer einzigen Quelle definiert – der Policy-Engine.

Ein konkretes Beispiel für eine Infrastrukturrichtlinie zeigt, wie OPA Entscheidungen trifft:

package infrastructure

default allow := false

allow if {
  input.disk_free_gb >= data.thresholds.min_disk_free_gb
  input.cpu_load <= data.thresholds.max_cpu_load
}

Die Schwellenwerte werden in einer separaten JSON-Datei definiert. Wird diese angepasst, wirkt sich das sofort auf die Entscheidungen von OPA aus. Ein weiteres Beispiel zeigt die Richtlinie für Canary-Releases:

package canary

allow if {
  input.error_rate <= data.thresholds.max_error_rate
  input.p99_latency_ms <= data.thresholds.max_p99_latency_ms
}

Hier wird geprüft, ob die Fehlerrate unter 1 % und die Latenz unter 500 ms liegt. Überschreitet eine dieser Metriken den Schwellenwert, wird der Canary-Release blockiert. Das Tool gibt eine klare Fehlermeldung aus, die den Grund für die Ablehnung nennt.

Chaos-Tests: Wie SwiftDeploy auf Ausfälle reagiert

Ein zentrales Feature von SwiftDeploy ist die Möglichkeit, gezielt chaotische Szenarien zu simulieren. Das Tool bietet einen Endpunkt /chaos, der es ermöglicht, Fehlerraten und Latenzen künstlich zu erhöhen. Ein Beispiel zeigt, wie ein Fehler von 80 % injiziert wird:

curl -X POST  \
  -d '{"mode": "error", "rate": 0.8}'

Versucht man nun, einen Canary-Release in die stabile Umgebung zu promovieren, wird dieser automatisch blockiert. SwiftDeploy prüft die Metriken und erkennt, dass die Fehlerrate den definierten Schwellenwert überschreitet. Die Fehlermeldung lautet:

Error rate 80.00% exceeds maximum 1.00%

Erst nach der Behebung des Problems und einem Neustart der API können die Metriken zurückgesetzt und der Canary-Release erfolgreich promoviert werden. Dieses Verhalten demonstriert, wie durch die Policy-Engine sichergestellt wird, dass keine fehlerhafte Infrastruktur in die Produktion gelangt.

Echtzeit-Metriken und automatisierte Berichte

SwiftDeploy bietet eine integrierte Metrik-Erfassung im Prometheus-Format. Die API stellt diese Daten über den Endpunkt /metrics bereit. Ein Beispiel zeigt die Ausgabe:

http_requests_total{method="GET",path="/",status_code="200"} 42
http_request_duration_seconds_p99 0.0034
app_mode 1
chaos_active 0

Das Tool swiftdeploy status liest diese Metriken alle drei Sekunden ein und visualisiert sie in einem Live-Dashboard. Zusätzlich werden alle Scrapes in einer Datei namens history.jsonl gespeichert. Mit dem Befehl swiftdeploy audit wird diese Datei analysiert und ein detaillierter Bericht in Markdown-Format generiert:

• Moduswechsel (z. B. von Canary zu Stable)
• Fehlerraten und Latenzmetriken
• Verstoß gegen definierte Richtlinien

Dieser Bericht dient als Grundlage für Compliance-Prüfungen und ermöglicht eine lückenlose Nachverfolgung von Infrastrukturänderungen.

Wichtige Erkenntnisse aus der Entwicklung

Die Entwicklung von SwiftDeploy brachte einige wertvolle Lehren mit sich. Eine der wichtigsten Erkenntnisse betrifft die Abhängigkeiten zwischen Containern. OPA muss vor der Ausführung von Richtlinienprüfungen vollständig gestartet sein. Eine Verzögerung von vier Sekunden nach dem Start von OPA hat sich als notwendig erwiesen, um zuverlässige Ergebnisse zu gewährleisten.

Ein weiteres Thema waren kumulative Metriken. Fehlerraten und Latenzwerte werden in Zählern gespeichert, die nicht automatisch zurückgesetzt werden. In der Produktion wäre ein gleitendes Zeitfenster sinnvoll, um die Genauigkeit der Daten zu erhöhen.

Die Entscheidung für Go als Programmiersprache erwies sich als optimal. Die generierte Binärdatei von SwiftDeploy ist nur 11,9 MB groß – ein deutlicher Vorteil gegenüber einer Python-Implementierung, die leicht 200 MB überschreiten würde. Die Verwendung einer einzigen Binärdatei ohne Abhängigkeiten ermöglicht einen schnellen Start und eine einfache Bereitstellung.

Ein weiterer wichtiger Punkt: Generierte Konfigurationsdateien gehören nicht in das Versionskontrollsystem. Sie werden aus dem Manifest abgeleitet und sollten bei jedem Klonen des Repos durch Ausführen von swiftdeploy init neu generiert werden. Dies stellt sicher, dass alle Teammitglieder stets mit den aktuellen Konfigurationen arbeiten.

SwiftDeploy zeigt, wie moderne Tools die Erstellung und Verwaltung von Infrastruktur vereinfachen können. Durch die Kombination aus automatisierter Generierung, isolierten Richtlinienprüfungen und integrierter Metrik-Erfassung wird die Bereitstellung von Anwendungen nicht nur schneller, sondern auch sicherer und zuverlässiger. Die Entwicklung des Tools unterstreicht die Bedeutung von Best Practices wie der Trennung von Entscheidungslogik, der Verwendung von Vorlagen und der kontinuierlichen Überwachung von Metriken. Für Teams, die nach einer effizienten und sicheren Lösung für die Infrastrukturverwaltung suchen, könnte SwiftDeploy eine wertvolle Ergänzung sein.