EC2: Amazon Machine Images nutzen, AMI selbst erstellen


    Tags: ,

    Amazon Machine Images (AMIs)Im Gegensatz zur Server-Virtu­alisierung mit ESXi oder Hyper-V kann man in AWS keinen nackten virtuellen Server ohne Betriebs­system erzeugen. Viel­mehr beruht eine VM immer auf einem Amazon Machine Image (AMI) mit einem darin ent­haltenen Linux oder Windows. Ein AMI kann man auch selbst erstellen.

    AMIs stammen entweder aus dem Angebot von AWS (Quick Start), aus dem eigenen Fundus (My AMIs), der Community (Community AMIs) oder dem kommer­ziellen AMI-Marktplatz (AWS Marketplace).

    AMIs instanziieren

    Aus dem AMI wird, sobald man daraus eine Instanz bootet ("Instanziieren"), ein (oder mehrere) virtuelle(r) Server, wobei man den gewünschten physi­kalischen Instanztyp angibt (also die Server-Hardware auf Basis der Hypervisor-Knoten im AWS-DC).

    Wurde eine neue Instanz aus einem AMI erzeugt, dann muss sie im Rahmen ihren Lebenszyklus gepflegt werden, was etwa das Überwachen operativer Daten oder das Einspielen von Software-Patches meint.

    Mittels cloudinit (Linux) oder ec2 config service (Windows) kann man im Verlauf der Instanziierung Patches oder Pakete installieren, und sofern gewünscht, ein Key Pair generieren, um sich nach dem Deployment sicher per SSH oder RDP auf den virtuellen Server verbinden zu können.

    Herunterladen des Key Pairs, das für den Remote-Zugriff auf die Instanz benötigt wird.

    Zudem wird erst durch das Installieren zusätzlicher Software-Pakete aus einem mehr oder weniger nackten Windows- oder Linux-Server eine komplexere (Web)-Anwendung. Abhängig davon, welche Pakete per cloudinit installiert wurden oder was bereits im AMI steckt (Marketplace AMIs), kann man auch von einen Anwendungs-Server reden.

    Metadaten von AMIs

    Ein AMI liegt etwa bei Maschinen, die auf dem persistenten Storage der Elastic Block Volumes (EBS) basieren, als Volume-Snapshot vor. AWS speichert diesen in S3, zusammen mit der AMI-Beschreibung, welche im Wesentlichen das Volume-Mapping im Gast­system und Start­berech­tigungen enthält.

    Die Beschreibung eines AMI gibt unter anderem Auskunft über das enthaltene Betriebssystem und den Typ des Root-Device.

    Die Beschreibung zeigt außerdem an, welches Betriebs­system jeweils die Basis bildet und liefert einige Informationen zu den wichtigsten vorinstallierten Paketen oder verfügbaren Paket­quellen, von welchem Typ das Root-Device ist (meist EBS), für welchen Hypervisor es gedacht ist (meist HVM) sowie die AMI-ID selbst.

    Zwei Varianten von Amazon Linux

    Derzeit unterstützt AWS zwei Versionen von Amazon Linux, Amazon Linux und das relativ neue Amazon Linux 2. Die dafür vorgesehenen AMIs enthalten Pakete und die erforderliche Konfigu­ration, um eine nahtlose Integration der Instanz mit Amazon Web Services zu ermöglichen.

    Dazu sind im Amazon Linux AMI die wichtigsten AWS-API-Tools sowie cloudinit vorinstalliert. AWS API-Tools machen etwa das Scripting wichtiger Bereitstellungs­aufgaben aus einer Amazon EC2-Instance heraus möglich.

    Dagegen übergibt cloudinit zum Startzeitpunkt Aktionen für die Instance-Konfiguration. Dies erlaubt unter anderem auch eine Fernkonfiguration von Amazon EC2-Instances, indem zum Beispiel der SSM-Agent für den neuen AWS Systems Manager installiert wird.

    Das Amazon Linux AMI ist in allen AWS-Regionen verfügbar. Folgende von AWS bereitgestellte Übersicht zeigt, welche Varianten des Linux AMI Amazon für die einzelnen EC2-Instance-Typen empfiehlt.

    Neben seinem eigenen Linux bietet AWS alle wichtigen Distributionen des Betriebssystems.

    Im Dezember letzten Jahres hat AWS Amazon Linux 2 eingeführt, nach Einschätzung von AWS die nächste Generation seines Linux-Server-Betriebssystems. Es ist als Amazon Machine Image (AMI) für Amazon EC2, aber auch als Docker-Container-Image und sogar als virtuelle Maschine für die Verwendung auf kernelbasierter virtueller Maschine (KVM), Oracle VM VirtualBox, Microsoft Hyper-V und VMware ESXi verfügbar.

    Amazon Linux 2 unterstützt auch die neuesten Amazon EC2-Funktionen, bietet ebenfalls Long Term Support (LTS), basiert auf einem Linux-Kernel 4.9 und unterstützt erstmals systemd.

    Eigene AMIs erstellen

    Ein AMI wird über EC2-Management-Konsole erstellt, und zwar bei markierter Instanz im Menü Actions => Image => Create Image. Das fertige Image ist nach einiger Zeit im EC2-Dashboard unter Images => AMIs zu sehen.

    Über das Menü Actions kann man AMI zum Beispiel kopieren oder eine Instanz davon starten.

    Dort kann man im Menü Actions darüber hinaus AMIs kopieren, neue Instanzen aus ihnen erzeugen (Launch), die Zugriffs­berechtigungen auf das AMI ändern (eigene AMIs sind immer per Default privat) oder AMIs wieder entfernen.

    Der Vorgang des Hinzufügens/Entfernens von AMIs in der betreffenden Region heißt offiziell Registrieren bzw. Deregistrieren.

    AMI aus laufender Instanz ableiten

    Zwar kann man ein Image jederzeit aus einer laufenden Instanz erzeugen, genau genommen wird es aber aus eines Snapshot des Boot-Volumes generiert. In der Praxis wird man die Instanz also erst stoppen, dann zur Volume-Ansicht wechseln, dort einen Snapshot anlegen und aus diesem in der Snapshot-Ansicht das dann das eigentliche AMI erstellen.

    Genau das passiert auch im Hintergrund, wenn man ein AMI aus einer Instanz erzeugt, um einen konsistenten Zustand zu garantieren.

    Amazon Machine Image aus einer laufenden Instanz ableiten

    Ist man sich hingegen sicher, dass sich die Instanz in einem für die AMI-Erstellung geeigneten Zustand befindet, kann man EC2 auch anweisen, die Instance nicht herunter­zufahren und neu zu starten. Bei einigen Dateisystemen wie XFS lassen sich Aktivitäten vorübergehend einfrieren (fsfreeze), damit das Abbild ohne Neustart der Instance auf sichere Weise erstellt werden kann.

    Im Detail unterscheiden sich die Verfahren zum Erzeugen und Verwalten von Abbildern sowie zum Wieder­herstellen von Instanzen bestehender Abbilder, je nachdem ob das Boot-Volume via EBS oder Instance-Store angeschlossen ist.

    Keine Kommentare