EC2-Instanzen lassen sich innerhalb der Amazon Web Services per Command Line Interface anlegen, bearbeiten und verwalten. Wie das Sub-Command „EC2“ mit AWS-CLI über einen Kommando-Host realisiert wird, sehen wir uns in diesem Beitrag an.
Im ersten Teil dieses Workshops haben wir die AWS-CLI auf einem lokalen Windows-Arbeitsplatz im eigenen Rechenzentrum installiert. In freier Wildbahn wird man die AWS-CLI häufig aus einer EC2-Instanz heraus verwenden, um andere AWS-Dienste zu steuern.
Ein populäres Beispiel ist der Betrieb einer Art Kommando-Hosts in einem Public-Subnet. Dieser basiert auf einem Amazon-Linux-AMI, bei dem die CLI bereits vorinstalliert ist und soll ausschließlich dazu dienen, AWS-Ressourcen im aktuellen VPC zu verwalten oder neue Services zu instanziieren. Dieser Kommando-Host wird in einem öffentlichen Subnetz platziert und ist damit selbst aus dem eigenen Rechenzentrum heraus per SSH steuerbar. Das Aufsetzen des Kommando-Hosts erledigen wir für das folgende Beispiel mithilfe der AWS Management Console und platzieren diesem in einem eigens dazu angelegten öffentlichen Subnetz. Die notwenigen Workflows im EC2- und VPC-Dashboard sollten allerdings geläufig sein.
Da unser Kommando-Host letztendlich als Steuerzentrale zum Provisionieren weiterer EC2-Instanzen dienen soll, muss die Instanz über den erforderlichen Berechtigungskontext verfügen. Hierfür erstellen wir zunächst einfach eine neue IAM-Rolle „Kommando-Host“ für den EC2-Service, der wir die verwaltete Policy „EC2 Full Access“ anhängen. Anschließend erstellt man im VPC-Dashboard ein passendes VPC mit einem öffentlichen Subnetz. Das Erstellen der benötigten Internet-Gateways (IGW) der Routing-Tabelle und Subnetze kann manuell im VPC-Dashboard oder der Einfachheit halber mit Hilfe des VPC-Wizards erfolgen, wie folgende Abbildung zeigt.
Sind die Voraussetzungen geschaffen, können wir die benötigte EC2-Instanz für den Kommando-Host erstellen. Der EC2-Launch-Wizard verwendet das Amazon-Linux-AMI als Vorlage, erhält die oben erstelle IAM-Rolle, das oben erstelle öffentliche Subnetz als Provisionierungsziel und ein einfaches User-Daten-Skript zum Aktualisieren der wichtigsten Pakete:
#!/bin/bash
yum update -y
Das Installieren der AWS-CLI per Instanz-User-Daten erübrigt sich, da diese im AMI für Amazon Linux bereits installiert ist. Bei der Instanz-Größe können wir es bei „T2-Micro“ belassen und auch beim Root-Volume übernehmen wir die Default-Einstellungen, um im Free-Tier-Kontingent zu bleiben. Lediglich bei der Security Group erstellen wir „on the fly“ im EC2-Launch-Wizard eine Neue für „SSH-Access“ (Port 22 eingehend von „überall“, d. h. 0.0.0.0/0) und kreieren abschließend ein neues RSA-Schlüsselpaar (nicht vergessen, den privaten Schlüssel herunterzuladen), um uns per SSH auf die Instanz verbinden zu können.
Wurde die Instanz erstellt, können wir uns per SSH und dem eben erstellten asymmetrischen Schlüsselpaar auf die Instanz verbinden und dort initial „aws configure“ durchlaufen lassen, wie in Teil 1 dieser Workshop-Reihe beschrieben. Die symmetrischen AES-Schlüssel „Access Key + Secret“ muss man allerdings zuvor für den verwendeten IAM-User erstellt und aktiviert haben.
Damit sind alle Voraussetzungen erfüllt, um vom Kommando-Host aus mit der AWS CLI arbeiten und z. B. weitere Instanzen im öffentlichen Subnetz zu erzeugen. Wir verwenden für diesen Teil des Workshops den Sub-Command „EC2“, befassen uns also vorerst nur mit der AWS-CLI für EC2.
