Configuration Management mit AWS, Teil 1 AWS OpsWorks Stacks und OpsWorks for Chef Automate

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Das Konfigurationsmanagement ist für die Automatisierung komplexer Infrastrukturen besonders wichtig. In der AWS Cloud ist mit OpsWorks, das auf Chef als Automationsplattform basiert und Server-Konfigurationen wie Code behandelt, ein entsprechender Managed Service erhältlich.

Anbieter zum Thema

AWS OpsWorks übernimmt auf Basis von Chef das Konfigurationsmanagement in der AWS-Cloud.
AWS OpsWorks übernimmt auf Basis von Chef das Konfigurationsmanagement in der AWS-Cloud.
(Bild: Amazon Web Services)

In der Cloud kommen gerne hunderte oder tausende Server-Instanzen mit verschiedensten Software-Konfigurationen zusammen. Wer diese bereitstellen, verwalten und deren Lebenszyklen überwachen muss, um ggf. auch Instanzen, die nicht richtlinienkonform ausgerollt wurden, identifizieren und beenden zu können, braucht eine Strategie für die einheitliche Konfiguration sowie Tools für das Konfigurationsmanagement.

Letzteres lässt sich in der AWS-Cloud wahlweise mit Chef, Puppet oder Ansible realisieren. Da Amazon Web Services allerdings mit OpsWorks einen verwalteten, auf Chef basierenden Dienst zur Konfigurationsverwaltungs bereitstellt, gestaltet sich das Config-Management mit diesem deutlich komfortabler.

Vorteile von Konfigurationsmanagement

Basis des Deployments von virtuellen Servern und deren Software-Konfiguration sind Vorlagen, im Falle von AWS Amazon Machine Images (AMIs) genannt, aus denen virtuelle Server deployt werden können. Da auch AWS hierbei den Bootstrapping-Prozess (z. B. via CloudInit) beherrscht, müssen Unternehmen selbst experimentell die für sie passende AMI-Konfigurationsstrategie bestimmen.

Hierbei sind Einflussfaktoren wie Build Time und Boot-Time gegeneinander abzuwägen, wobei zwei Extreme vorstellbar sind: ein AMI, das lediglich die Betriebssystem-Konfiguration enthält, ist zwar schnell gebaut. Es braucht aber recht lange zum Booten, weil im Rahmen des Bootstrappings jeweils alle benötigten Anwendungen sowie die aktuellen Patches für OS und Anwendungen bereitgestellt werden müssen, wenn eine neue Instanz hochgefahren wird. Das Verpacken einer bestimmten Anzahl dieser Voraussetzungen in ein benutzerdefiniertes AMI kann daher die Boot-Zeiten verkürzen.

Mit dem Konfigurieren von Instanzen ist es aber nicht getan. In der Praxis muss sich der Admin auch um VPCs, Sicherheitsgruppen, Netzwerk-ACLs, Router, Load Balancer usw. kümmern und dabei nach einem möglichst einheitlichen und vor allem reproduzierbaren Deployment streben, insbesondere aus Sicherheits- und Compliance-Gründen.

Konfigurationsserver

Daher nutzen gerade größere Unternehmen für solche Vorgänge einen Konfigurationsserver, der viele allgemeine Verwaltungsaufgaben vereinfacht. Man stelle sich z. B. folgendes Szenario vor: ein Admin im Unternehmen hat Zugriff auf mehrere Amazon EC2-Instanzen und verfügt über den privaten Schlüssel, der es ihm ermöglicht, sich mit seiner eindeutigen Benutzer-ID anzumelden und Verwaltungsaufgaben für diese Instanzen auszuführen. Doch was passiert, wenn er das Unternehmen verlässt?

Ohne einen Konfigurationsserver kann sich die manuelle Deaktivierung seines Zugriffs auf diese Instanzen zum Albtraum auswachsen. Mithilfe eines Konfigurationsservers kann ein Systemadministrator den Status eines solchen Mitarbeiters im System einfach ändern und diese Änderung mit einigen simplen Befehlen auf alle betroffenen Instanzen übertragen.

Einer der Vorteile eines Konfigurations-Servers wie Chef, Puppet oder Ansible ist, dass die Konfiguration „idempotent“ ist. Ressourcen, die von einem Konfigurationsserver erstellt oder konfiguriert werden, werden immer nur einmalig konfiguriert oder erstellt. Wenn die Konfiguration einer Instanz manuell geändert wird, erkennt der Konfigurationsserver diese und rollt sie zurück.

Was ist AWS OpsWorks?

Werfen wir dazu einen Blick auf AWS OpsWorks. Bei OpsWorks handelt es sich quasi um eine verwaltete Version von Chef. Mit OpsWorks können AWS-Nutzer sowohl die Bereitstellung und Überwachung von Servern, also auch deren Konfiguration (inklusive der Softwarepflege) über ihre gesamte Amazon Elastic Compute Cloud-Umgebung automatisieren.

Konkret stellt Amazon Web Services OpsWorks sogar zwei voneinander zu unterscheidende Angebote zur Verfügung:

AWS OpsWorks for Chef Automate

AWS OpsWorks for Chef Automate stellt einen vollständig integrierten Chef-Server bereit. Erweitert wurde dieser um eine Reihe von Automatisierungs-Tools, welche dem Admin das Automatisieren des Workflows für Continuous Delivery einschließlich automatisiertem Überprüfen der Compliance und Sicherheit erlauben.

Die OpsWorks-GUI bietet zudem eine komfortable Möglichkeit, sämtliche Knoten und deren Status einzusehen. Der Chef-Server erlaubt eine nahezu vollständige Stack-Automatisierung, indem er operative Aufgaben wie das Konfigurieren von Software und Betriebssystem, das Aufsetzen von Datenbanken oder das Installieren von Software-Paketen umsetzt.

OpsWorks speichert dazu sämtliche Konfigurations-Aufgaben an zentraler Stelle und stellt sie jedem Knoten zur Verfügung, unabhängig von der Größe der Umgebung. Damit adressiert OpsWorks als Dienst vor allem erfahrene Chef-Nutzer, zumal OpsWorks für Chef Automate vollständig mit den Tools und Rezepten der Chef-Community kompatibel ist und neu Knoten automatisch beim Chef-Server registriert.

AWS OpsWorks Stacks

Auch der Dienst AWS OpsWorks Stacks erlaubt das Verwalten von „Anwendungen“ oder „Servern“ auf AWS und/oder on premises. Der Administrator kann mit AWS OpsWorks Stacks seine mehrstufige Anwendung sehr komfortabel als „Stack“ mit verschiedenen „Ebenen“ wie Load Balancing, Anwendungsserver und Datenbank „beschreiben“.

Jeder Stack enthält dabei eine Gruppe von EC2-Instances sowie als „Layer“ bezeichnete Instance-Pattern, die zum Starten und Verwalten dieser Instanzen verwendet werden, etwa ein PHP-Server und die zugehörige MariaDB-Datenbank, welche von der Applikation benötigt werden. Der Admin definiert und kontrolliert also seine Anwendungen, Berechtigungen und Ressourcen immer im Kontext des Stacks.

Hierfür kann er in jedem Layer nach Belieben EC2-Instanzen konfigurieren oder andere Ressourcen wie Amazon-RDS-Datenbanken einbinden. Dabei lassen sich auch Aufgaben wie das Installieren von Softwarepaketen, Programmiersprachen oder Frameworks oder das Konfigurieren von Software automatisieren. OpsWorks Stack sorgt dann automatisch dafür, dass etwa Server auf der Grundlage vordefinierter „Pläne“ oder als Reaktion auf auftretende Ereignisse skalieren.

Chef-solo

Im Gegensatz zu „AWS OpsWorks for Chef Automate“ werden Chef-Rezepte bei AWS OpsWorks Stacks stets per „chef-solo“-Kommando ausgeführt. Chef-solo führt den Chef-Client (chef-client) auf der jeweiligen Instanz derart aus, dass kein Chef-Server erforderlich ist, was dem local mode von Chef entspricht. Dieser lokale Modus unterstützt im Gegensatz zu AWS OpsWorks for Chef Automate keine zentralisierte Verteilung von Cookbooks, bietet keine zentrale API und auch keine Authentifizierung und Autorisierung.

Unterstütze Architekturen

AWS OpsWorks Stacks kennt eine große Anzahl Architekturen – von einfachen Web-Applikationen bis hin zu komplexen kundenspezifischen Anwendungen. Da AWS OpsWorks Stacks sowohl Chef-Rezepte als auch Bash-/PowerShell-Skripte unterstützt, sind Administratoren sogar in der Lage, von der Community entwickelte Konfigurationen zu verwenden.

Der Clou dabei ist, dass sich mit AWS OpsWorks Stacks Konfigurationen für die gesamte Umgebung in einem Format definieren lassen, die man wie einen Anwendungsquellcode verwalten und z. B. auch unter eine Versionskontrolle z. B. via GitLab stellen kann. AWS OpsWorks Stacks kann zahlreiche betriebsbezogene Aufgaben automatisieren.

Hierzu zählen die Konfiguration von Software, das Installieren von Paketen, das Einrichten von Datenbanken und das Bereitstellen von Code auf jedem Linux- oder Windows-Server – und zwar nicht nur auf existierenden EC2-Instancen, sondern auch auf Servern im eigenen Rechenzentrum, wobei die am weitesten verbreiteten Anwendungsfälle sicherlich das Hosting mehrstufiger Webanwendungen oder die Unterstützung für Continuous Integration ist.

Schichtenmodell

Konkret erlaubt AWS OpsWorks Stacks eine Modellierung und Visualisierung komplexer Anwendungen mit Hilfe von Ebenen (Layern), innerhalb derer der Admin bestimmt, wie eine bestimmte Gruppe gemeinsam verwalteter Ressourcen zu konfigurieren ist. Darüber hinaus können Admins für jeden Layer Software-Konfigurationen einschließlich Installationsskripten und Initialisierungsaufgaben definieren.

Beispiel für eine mehrstufige Web-App.
Beispiel für eine mehrstufige Web-App.
(Bild: Drilling / AWS)

AWS OpsWorks Stacks unterstützt jede Software, die eine skriptgesteuerte Installation erlaubt. Eine einfache mehrstufige Web-Anwendung mit Load Balancer, Applikationsservern und Datenbank, wie sie in der vorangestellten Abbildung zu sehen ist, würde sich im Rahmen des OpsWorks-Workflows wie folgt darstellen.

Umsetzung der Web App in AWS OpsWorks.
Umsetzung der Web App in AWS OpsWorks.
(Bild: Drilling / AWS)

(ID:45009486)