Tags: AWS, Amazon EC2, Configuration-Management, Hochverfügbarkeit
Unter Operations Management in der Cloud versteht man alle Handgriffe, die aus einem nackten Linux- oder Windows-Server eine Applikation machen. Zur Pflege des Systems gehören auch das Aktualisieren des Betriebssystems, das Einspielen von Patches oder das Überwachen operativer Betriebsdaten.
Eine gängige Anforderung besteht darin, einen virtuellen Server zu vergrößern, also vertikal zu skalieren. Dies wäre eine Aktion, die man sozusagen von außen mit AWS-Mitteln erledigt würde. Das Patchen des Betriebssystems oder der Anwendungen kann hingegen prinzipiell nur von innerhalb einer Instanz erfolgen. Dazu wird man sich in der Praxis meist über SSH mit dem Server verbinden.
Das nachträgliche Verbinden auf der Instanz für operative Aufgaben ist im Cloud-Computing eher verpönt, da es Devops-Szenarien erschwert und allgemein auch als Sicherheitsproblem gilt. Daher hat man unter AWS mehrere Möglichkeiten, das Pflegen von Instanzen auch anders zu bewältigen. Hier einige Anregungen.
Vollständiges Ersetzen einer defekten Instanz
AWS bietet bei EC2 von Haus aus keine eingebaute Hochverfügbarkeit, anders als bei vielen höherwertigen AWS-Services. Sofern man also seine Web-Anwendung nicht selbst so auslegt, dass sie zum Beispiel in mindestens zwei Availability-Zonen läuft, hilft hier EC2 Auto Recovery.
Dieses Feature lässt sich nur bei ausgewählten Instanztypen (gilt nicht für T2) konfigurieren. Hierbei wird die betreffende Instanz, ausgelöst durch einen Cloudwatch-Alarm, von AWS automatisch durch eine gleichwertige ersetzt, also mit gleichen User-Daten, gleichen Netzwerkeinstellungen usw.
Hierzu klickt man in der EC2-Instanzliste bei markierter Instanz auf den Tab Monitoring und dann auf Create Alarm. Nun wählt man bei Whenever die zu diesem Feature passende Metrik aus, in diesem Fall Status Check Failed (Instance), und aktiviert die Checkbox Take the action. Hier kreuzt man rechts Recover this instance an.
AMI-Strategien
Man kann Instanzen auch geplant regelmäßig durch neue ersetzen, theoretisch sogar bei jeder anstehenden Aktualisierung. Schließlich liegt die Bereitstellungszeit von virtuellen Maschinen im Cloud-Computing im Bereich weniger Sekunden. Voraussetzung dazu ist eine geeignete AMI-Strategie.
Eine könnte darin bestehen, immer nur ein Basis-Image von AWS zu verwenden und sämtliche unternehmensrelevanten Pakete, Tools und Services via cloudinit zu installieren. Dazu entwickelt und pflegt man seine eigenen User-Daten-Skripte in einem Versionskontrollsystem.
Speichert man die von der Applikation generierten Daten zudem, wie von AWS empfohlen, außerhalb der Instanz (etwa auf S3), dann kann man jederzeit eine komplett neue Instanz aus dem Basis-AMI provisionieren. Dies kann in fest vorgegebene Zyklen erfolgen oder nach Bedarf (etwa wenn schwerwiegende Sicherheitslücken bekannt werden oder wenn die Instanz nicht mehr verfügbar ist).
Eine andere AMI-Strategie könnte darin bestehen, sämtliche unternehmensrelevanten Patches und Anwendungen nach dem anfänglichen Provisionieren der Instanz manuell zu installieren und dann daraus ein unternehmensspezifisches AMI zu generieren. Dieses dient danach als Grundlage für das Bereitstellen neuer Instanzen.
Folgende Abbildung demonstriert den kompletten Workflow bzw. Lifecycle vom Basis-AMI über die Instanz, ein angepasstes AMI bis zur neuen Instanz.
Allerdings muss auch dieses AMI in regelmäßigen Abständen gepflegt werden, wozu Unternehmen unterschiedliche Strategien entwickelt haben. Ein Beispiel dafür ist das Animator-Tool von Netflix, einem der bekanntesten AWS-Kunden. Folgende Abbildung zeigt die beiden Pole einer möglichen Strategie für AMI-basiertes Konfigurationsmanagement.
Ein so genanntes Full AMI benötigt eine längere Build-Time, bootet aber dafür sehr schnell, da keinerlei Patches oder Applikationen im Verlauf der Initialisierung installiert werden müssen. Ein OS-Only-AMI benötigt überhaupt keine Build-Time, sofern man ein Basis-AMI von AWS verwendet, braucht aber im Zweifel sehr lange für den Boot-Prozess, weil umfangreiche User-Daten verarbeitet werden müssen.
Konfigurationsmanagement-Systeme
Eine weitere Möglichkeit besteht darin, Lösungen für das Konfigurationsmanagement einzusetzen. Dazu installiert man in den Instanzen einen Agenten für Systeme wie Puppet oder Chef. Danach verteilt man Aktualisierungen und Patches ausschließlich über einen Konfigurations-Server.
Eine solche Strategie lässt sich gut auch auf physische Server und virtuelle Maschinen anwenden, die on-premises betrieben werden. Chef und Puppet kann man alternativ auch als verwalteten Dienst auf AWS buchen.
Dieser Service heißt AWS OpsWorks und stellt einen verwalteten Chef Automate Server sowie einen Puppet Enterprise Server zur Verfügung. Wahlweise gibt es mit AWS OpsWorks Stacks noch eine dritte Variante, mit der man quasi Chef im Local Mode zur einfachen Anwendungsmodellierung und -verwaltung nutzt.
AWS rechnet Automate Server oder einen Puppet Enterprise Server nach so genannten Kontenstunden für die Benutzung des Dienstes ab, und zwar abhängig von der gewünschten Anzahl der zu konfigurierender Knoten. Dagegen zahlt man bei OpsWorks Stack nicht für die Benutzung des Dienstes an sich, dafür aber ganz normal für alle damit automatisch bereitgestellten AWS-Ressourcen.
AWS Systems Manager
Als weitere Möglichkeit (neben programmatischen Methoden), das Operations Management von außen, aber mit AWS-eigenen Mitteln zu erledigen, ist der Ende letzten Jahres eingeführte AWS Systems Manager.
Er ist die AWS-spezifische Variante eines Services für das Aggregieren, Überwachen und Visualisieren operativer Daten von EC2-Instanzen. Außerdem eignet er sich für das Verteilen von Patches oder das Anstoßen von Automatisierungsfunktionen.
CLI und APIs
Schließlich muss man sich nicht unbedingt über ein Public Key-Pair explizit auf einer Instanz verbinden, um nachträglich operative Aufgaben durchzuführen. Alternativ kann man sich mit Hilfe eines so genannten AccessKeys gegen das API authentifizieren und entweder via CLI oder das SDK einer Programmiersprache Befehle auf EC2-Instanzen absetzen.
So ist beispielsweise der komplette AWS Systems Manager im Kern aus dem Tool ec2 run command hervorgegangen. Damit können Nutzer die Konsole zum Konfigurieren von Instanzen verwenden, ohne sich bei jeder von ihr anmelden zu müssen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Ähnliche Beiträge
- AWS Systems Manager: EC2-Instanzen patchen, Wartungsaufgaben automatisieren
- winget erhält PowerShell-Modul und Configuration Management
- VMware vCenter Converter 6.4 Beta: Support für vSphere 8, Microsoft VBS
- VMware vSphere 8 Update 1: Configuration Profiles nun GA, erweiterter TPM -Support, Okta als Identity Provider
- UUP-Updates auf WSUS und Configuration Manager ab März verfügbar
Weitere Links