Cloud-Ressourcen stundenweise mieten

Speichermedium auswählen

von - 17.12.2018
Schlüsselpaar
Schlüsselpaar: Es dient dem Besitzer einer VM zur Authentifizierung.
Die Zuweisung von Subnet und Co. darf übernommen werden. Danach wählen Sie das Speichermedium aus und weisen ein Tag zu. Im Interesse der Sicherheit sollten Sie in der Security Group den Zugriff auf die VM beschränken. Klicken Sie in der Source-Combobox die Option „My IP“ an, um die IP der aktiven Workstation ins Textfeld zu übernehmen. Nach dem Abnicken der Übersichtsseite folgt ein Klick auf „Launch“, um den eigentlichen Startprozess zu befehligen.
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.
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:
  1. tamhan@tamhan-thinkpad:~$ chmod 400 NMGKey.pem
  2. 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.
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:
  1. ubuntu@ip-172-31-14-20:~$ curl  http://169.254.169.254/latest/meta-data/
  2. ami-id
  3. ami-launch-index
  4. ami-manifest-path
  5. block-device-mapping/
  6. hostname
  7. instance-action
  8. instance-id
  9. instance-type
  10. local-hostname
  11. local-ipv4
  12. mac
  13. metrics/
  14. network/
  15. placement/
  16. profile
  17. public-hostname
  18. public-ipv4
  19. public-keys/
  20. reservation-id
  21. security-groups
 
Wer zur Laufzeit den öffentlichen Hostnamen der VM erfahren will, vertraut auf CURL:
  1. 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:
 
  1. ubuntu@ip-172-31-14-20:~$ touch puber.txt
  2. ubuntu@ip-172-31-14-20:~$ sudo shutdown -r
    now
  3. . . .
  4. ubuntu@ip-172-31-14-20:~$ ls
  5. packages-microsoft-prod.deb puber.txt
 
Dieses Verhalten erschließt sich, wenn man den Lebens­zyklus 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

Verwandte Themen