AWS EC2: Instanzen ersetzen, AMIs aktualisieren, Konfigurations-Management mit OpsWorks

Das nach­trägliche Verbinden auf der Instanz für operative Aufgaben ist im Cloud-Computing eher verpönt, da es Devops-Szenarien erschwert und all­gemein auch als Sicher­heits­problem gilt. Daher hat man unter AWS mehrere Möglich­keiten, 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 Hoch­verfüg­barkeit, anders als bei vielen höher­wertigen 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 ausge­wä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 Netzwerk­einstellungen 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 Aktuali­sierung. Schließlich liegt die Bereit­stellungszeit von virtuellen Maschinen im Cloud-Computing im Bereich weniger Sekunden. Voraus­setzung dazu ist eine geeignete AMI-Strategie.

Eine könnte darin bestehen, immer nur ein Basis-Image von AWS zu verwenden und sämtliche unternehmens­relevanten Pakete, Tools und Services via cloudinit zu installieren. Dazu entwickelt und pflegt man seine eigenen User-Daten-Skripte in einem Versions­kontroll­system.

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 schwer­wiegende Sicherheits­lücken bekannt werden oder wenn die Instanz nicht mehr verfügbar ist).

Eine andere AMI-Strategie könnte darin bestehen, sämtliche unter­nehmens­relevanten Patches und Anwendungen nach dem anfänglichen Provisionieren der Instanz manuell zu installieren und dann daraus ein unternehmens­spezifisches AMI zu generieren. Dieses dient danach als Grundlage für das Bereit­stellen 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 regel­mäßigen Abständen gepflegt werden, wozu Unter­nehmen unter­schiedliche 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 Konfi­gurations­management.

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 Initiali­sierung 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 umfang­reiche User-Daten verarbeitet werden müssen.

Konfigurationsmanagement-Systeme

Eine weitere Möglichkeit besteht darin, Lösungen für das Konfigurations­management 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 Anwendungs­modellierung und -verwaltung nutzt.

AWS rechnet Automate Server oder einen Puppet Enterprise Server nach so genannten Konten­stunden 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 bereit­gestellten 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 Automa­tisierungs­funktionen.

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 Programmier­sprache Befehle auf EC2-Instanzen absetzen.

So ist beispiels­weise der komplette AWS Systems Manager im Kern aus dem Tool ec2 run command hervor­gegangen. Damit können Nutzer die Konsole zum Konfigurieren von Instanzen ver­wenden, ohne sich bei jeder von ihr anmelden zu müssen.