Cloud-Ressourcen stundenweise mieten
Speichermedium auswählen
von Tam Hanna - 17.12.2018
Schlüsselpaar: Es dient dem Besitzer einer VM zur Authentifizierung.
Aus Sicherheitsgründen arbeiten EC2-Instanzen nicht mit vorgefertigen Passwörtern. Das Ausweisen bei der VM erfolgt stattdessen mit einem Schlüsselpaar, zu dessen Anlegen Sie aufgefordert werden. Beim erstmaligen Erzeugen einer EC2-Instanz wählen Sie die Option „Create a new key pair“ aus und vergeben einen Namen. Der Button „Download Key Pair“ erlaubt das einmalige Herunterladen einer PEM-Datei. Diese lässt sich später nicht nochmals beschaffen. Nach dem einige Sekunden dauernden Startprozess finden Sie sich in einer Übersichtsseite wieder, in der die neue VM durch eine nach dem Schema
i-09f1f4639938a250d aufgebaute ID aufgelistet ist. Klicken Sie diese an, um Detailinformationen zu laden. Von besonderer Wichtigkeit ist der im Feld „Public DNS“ eingegebene String, der nach dem Schema ec2-54-235-15-230.compute-1.amazonaws.com aufgebaut ist.
i-09f1f4639938a250d aufgebaute ID aufgelistet ist. Klicken Sie diese an, um Detailinformationen zu laden. Von besonderer Wichtigkeit ist der im Feld „Public DNS“ eingegebene String, der nach dem Schema ec2-54-235-15-230.compute-1.amazonaws.com aufgebaut ist.
Für den eigentlichen Verbindungsaufbau ist die PEM-Datei erforderlich, die mittels CHMOD mit stark eingeschränkten Rechten ausgestattet sein muss. Erst danach wird sie von SSH akzeptiert.
Die folgende Befehlssequenz liefert eine Shell zurück, die in die neue VM eingeloggt ist:
- tamhan@tamhan-thinkpad:~$ chmod 400 NMGKey.pem
- tamhan@tamhan-thinkpad:~$ ssh -i NMGKey.pem ubuntu@ec2-54-235-15-230.compute-1.amazonaws.com
Kritisch ist der Benutzername, da er von AMI zu AMI unterschiedlich ist. Der Kasten „Nutzernamen bei AWS“ auf Seite 91 zeigt einige häufige User-Namen, die man in der AWS-Praxis immer wieder antrifft.
An dieser Stelle ist unsere EC2-Instanz eine Linux-Box wie jede andere. Sie unterscheidet sich von einem Prozessrechner nur insofern, als sie auf die Hardware nicht physikalisch zugreifen kann. Im Rahmen des erstmaligen Bootens der VM arbeitet Amazon als User Data bezeichnete Parameter ab. Diese können in Form eines Shell-Skripts oder als Cloud-Init-Befehle vorliegen. Informationen zu den beiden Vorgehensweisen finden sich unter https://docs.aws.amazon.com/AWS
EC2/latest/UserGuide/user-data.html. Zur Laufzeit stehen diese Infos unter http://169.254.169.254/latest/ bereit, wo sie mit CURL oder einer gewöhnlichen HTTP-Transaktion abgerufen werden können.
EC2/latest/UserGuide/user-data.html. Zur Laufzeit stehen diese Infos unter http://169.254.169.254/latest/ bereit, wo sie mit CURL oder einer gewöhnlichen HTTP-Transaktion abgerufen werden können.
Ein weiterer interessanter Aspekt ist das Metadatensystem, das Informationen zur Selbstreflektion bereitstellt. Auf unserer soeben neu angeworfenen EC2-VM würde sich das Stammverzeichnis beispielsweise so präsentieren:
- ubuntu@ip-172-31-14-20:~$ curl http://169.254.169.254/latest/meta-data/
- ami-id
- ami-launch-index
- ami-manifest-path
- block-device-mapping/
- hostname
- instance-action
- instance-id
- instance-type
- local-hostname
- local-ipv4
- mac
- metrics/
- network/
- placement/
- profile
- public-hostname
- public-ipv4
- public-keys/
- reservation-id
- security-groups
Wer zur Laufzeit den öffentlichen Hostnamen der VM erfahren will, vertraut auf CURL:
- ubuntu@ip-172-31-14-20:~$ curl
http://169.254.169.254
/latest/meta-data/public-hostname
ec2-54-235-15-230.compute-1.
amazonaws.comubuntu@ip-172-31-14-20:~$
Bei der Arbeit mit der Kommandozeile beziehungsweise mit einem SSH-Fenster ist die seltsame Platzierung des nächsten Prompts auffällig. Amazon terminiert die im Metadatensystem liegenden Strings nicht mit einem Carriage Return, um das Abernten mit Skripts zu erleichtern.
Zur Demonstration der Persistenz bietet es sich an, im ersten Schritt eine Datei anzulegen und danach einen Neustart der virtuellen Maschine anzuweisen. Danach, also nach dem abermaligen Aufbauen einer SSH-Verbindung zum Host, ist die Datei nach wie vor am Platz:
- ubuntu@ip-172-31-14-20:~$ touch puber.txt
- ubuntu@ip-172-31-14-20:~$ sudo shutdown -r
now - . . .
- ubuntu@ip-172-31-14-20:~$ ls
- packages-microsoft-prod.deb puber.txt
Dieses Verhalten erschließt sich, wenn man den Lebenszyklus der Instanz näher betrachtet. Eine EC2-Instanz kennt zwei Arten der Ruhe. Erstens kennt sie den Stop-Zustand, wenn wir sie mit shutdown -h herunterfahren. In diesem Zustand verbraucht die EC2-VM zwar keine Rechenleistung und verursacht so auch keine Mietkosten, die in S3 bereitliegenden Speicherzellen für das Dateisystem bleiben allerdings erhalten. Daraus folgt, dass Speicherkosten anfallen. Im Zustand zwei, der sich erreichen lässt, indem man die virtuelle Maschine im Backend rechts anklickt, ist die virtuelle Maschine zerstört. Dann würde die weiter oben angelegte Datei gelöscht werden, sodass keinerlei S3-Kosten mehr anfallen.
Bevor Sie dies tun, werfen Sie einen Blick auf das kleine Glockensymbol in Alarm-Status. Es öffnet ein Fenster, in dem Sie Alarmbedingungen für den Monitor festlegen können. Das Backend kann Sie so beispielsweise darüber informieren, wenn die CPU der virtuellen Maschine zu sehr ausgelastet ist.
Die Inhalte der AWS-Konsole aktualisieren sich nicht automatisch. Wenn Sie die Speicherliste in einem Tab öffnen und Sie im anderen Tab die dazugehörige EC2-Instanz terminieren, verschwindet das schon gelöschte Volume erst nach manueller Aktualisierung aus der Liste.
AMI-Basis |
User-Name |
Amazon Linux AMI |
ec2-user |
Centos AMI |
centos |
Debian AMI |
admin oder root |
Fedora AMI |
ec2-user oder fedora |
RHEL AMI |
ec2-user oder root |
SUSE AMI |
ec2-user oder root |
Ubuntu AMI |
ubuntu oder root |