CI und Deployment trennen
Software sicher mit GitOps verteilt
Effizienz und Cybersicherheit sind zwei wichtige Aspekte in der Softwareentwicklung. GitOps ist ein Ansatz, um beides zu verbessern. Zugleich wird die Handlungsfähigkeit von Entwicklungsteams gesteigert.
Im ‚2020 CIO Survey – Industrial Manufacturing Industry Insights‘ haben 65 Prozent der IT-Führungskräfte in der Fertigungsindustrie angegeben, dass die betriebliche Effizienz die wichtigste Leistung ist, die von ihren Abteilungen erwartet wird. Außerdem haben 50 Prozent der Unternehmen angegeben, dass Cyber-Security ihre Top-Investition sei. Ein Grund dafür ist die gewachsene Angriffsfläche durch vermehrtes Homeoffice, ein anderer sind die Auswirkungen eines Produktionsausfalls durch Cyberattacken. Beide Herausforderungen lassen sich durch das GitOps-Konzept adressieren. Der Ansatz ist im DevOps-Umfeld entstanden und kann sowohl in Verbindung mit DevOps als auch eigenständig eingesetzt werden. Entwicklungsteams erhalten damit Werkzeuge, um den Betrieb von Softwareanwendungen eigenständig zu übernehmen und die Effizienz zu steigern. Die Sicherheit der Infrastruktur wird durch eine Richtungsumkehr des Deployments vom Push zum Pull-Prinzip erreicht.
Das klassische Vorgehen
GitOps lässt sich im Vergleich zu CI/CD-Pipelines gut beschreiben, hier kurz CIOps. Die erste Abbildung zeigt eine vereinfachte CIOps-Pipeline: Klassischerweise wird dabei ein CI-Server über Änderungen an einem Repository informiert. Er führt daraufhin einen Build durch und deployt anschließend die geänderte Anwendung auf einen Server (Push-Prinzip). In der Praxis ist eine CIOps-Pipeline in eine Staging- und Produktionsumgebung aufgeteilt, bei denen die Automatisierung des Deployments durch die Verwendung von Branches in der Versionsverwaltung, etwa Git, umgesetzt werden kann. Nachteil an diesem Vorgehen: Der Prozess ist langsam, da für jedes Deployment ein Build im CI-Server durchlaufen werden muss. Eigentlich ist aber gar kein neuer Build notwendig, da das gleiche Artefakt auf allen Stages ausgeliefert werden könnte. Außerdem benötigt der CI-Server Zugriff auf die Betriebsumgebung, was in Bezug auf die Sicherheit nachteilig ist. Die neunte Ausgabe von Rockwell Automations „State of Smart Manufacturing“ Report liefert Einblicke in Trends und Herausforderungen für Hersteller. Dazu wurden über 1.500 Fertigungsunternehmen befragt, knapp 100 der befragten Unternehmen kommen aus Deutschland. ‣ weiterlesen
KI in Fertigungsbranche vorn
Wie GitOps funktioniert
Im Gegensatz zu CIOps werden mit GitOps Änderungen nach dem Pull-Prinzip in die Produktion überführt. So wird die kontinuierliche Integration (CI) einer Anwendung vom eigentlichen Deployment-Prozess getrennt. Das heißt, der CI-Server übernimmt nicht mehr das Deployment, sondern führt nur noch Build und Tests durch und schiebt Artefakte, etwa Docker Images, in eine Registry. Die zweite Abbildung zeigt, wie eine GitOps-Pipeline aussehen kann. GitOps verbessert so zum einen die Sicherheit, da kein schreibender Zugriff durch den CI-Server von außerhalb des Clusters notwendig ist. Zum Anderen ist es effizienter, da eine Anwendung nur einmal gebaut werden muss und das Artefakt anschließend in unterschiedlichen Umgebungen deployt werden kann. Ein weiterer Unterschied zu CIOps ist, dass mit GitOps der Sollzustand einer Umgebung beschrieben wird und spezielle Tools kontinuierlich einen Soll-/Ist-Abgleich durchführen. Abweichungen und Fehler werden so automatisiert erkannt und korrigiert. Diese Tools werden als Operatoren oder auch Custom Controller bezeichnet. Die Abstimmungsschleife zwischen Soll- und Ist-Zustand wird als Reconciliation Loop bezeichnet. Der Thin[gk]athon, veranstaltet vom Smart Systems Hub, vereint kollaborative Intelligenz und Industrie-Expertise, um in einem dreitägigen Hackathon innovative Lösungsansätze für komplexe Fragestellungen zu generieren. ‣ weiterlesen
Innovationstreiber Thin[gk]athon: Kollaborative Intelligenz trifft auf Industrie-Expertise
Nützliche Effekte
Der GitOps-Ansatz bringt mehrere Vorteile: Wie schon erwähnt wird die Sicherheit verbessert, da der GitOps-Operator Deployments durchführen kann und sich dieser innerhalb des Clusters befindet. So wird kein Zugriff von außen mehr auf den Cluster benötigt. Darüber hinaus ist der Zugriff auf Git oft einfacher zu organisieren als auf einen API-Server. Nicht nur, dass gegebenenfalls eine Firewall-Freischaltung entfällt, auch die Entwicklungsteams sind mit Git vertraut. GitOps ist im Umfeld von Kubernetes (k8s) entstanden. Nutzt ein Unternehmen kein Kubernetes, ermöglichen Tools die Anwendung von GitOps dennoch. Der zentrale Bestandteil in GitOps ist die vollständige deklarative Beschreibung des Zustands in Git. Dadurch ist ein anderes Vorgehen gefragt als in klassischen CIOps-Pipelines. So müssen jeweils passende Operatoren benutzt werden, die den Kubernetes API-Server um sogenannte Custom Resource Definitions (CRDs) erweitern und Custom Resources (CRs) bereitstellen. Anwendungsfälle mit speziellen Operatoren sind etwa der Einsatz von Templating-Werkzeugen wie Helm oder Kustomize, die Ver- und Entschlüsselung von Secrets, da diese mit GitOps in Git gespeichert werden müssen, sowie die Realisierung von Deployment-Strategien wie Canary Releases, A/B-Tests und Blue/Green Deployments.
GitOps ausprobieren
Mit seinen vielen Operatoren könnte sich die GitOps-Methode zunächst nur schwer nachvollziehen lassen. Ein Umsetzungsbeispiel bietet der Open Source GitOps Playground. Das Repository beinhaltet eine reproduzierbare GitOps-Infrastruktur mit Kubernetes Cluster, CI-Server (Jenkins), Source Code Management (SCM-Manager) und unterschiedlichen GitOps-Operatoren (Flux und ArgoCD), auf der die Komponenten bereits mit Beispielapplikationen vorkonfiguriert sind. Außerdem zeigt der GitOps Playground eine Umsetzung von Monitoring und Alerting mit Grafana und Prometheus.
