Schon seit vielen Jahren setzten wir bei Apache Friends auf Virtualisierungslösungen um XAMPP unter den verschiendensten Betriebssystemen zu testen. Ganz am Anfang haben wird dazu ausschließlich VMware benutzt und später ist dann noch Parallels Desktop dazugekommen. Anders kann man es bei einer cross-plattform Software wie XAMPP auch kaum machen. Das ist nicht mal eine Frage des Budgets.

Seit Anfang dieses Jahres setzten wir für die Linux-Testumgebungen auch Amazons Elastic Compute Cloud (oder kurz EC2) ein und sind damit auch recht zufrieden. Letztendlich erscheint mir diese Lösung viel bequemer und effizienter, als in der eigenen Infrastruktur all die Ressourcen vorzuhalten.

Da wir dieses Jahr neben der Mac OS X-Version von XAMPP auch die Solaris-Version aus dem Beta-Zustand erwecken wollen, wurde für uns die Notwendigkeit von Solaris-Testsystemen größer denn je und nachdem meine Experimente »Solaris unter Parallels« und »OpenSolaris unter Parallels« erfolglos blieben, war nun EC2 an der Reihe sich der Solaris-Herausforderung zu stellen.

Hier das Protokoll meines Vorgehens beim Einrichten von OpenSolaris unter EC2. Vielleicht ist es ja für den einen oder anderen interessant.

Diese Beschreibung ist unter Mac OS X entstanden, sollte aber unter Linux oder einem anderen Unix-System analog funktionieren.

Die Vorbereitungen

Als erstes besorge man sich einen Amazon EC2 Account. Achtung, da EC2 richtiges Geld kostet muss man hier auch seine Kreditkarten-Daten hinterlegen. Das ganze ist also kein Spaß.

1. Nach dem Einrichten des EC2 Accounts wird man aufgefordert ein »X.509 Certificate« zu erstellen. Dieses Zertifikat enthält neben dem eigentlichen Zertifikat auch noch einen sog. privaten Schlüssel. Beides lädt man herunter und packt es in das Verzeichnis ~/.ec2.

   Letztendlich kann man ein beliebiges Verzeichnis wählen, in diesem Text verwende ich aber immer wieder genau dieses.

2. Wer wirklich OpenSolaris unter EC2 laufen lassen möchte, der muss sich nun noch bei »OpenSolaris on Amazon EC2« registrieren. Wer “nur” Linux benutzen möchte, der kann diesen Schritt überspringen. Achtung, das Registrieren für OpenSolaris unter EC2 dauert ein paar Stunden, also diesen Schritt rechtzeitig machen.
3. Nun die Amazon EC2 Command-Line Tools herunterladen und zu den Zertifikat und privatem Schlüssen in das Verzeichnis ~/.ec2 packen.
4. Der Inhalt des ~/.ec2 Verzeichnisses sollte jetzt etwa so aussehen:

   -rw-r--r--   1 oswald    42319 20 Aug 09:57 THIRDPARTYLICENSE.TXT
   drwxrwxr-x 148 oswald     5032 20 Aug 09:57 bin
   -rw-r--r--   1 oswald      916  3 Jan 17:39 cert-XXX.pem
   drwxrwxr-x  25 oswald      850 20 Aug 09:57 lib
   -rw-r--r--   1 oswald      926  3 Jan 17:39 pk-XXX.pem
   

5. Benutzer der Bourne Again Shell (meistens die Standard-Shell unter Linux und Mac OS X) suchen nun die Datei ~/.bashrc (einfach erstellen, falls es diese noch nicht gibt) und fügen folgende Zeilen hinzu:

   export EC2_HOME=~/.ec2
   export EC2_PRIVATE_KEY=$EC2_HOME/pk-*.pem
   export EC2_CERT=$EC2_HOME/cert-*.pem
   export EC2_URL=https://ec2.amazonaws.com 
   export PATH=$PATH:$EC2_HOME/bin
   export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/

   Benutzer der C Shell öffnen und erstellen ggf. die Datei ~/.cshrc und fügen folgende Zeilen hinzu:

   setenv EC2_HOME ~/.ec2
   setenv EC2_PRIVATE_KEY $EC2_HOME/pk-*.pem
   setenv EC2_CERT $EC2_HOME/cert-*.pem
   setenv EC2_URL https://ec2.amazonaws.com 
   setenv PATH $EC2_HOME/bin:$PATH
   setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home/

   Der Wert von JAVA_HOME muss evtl. angepasst werden. In diesem Beispiel verwende ich den Standardort des Java Runtime Environment unter Mac OS X.

Soweit die Vorbereitungen. Jetzt kann es auch schon losgehen.

Einrichten einer Server-Instanz

Das was man normalerweise eine VM oder virtuelle Maschine nennen würde, wird unter EC2 server instance oder einfach instance genannt. Die Basis für eine solche Instanz bildet das sogenannte Amazon Machine Image (AMI), also das EC2-Equivalent zu einem Festplatten-Image.

Wie auch bei anderen Virtualisierunslösungen hat man hier die Wahl: entweder man erstellt selbst so ein Image oder man wählt ein vorgefertigtes. Langfristig wird man wohl eher seine eigenen AMIs verwenden, aber für den Anfang ist ein AMI von der Stange sicherlich der effektivste Start.

1. Also als erstes ein gefälliges Image suchen.

   Mit dem folgenden Befehl bekommt man eine Übersicht über alle eigenen und alle von Amazon angebotenen AMIs:

   % ec2-describe-images -o self -o amazon | grep machine

   Will man allerdings OpenSolaris unter EC2 laufen lassen, dann wird man in dieser Liste nicht fündig. OpenSolaris wird momentan nur innerhalb einer Beta-Phase von EC2 unterstützt und in diesem Fall wird man nur unter
   »OpenSolaris based AMI catalog on Amazon EC2« fündig. Um allerdings die hier aufgeführten AMIs zu verwenden zu dürfen, muss man sich vorher bei Sun registriert haben (siehe oben).

   Ich entscheide mich für die AMI »OpenSolaris 2008.05 (build 91) 32-bit AMI for developers« mit der wunderbaren AMI ID ami-41e70328.

2. Alle folgenden Schritte passieren im ~/.ec2 Verzeichnis, jetzt also zunächst in dieses Verzeichnis wechseln:

   % cd ~/.ec2

3. Bevor man jetzt aber schon durchstarten kann, muss man zunächst noch ein Schlüsselpaar für SSH generieren, mit dem man später dann auf seine Server-Instanz zugreifen kann.

   ~/.ec2% ec2-add-keypair ec2-keypair > ec2-keypair

   Damit der SSH-Client später diese Schlüsseldatei akzeptiert, müssen die Zugriffsrechte so gesetzt sein, dass man nur selbst Zugriff auf diese Datei hat. Also schnell folgenden Befehl aufrufen:

   ~/.ec2% chmod 600 ec2-keypair

4. Achtung: Ab diesem Schritt rollt das Geld in Richtung Amazon. Zur Zeit sind es 10 USD-Cent für jede angefangene Stunde, die eine Instanz läuft. Wenn man später bei S3 auch noch eigene AMIs speichert, dann fallen für den Speicherverbrauch auch noch Kosten an.

   Gut, aber 10 Cent sind auch nur 10 Cent, also los gehts:

   ~/.ec2% ec2-run-instances ami-41e70328 -k ec2-keypair
   RESERVATION ...
   INSTANCE    i-87a705ee   ami-41e70328      pending ...

   Nun wird die Server-Instanz eingerichtet und hochgefahren. Einfach wiederholt diesen Befehl aufrufen um zu erfahren, wann das System bereit steht:

   ~/.ec2% ec2-describe-instances
   RESERVATION ...
   INSTANCE    i-87a705ee   ami-41e70328      pending ...

   Nach ein paar Minuten wird aus dem pending ein running und in der 4. Spalte erscheint die Adresse unsers neugeborenen Servers:

   ~/.ec2% ec2-describe-instances
   RESERVATION ...
   INSTANCE    i-87a705ee   ami-41e70328   ec2-XXX.amazonaws.com ...
   

Die Server-Instanz ist nun vollständig gestartet und unter der Adresse ec2-XXX.amazonaws.com erreichbar.

Zugriff auf den neuen Server

Zunächst ist da aber auch noch eine Firewall, die uns den Zugriff auf unseren neuen Server versagt.

1. Hier also erst mal den SSH-Port 22 durchlassen:

   ~/.ec2% ec2-authorize default -p 22
   GROUP      default	
   PERMISSION default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
   

   Damit wird generell der Zugriff auf den Port 22 erlaubt. Sicherlich für die Realität später ein bisschen zu viel, aber für einen erstes Ausprobieren eine durchaus pragmatische Einstellung.

2. Und nun kann man sich tatsächlich mittels SSH mit seinem neuen Server verbinden:

   ~/.ec2% ssh -i ec2-keypair root@ec2-XXX.amazonaws.com
   The authenticity of host 'ec2-XXX.amazonaws.com'
   can't be established.
   RSA key fingerprint is 35:60:80:ef:ae:f3:aa:92:9c:de:41.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added 'ec2-XXX.amazonaws.com' (RSA) to the 
   list of known hosts.
   Last login: Tue Aug 12 12:16:38 2008 from 192.18.43.225
   Sun Microsystems Inc.   SunOS 5.11      snv_91  January 2008
   -bash-3.2# 
   

   Nun kann man auf dieser Maschine seinen geplanten Tätigkeiten nachgehen.

3. Ist man damit fertig und braucht die Instanz nicht mehr:

   -bash-3.2# exit
   logout
   Connection to ec2-XXX.amazonaws.com closed.
   

   Good bye.

   Aber Vorsicht: Jetzt läuft die Server-Instanz natürlich noch und damit tickt auch noch die Stechuhr. Und um diese zu stoppen muss die Instanz noch heruntergefahren werden.

Und tschüß!

Zum Abschalten einer Server-Instanz gibt es zwei Wege.

1. Entweder man fährt das Gastsystem von innen herunter:

   -bash-3.2# shutdown -y -g0 -i0

2. Oder von aussen:

   ~/.ec2% ec2-terminate-instances i-87a705ee
   INSTANCE	i-87a705ee	running	shutting-down

   Ist das System dann heruntergefahren ändert sich der Zustand von running auf terminated:

   ~/.ec2% ec2-describe-instances
   RESERVATION ...
   INSTANCE i-87a705ee   ami-41e70328      terminated   ...
   

   Ich bevorzuge eigentlich immer die zweite Variante, da ich mir in diesem Fall sicher sein kann, dass ich den shutdown-Befehl nicht auf der falschen Maschine aufrufe. (Das ist mir zwar bisher nie passiert, aber ich geh da auch gerne auf Nummer sicher.)

Ein wenig später ist die Instanz dann komplett aus dieser Liste verschwunden und alles was wir auf diesem Rechner gemacht haben ist futsch.

So, und beim nächsten Mal schauen wir uns an, wie man Daten so speichert, dass sie nicht mit der Instanz im Nirgendwo verschwinden.

Referenzen

Der Einrichtungs-Part dieses Dokuments basiert auf dem
»Starting Amazon EC2 with Mac OS X« von Robert Sosinski. Seine Umgebungsvariablen-Schnipsel habe ich ein wenig angepasst und gekürzt. Wenn es damit Probleme gibt, ist es mein Fehler.

Alle anderen Informationen stammen aus Amazons
»Amazon Elastic Compute Cloud, Developer Guide API Version 2008-05-05«, was auch gleichzeitig die Referenz-Dokumentation für EC2 ist.