DevOps ist eine Softwareentwicklungskultur, ein Ansatz und eine Reihe von Tools, die die Integration und Zusammenarbeit zwischen traditionell getrennten Entwicklungs-, Betriebsarbeiten und Teams fördern sollen. Die Verbesserung der Effizienz durch die Automatisierung sich wiederholender manueller Aufgaben bei der Integration und Bereitstellung (CI/CD-Pipelines) von Software-Iterationen steht im Mittelpunkt eines DevOps-Ansatzes. Eine DevOps-Architektur integriert die Tools, die diese Automatisierung ermöglichen, in das Design einer Softwareanwendung und der Infrastruktur, die zwischen den Nicht-Produktions- (Entwicklung und Tests) und Produktionsumgebungen (Betrieb) liegt.
In diesem Blog werden wir versuchen, ein besseres Verständnis für die Besonderheiten einer DevOps-Architektur zu schaffen, indem wir den DevOps-Ansatz vorstellen und ein spezielles Beispiel für eine Anwendungsarchitektur beschreiben, die von einem leitenden DevOps-Engineer von K&C entworfen wurde. Sie werden sehen, wie diese Architektur eine Reihe von Anforderungen für eine Cloud-native Webanwendung erfüllt, unter Berücksichtigung von:
Anwendungsanforderungen
- Cloud-native
- Minimierung des Risikos der Anbieterbindung so weit wie möglich
Cloud-native Infrastruktur
- Verwendung von AWS-nativen Komponente, sofern verfügbar, um Wartungskosten und Komplexität zu reduzieren
- Keine agnostische Cloud-Infrastruktur erforderlich
Web-Anwendungs-Firewall (WAF)
- Schutz der webbasierten Anwendungen vor gängigen Angriffen wie SQL-Injektionen, Cross-Site-Scripting und anderen Sicherheitslücken
- Audit-Protokolle
- Verteilung des Anwendungsverkehrs auf mehrere Ziele
Schlüsselverwaltung
- Verwalten Sie kryptografische Schlüssel und kontrollieren Sie Audit-Protokolle, um Complicane-Anforderungen zu erfüllen.
Monitoring (Überwachung)
- Die Überwachung sollte in separaten, von der Anwendung unabhängigen Umgebungen erfolgen, um eine hohe Stabilität zu gewährleisten.
- Automatisierte Überwachung aller Phasen + Bereitstellungspipelines
- Hierarchische Organisation der folgenden Metriken:
- Leistung
- Geschäftslogik
- Sicherheit
- Entwicklung instrumentiert
Speicherung
- Jedes Entwicklungsprojekt kann frei über das optimale DBMS entscheiden
- Aus einer DevOps-Perspektive sind möglichst wenige verschiedene AWS-native DBMS wünschenswert
Entwicklungstools
- Integrierte und native Entwicklungskette für CI/CD
- GitOps Git als Single Source of Truth für deklarative Infrastruktur ist ein interessanter Trend. Analyse des potenziellen Nutzens im Kontext der Anwendung
Sicherheit
- Analyse der Codequalität
- Sicherheitsprüfung von Inhouse- und Open-Source-Code auf Konformität mit OWASP-Standards
Management-Console
Wenn AWS EKS anstelle von OpenShift verwendet wird, sollten wir eine einfachere intuitivere Benutzeroberfläche für die Kubernetes-Verwaltung in Betracht ziehen, um den Wartungsaufwand zu optimieren.
Cloud Identity and Access Management (IAM)
- Das Rollenkonzept
- Trennung der Aufgaben
- Bereitstellung/De-Provisionierung
- Auditing von Berechtigungen und erfolgreichen / fehlgeschlagenen Zugriffen
- Rotierende Hauptschlüssel
Bevor wir jedoch ein Beispiel für eine DevOps-Architektur vorstellen und aufschlüsseln, die diese Projektanforderungen erfüllt, wollen wir kurz darauf eingehen, warum DevOps-Berater, -Architekten und -Teams derzeit die gefragtesten Dienstleistungen eines IT-Dienstleisters sind.
Was ist DevOps?
DevOps selbst ist eine Reihe von Best Practices, die eingeführt wurden, um traditionell getrennte Entwicklungs- und Betriebsteams, die für eine einzige Anwendung verantwortlich sind, zu einem ganzheitlichen Team zu vereinen. Als Modus Operandi der Organisationskultur beseitigt DevOps die Barrieren zwischen den Entwicklungs- und Testumgebungen und der Produktionsumgebung.
Dadurch wird das traditionelle Potenzial für Spannungen zwischen Entwicklung und Produktion vermieden, wenn eine produktionsreife Iteration einer neuen Funktion vom Entwicklungsteam an das Betriebsteam übergeben wird, aber in der Produktion auf Probleme stößt. Es vermeidet das Potenzial für ein „Schuldspiel“ und die Zeit- und Ressourcenverschwendung, die eine unvermeidliche Folge davon sind, dass eine neue Funktion in der Produktion nicht reibungslos funktioniert, obwohl in der Entwicklungs- und Testumgebung keine Probleme aufgetreten sind.
In einer DevOps-Kultur gibt es kein Dev und Ops, sondern nur DevOps. Der Schlüssel zu diesem ganzheitlichen Ansatz ist die Automatisierung der Tests, der Bereitstellung und der anschließenden Überprüfung bzw. Überwachung in der Produktion. Dieser automatisierte Prozess ist die CI/CD-Pipeline, d. h. kontinuierliche Integration und entweder kontinuierliche Lieferung (delivery) oder kontinuierliche Bereitstellung (deployment).
Ein gut ausgeführter DevOps-Ansatz führt zu einer besseren Softwarequalität, die in kürzerer Zeit bereitgestellt wird. Dies führt zu einer Senkung der Gesamtkosten für die Softwareentwicklung und verbessert die Geschäftsabläufe.
Eine DevOps CI/CD-Pipeline wird durch den Einsatz verschiedener Tools, Technologien und Prozesse erreicht.
Eine DevOps-Architektur, welche die Anforderungen unserer Cloud-nativen Webanwendung erfüllt
Der Aufbau einer Cloud-nativen Webanwendung nach DevOps-Prinzipien beinhaltet die Integration von DevOps-Tools und -Technologien, die uns eine CI/CD-Pipeline bieten. Da die Anforderung auch darin bestand, eine DevOps-Architektur für AWS zu erstellen, beeinflusste dies auch die Wahl der zu verwendenden Tools und Technologien.
Unsere beiden Vorschläge für eine DevOps-Architektur, von denen einer nur auf AWS EKS basierte. Alternativ empfehlen wir eine Kombination aus AWS EKS und OpenShift, die AWS-native und Open-Source-DevOps-Tools und -Technologien vereint.
Die beiden Vorschläge für die DevOps-Architektur waren:
Referenz DevOps-Architektur 1 – AWS EKS
Referenz DevOps Architektur 2 – AWS EKS + OpenShift
Der Unterschied zwischen den beiden bestand darin, dass Helm für die Verwaltung des Kubernetes-Clusters in dem DevOps-Architekturvorschlag verwendet werden musste, bei dem OpenShift nicht zum Einsatz kam und nur Amazon EKS verwendet wurde.
Gehen wir die Rolle jeder Komponente oder jedes Tools durch, die Teil der DevOps-Architekturprototypen sind.
Amazon EKS
Amazon Elastic Kubernetes Service (Amazon EKS) ist der nativ verwaltete Kubernetes-Container-as-a-Service (CaaS) von AWS. Er vereinfacht die Ausführung von Kubernetes-Clustern auf AWS, indem er die Installation, den Betrieb und die Wartung einer eigenständigen Kubernetes-Kontrollebene überflüssig macht, die stattdessen von EKS verwaltet wird.
Amazon EKS ist in der Lage, abnormale Instanzen der Steuerebene (Knoten), die zum Auslöser eines Problems werden könnten, zu erkennen und zu ersetzen und sie bei Bedarf automatisch über Availability Zones innerhalb der Region neu zu starten. EKS sorgt für die Hochverfügbarkeit von Kubernetes-Clustern, indem es die Architektur der AWS-Regionen nutzt, um jeden einzelnen Ausfallpunkt zu eliminieren.
Der von AWS verwaltete Kubernetes-Cluster ist nicht mehr anfällig für den Ausfall einer oder mehrerer Availability Zones und damit wesentlich widerstandsfähiger.
Im Gegensatz zur OpenShift/EKS-Alternative arbeitet unsere EKS-basierte DevOps-Referenzarchitektur mit Heptio zusammen, um Kubernetes RBAC mit IAM-Authentifizierung zu integrieren.
OpenShift Container Plattform
OpenShift ist eine „Gruppe von Containerisierungssoftware“, die von RedHat entwickelt wurde, und die OpenShift-Container-Plattform lässt sich am besten als private Plattform-as-a-Service (PaaS) beschreiben. OpenShift kann auf einer privaten Cloud oder einem Bare-Metal-Server vor Ort bereitgestellt und verwaltet werden oder auf die Infrastruktur eines Cloud-Anbieters – in diesem Fall AWS – aufgesetzt werden.
Der vollständig verwaltete OpenShift-Service wird auf AWS bereitgestellt und betrieben, wobei die beiden Unternehmen zusammenarbeiten, um einen kombinierten Service anzubieten, der von beiden Seiten unterstützt und direkt von AWS zusammen mit anderen AWS-eigenen Ressourcen und Tools, die ein Kunde nutzt, abgerechnet wird.
OpenShift vs. AWS EKS für Kubernetes management und orchestration
Unsere empholene DevOps-Architektur verwendet OpenShift anstelle einer reinen AWS-nativen EKS-Lösung, und zwar aus mehreren Hauptgründen:
AWS Elastic Kubernetes Services (EKS)
Pros
- Native Unterstützung durch Amazon
- Native KMS-Unterstützung
Cons
- Zusätzliche Management-UI erforderlich (wie Rancher)
OpenShift
Pros
- Einfache Out-of-the-Box-Einstellung für Sicherheit und Netzwerk ermöglichken einen schnellen Start
Cons
- Keine native Implementierung durch AWS
- Zusätzlicher Anbieter (Red Hat) erhöht die Komplexität
- OpenShift-Vorlagen sind weniger flexibel als Helm-Diagramme
Felxibilität
OpenShift bietet mehr Flexibilität bei der Bereitstellung, da K8s-Cluster sowohl vor Ort als auch in AWS bereitgestellt werden können. Dies kann ein großer Vorteil für Unternehmen sein, die noch Daten und/oder Integrationsanwendungen vor Ort in einer Multi-Cloud- oder Hybrid-Cloud-Umgebung gehostet haben.
Lernkurve
Sowohl AWS EKS als auch OpenShift erfordern Kubernetes-Kenntnisse, aber die OpenShift WebApp-Schnittstelle verringert die Lernkurve und macht es DevOps-Teams leichter, sich einzuarbeiten.
Für OpenShift zu bezahlen ist teurer als nur EKS zu verwenden, aber im Kontext der fraglichen App und DevOps-Architektur waren wir der Meinung, dass die Effizienz- und Vereinfachungsgewinne dies kompensieren. Wenn das interne Team des Kunden, dem es an Erfahrung mit der Einrichtung, Orchestrierung und Wartung von Kubernetes mangelt, mit dem reinen EKS-Ansatz auf mehr Probleme stoßen würde, würde dies mit Sicherheit alle oberflächlichen Einsparungen mehr als zunichte machen.
Wahl der Umgebung – Hard (Kubernetes cluster) vs. Soft (named space)
Hard (cluster)
- Adaption von IaC (Infrastructure as Code) für Prod und Pre-Prod
- Testen von infrastrukturellen Änderungen in der Entwicklungsumgebung ohne Auswirkungen auf die Produktion
Soft (named space)
- Geringerer Wartungsaufwand
- Jede IaC-Änderung wirkt isch auf alle Kubernetes-Tenants (d.h. namespaces) aus
AWS KMS für die Schlüsselverwaltung
Wir empfehlen eine harte Umgebung, die auf einem Kubernetes-Cluster basiert, da dies eine hochgradig automatisierte Wartung ermöglicht und getrennte Cluster mehr Flexibilität und eine robustere Infrastruktur bieten.
Unsere DevOps-Architektur verwendet AWS KMS für die Schlüsselverwaltung. KMS ermöglicht die einfache Erstellung und Verwaltung von kryptografischen Schlüsseln und deren Kontrolle über AWS-Services und innerhalb der Anwendung. Hardware-Sicherheitsmodule, die entweder bereits nach FIPS 140-2 validiert sind oder gerade validiert werden, bieten ein hohes Maß an Sicherheit und Widerstandsfähigkeit, und Protokolle über die Schlüsselnutzung sind ein Plus, insbesondere wenn eine Anwendung gesetzliche oder Compliance-Anforderungen erfüllen muss.
Die Vorzüge umfassen:
- Kontrollierter Zugang durch definierte Schlüsselnutzungsberechtigungen
- Zentralisierte Schlüsselverwaltung
- Die Verschlüsselungsverwaltung ermöglicht die gemeinsame Nutzung verschlüsselter Ressourcen zwischen Konten und Services, die durch Schlüsselnutzungsprotokolle verfolgt werden, die AWS-Services enthalten, die diese in Ihrem Namen verwenden.
Monitoring (Überwachung) und Protokollierung in einer DevOps-Architektur: Prometheus, Grafana, Elasticsearch, Kibana und Jaeger
Um den Anforderungen an die Überwachung und Protokollierung gerecht zu werden, verwenden wir eine Kombination aus Prometheus und Grafana für die Kubernetes-Überwachung, Jaeger für die verteilte Nachverfolgung, Kibana für die Protokollierung und Grafana für die breitere Anwendungsüberwachung. Alle Tools werden von OpenShift in den Management-Cluster übertragen.
Prometheus für Kubernetes monitoring
Das Open-Source-Tool Prometheus zur Überwachung von Containern und Microservices sammelt numerische Daten auf der Grundlage von Zeitreihen, indem es die Metrik-Endpunkte der überwachten Knoten aufruft. Prometheus sammelt die Metriken und versieht sie mit Zeitstempeln.
Prometheus ist ein kostenloses und quelloffenes Event-Monitoring-Tool für Container und Microservices. Prometheus sammelt numerische Daten auf der Grundlage von Zeitreihen. Der Prometheus-Server arbeitet nach dem Prinzip des Scraping. Er ruft den Metrik-Endpunkt der verschiedenen Knoten auf, die zur Überwachung konfiguriert wurden. Diese Metriken werden mit regelmäßigen Zeitstempeln gesammelt und lokal gespeichert. Der Endpunkt, der zum Verwerfen verwendet wurde, wird auf dem Knoten ausgesetzt.
Prometheus mit Grafana
Grafana, eine plattformübergreifende Datenvisualisierungsplattform, die die Verfügbarkeit der Datenquelle in Diagrammen oder Grafiken darstellt und einen Mehrwert über die Browser-Expression von Prometheus hinaus bietet. Grafana bietet auch eine sofort einsatzbereite Integration mit Prometheus. Grafana wird verwendet, um Metriken und Protokolle auf viele verschiedene Arten zu visualisieren und bietet eine hocheffiziente Möglichkeit, Protokolle zu durchsuchen oder live zu streamen.
Elasticsearch und Kibana für die Protokollierung in Kubernetes
Elasticsearch speichert Daten in Indizes und fungiert als verteilte, skalierbare Suchmaschine sowohl für die Volltextsuche als auch für die strukturierte Suche und für Anwendungen in der Analytik. Im Kontext eines Kubernetes-Clusters wird Elasticsearch zum Einlesen von Protokollen verwendet.
Die Rolle von Kibana besteht in der Anzeige der in Elasticsearch aufgenommenen Protokolle. Kibana ist Teil des ELK Elastic Stack und lässt sich am besten als „Benutzeroberfläche beschreiben, mit der Sie Ihre Elasticsearch-Daten visualisieren und im Elastic Stack navigieren können. Von der Verfolgung der Abfragelast bis hin zum Verständnis der Art und Weise, wie Anfragen durch Ihre Anwendungen fließen, ist alles möglich.“
Jaeger für die verteilte Rückverfolgung
Jaeger ist ein verteiltes Open-Source-Tracing-System, das Komponenten zum Speichern, Visualisieren und Filtern von Traces enthält. Es implementiert die OpenTracing-Spezifikation. Verteiltes Tracing erfasst Anfragen, um ein Bild der gesamten Kette von Aufrufen von Benutzeranfragen bis zu Interaktionen zwischen Microservices zu erstellen. Jaeger verfolgt auch die Dauer von Anfragen, den Lebenszyklus von Netzwerkaufrufen wie HTTP und RPC und hilft bei der Lokalisierung von Engpässen, die die Leistung beeinträchtigen.
In einer Kubernetes-Umgebung ermöglicht Jaeger das verteilte Tracing für gRPC-Dienste.
Entwicklungswerkzeuge in unserer DevOps-Architektur – AWS Container Registry (ECR), IaC Terraform, Helm, GitOps ArgoCD, AWS CodeCommit, AWS CodePipeline
Eine Aufschlüsselrung der Dev-Tools, die in unserer DevOps-Architektur verwendet werden:
AWS Elastic Container Registry – ECR
Das AWS-eigene ECR ist eine vollständig verwaltete Docker-Container-Registry, die Docker-Container-Images in einer skalierbaren und hochverfügbaren Architektur hostet. Seine Rolle in einer DevOps-Architektur besteht in der zuverlässigen Bereitstellung von Containern mit Kontrolle auf Ressourcenebene für einzelne Repositorys, die durch die Integration mit AWS Identity und IAM erreicht wird.
IaC Terraform und Helm
Das Infrastructure-as-Code (IaC)-Tool Terraform wird zur Verwaltung der AWS-Infrastruktur verwendet. Mit Terraform können wir den Code für die Infrastruktur schreiben und ihn in GIT verwalten. Wir können auch den Zustand der Infrastruktur verwalten und bei Bedarf zum vorherigen Zustand zurückkehren. Terraform findet heraus, wie der gewünschte Endzustand der Infrastruktur erreicht werden kann, der durch den Code festgelegt wurde. Es unterstützt auch unveränderliche Infrastrukturen.
Helm ist der Anwendungspaketmanager, der auf Kubernetes läuft, um die Struktur der Anwendung zu beschreiben und zu verwalten. Er vereinfacht die Verwaltung von Microservices durch die Bereitstellung von Helm-Diagrammen und einfachen Verwaltungsbefehlen.
Argo CD
Argo CD folgt der GitOps-Praxis, Git-Repositories als einzige Quelle der Wahrheit für den Zustand der Anwendung zu verwenden. Argo CD stellt sicher, dass Anwendungsdefinitionen, -konfigurationen und -umgebungen deklarativ und versionskontrolliert sind und das Lebenszyklusmanagement automatisiert, überprüfbar und einfach zu verstehen ist.
Innerhalb eines Kubernetes-Clusters hat Argo CD einen Controller für die kontinuierliche Überwachung laufender Anwendungen implementiert, der den Produktionsstatus mit dem gewünschten Zielstatus vergleicht, wie er durch das Git-Repository definiert ist. Wenn der Produktionsstatus nicht mit der einzigen Wahrheitsquelle des Git-Repos übereinstimmt, meldet und visualisiert Argo CD Diskrepanzen und ermöglicht ein manuelles oder automatisches Rollback auf den Zielstatus.
Änderungen an dem in Git gespeicherten Zielstatus können auch automatisch in die Produktion übertragen werden.
AWS CodeCommit
CodeCommit ist ein Schlüsselelement für eine CI/CD-Pipeline in einer AWS-Umgebung. Als vollständig verwalteter Versionskontrolldienst hostet CodeCommit sicher Git-Repos, sodass das DevOps-Team kein eigenes Versionskontrollsystem betreiben muss, was bei der Skalierung der Infrastruktur einen Engpass darstellen kann. CodeCommit speichert alles, vom Quellcode bis hin zu Binärdateien, sicher und ist mit bestehenden Git-Tools kompatibel.
Sicherheits- und Codequlitätsanalyse mit SonarQube
Codequalität und Sicherheit in unserer DevOps-Architektur basieren auf SonarQube, einem Tool mit der Device „Continuous Inspection must become mainstream as Continuous Integration” („Kontinuierliche Inspektion muss genauso mainstream werden wie kontinuierliche Integration“).
SonarQube ist ein Open-Source-Tool, das eine automatisierte Codeüberprüfung ermöglicht und durch statische Anwendungssicherheitstests (SAST) Fehler, Bugs, Schwachstellen und unsauber implementierte Segmente im Quellcode von 27 verschiedenen Programmiersprachen aufdeckt.
Das Tool kann auch verwendet werden, um die Einhaltung organisatorischer Coding-Richtlinien sowie allgemeine Qualitätsprobleme zu überprüfen. Sein Beitrag zur Sicherheit besteht darin, potenzielle Probleme wie unsichere Coding-Ansätze, veraltete kryptografische Bibliotheken, Konsistenz von Debug-Ausgaben usw. aufzuzeigen.
All dies ist der entscheidende Faktor für die Integration von Sicherheit in DevOps, bzw. DevSecOps, wie es manchmal genannt wird. Wir bei K&C sind der Meinung, dass alle DevOps standardmäßig DevSecOps sein sollten, was die Notwendigkeit eines eigenen Begriffs überflüssig macht.
Bei einem traditionellen Wasserfall-Ansatz für die Softwareentwicklung wird die Sicherheit erst in der letzten Phase der Entwicklung in die Software integriert. Das Problem bei der nachträglichen Sicherheitsintegration besteht darin, dass in diesem Stadium die Gefahr besteht, dass grundlegende Fragen der Softwarearchitektur nicht den strengen Sicherheitsstandards entsprechen. Zu diesem Zeitpunkt kann es oft zu spät sein, um Änderungen vorzunehmen, die ein robustes Sicherheitsniveau bieten würden, ohne einen Großteil der Entwicklungsarbeit neu zu machen.
Wenn die Sicherheit ein integraler Bestandteil der CI/CD-DevOps-Pipeline ist, wird diese Schwäche der nachträglichen Integration beseitigt. SonarQube sorgt dafür, dass dies der Fall ist und dass neuer Code kontinuierlich auf allgemeine Qualität und im Kontext von Sicherheitsüberlegungen geprüft wird.
Rancher als unsere Verwaltungskonsole
In unserer DevOps-Architektur hat Rancher folgende Aufgaben:
- Betrieb und Verwaltung von Kubernetes-Clustern
- Workload Management
- Unternehmensunterstützung
Rancher, mit dem K8s-Cluster auf jeder Infrastruktur vom Rechenzentrum bis zum Edge bereitgestellt und verwaltet werden können, ist eines unserer bevorzugten und integrierten DevOps-Tools. Betriebliche und sicherheitstechnische Herausforderungen werden von Rancher durch Cluster-Verwaltung und Provisionierung gemeistert. Rancher bietet außerdem eine Reihe integrierter Tools, die DevOps-Teams bei der Ausführung von containerisierten Arbeitslasten unterstützen.
Rancher lässt sich auch in ein GitHub-Repository integrieren, um die Ausfürhung der CI-Pipeline zu automatisieren. Als Teil der CI/CD-Pipeline kann Rancher:
- Builds (Baut) die Anwendung vom Code zum Image (Bild).
- Validiert Builds
- Deploys build images auf dem Cluster
- Führt Unit-Tests aus.
- Führt Regressionstests durch.
Identity- and Access Management in der Cloud – IAM mit AWS IAM
Identity- and Access Management (IAM) ist ein weiterer wichtiger Pfeiler der Sicherheit. Da wir eine AWS-Umgebung verwenden, ist das native AWS IAM hier die offensichtliche Lösung. AWS IAM steuert einfach, wer sich in der Cloud-Umgebun anmelden kann und legt fest, welche Berechtigungen zur Nutzung von AWS-Ressourcen jeder angemeldete Benutzer hat.
In einem DevOps-Ansatz sollten die IAM-Rollen es dem Team ermöglichen, für die Ressourcennutzung verantwortlich zu sein, wobei die Berechtigungen so festgelegt werden, dass das Team flexibel auf Vorfälle reagieren kann, was die Reaktionszeiten verkürzt. Eine strenge Prüfung der IAM-Rollen durch eine externe Drittpartei wird ebenfalls empholen.
DevOps-Teams & Beratung
Wenn Sie von einer erfahrenen und sachkundigen DevOps-Beratung für Ihre internen Projekte profitieren könnten oder ein flexibles, skalierbares DevOps-Team für die Entwicklung oder Wartung Ihrer Anwendungen oder Kubernetes-Cluster benötigen, würde K&C Ihnen gerne helfen. Schreiben Sie uns gerne eine Nachricht!
