OpenStack-Workshop, Teil 2: Eine Schritt-für-Schritt Cloud-Installation

Eingedenk der am Markt herrschenden Vielfalt verschiedener Cloud-Lösungen ist die Auswahl des passenden Systems für die eigenen Ansprüche eine eher schwierige Angelegenheit. Haben die Planer von IT-Umgebungen diesen Schritt hinter sich gebracht und sich dabei für OpenStack entschieden, fängt jedoch das Leiden meist erst richtig an. Denn OpenStack genießt nicht unbedingt den Ruf, das bestdokumentierte Projekt der Open-Source-Szene zu sein. Zwar ist in den letzten Monaten die Dokumentation ein ganzes Stück besser geworden, was nicht zuletzt an der Hartnäckigkeit von Anne Gentle liegt – der Leiterin des Dokumentationsteams. Doch hapert es noch immer an einigen Stellen – so fehlt beispielsweise ein Dokument, das die Installation einer OpenStack-Wolke durchgängig von der Installation der Pakete bis hin zu der ersten VM erläutert.

Keine Panik: OpenStack wirkt umfangreich, doch die meisten Teile der ab Werk gelieferten Konfiguration lassen sich eins zu eins nutzen. Dieser Text beschäftigt sich mit der Frage, welche OpenStack-Komponenten notwendig für eine OpenStack-Basisinstallation sind und wie deren Konfiguration klappt. Das Ziel ist eine OpenStack-Referenzimplementation bestehend aus drei Knoten: Ein Knoten dient als Cloud-Controller, ein weiterer fungiert als Knoten für den OpenStack-Netzwerkdienst Quantum, und der dritte Knoten beheimatet als klassischer Hypervisor die virtuellen Maschinen der Umgebung.

Zur Vorbereitung: NTP, RabbitMQ und MySQL

Die gute Nachricht vorweg: NTP und RabbitMQ bedürfen nach der Installation auf Alice keiner Veränderungen; beide Dienste funktionieren unmittelbar nach der Installation mit Standardwerten.

Etwas anders sieht es für MySQL aus: Sämtliche OpenStack-Dienste benötigen eine eigene Datenbank in MySQL, die händisch anzulegen ist. Das Listing 1 hat die notwendigen Befehle. Das Beispiel geht davon aus, dass für den Root-User in MySQL kein Passwort gesetzt ist. Falls das im lokalen Setup anders ist, so ist den MySQL-Aufrufen jeweils der "-p"-Parameter hinzuzufügen, sodass der MySQL-Client jeweils nach dem Datenbank-Passwort fragt. Überdies muss MySQL so konfiguriert sein, dass es auf allen Interfaces lauscht – und nicht nur auf der Localhost-Adresse »127.0.0.1« . Dazu ist in »/etc/mysql/my.cnf« der Wert von »bind_address =« auf »0.0.0.0« zu ändern. Wenn also die Datenbanken angelegt sind, und die IP-Adresse entsprechend angepasst ist, kann es mit den eigentlichen OpenStack-Komponenten weitergehen.

mysql -u root <<EOF
CREATE DATABASE nova;
GRANT ALL PRIVILEGES ON nova.* TO 'novadbadmin'@'%'
  IDENTIFIED BY 'dieD9Mie';
EOF
mysql -u root <<EOF
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glancedbadmin'@'%'
  IDENTIFIED BY 'ohC3teiv';
EOF
mysql -u root <<EOF
CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystonedbadmin'@'%'
  IDENTIFIED BY 'Ue0Ud7ra';
EOF
mysql -u root <<EOF
CREATE DATABASE quantum;
GRANT ALL PRIVILEGES ON quantum.* TO 'quantumdbadmin'@'%'
  IDENTIFIED BY 'wozohB8g';
EOF
mysql -u root <<EOF
CREATE DATABASE cinder;
GRANT ALL PRIVILEGES ON cinder.* TO 'cinderdbadmin'@'%'
  IDENTIFIED BY 'ceeShi4O';
EOF

Aller Anfang: OpenStack Keystone

Keystone ist die Autentizifierungskomponente von OpenStack. Es handelt sich um den einzigen Dienst, der keinen anderen Dienst voraussetzt. Deshalb ist es sinnvoll, mit der Keystone-Installation auf Alice zu beginnen. Direkt nach der Installation der Keystone-Pakete empfiehlt es sich, die Keystone-Konfiguration in »/etc/keystone/keystone.conf« per Editor zu bearbeiten.

Wichtig ist, dass in der Zeile »admin_token = « ein entsprechender Wert als Admin-Token festgelegt wird. Das Admin-Token ist der Generalschlüssel für OpenStack: Wer den Wert kennt, kann nach Belieben Veränderungen in Keystone vornehmen. Es ist deshalb empfehlenswert, die Zugriffsrechte von »keystone.conf« so zu setzen, dass nur »root« die Datei lesen kann. Für das Beispiel kommt das Admin-Token »geheim« zum Einsatz.Keystone muss auch wissen, wo es seine eigene MySQL-Datenbank erreicht. Das geht über den SQL-Connection-String, der in »keystone.conf« innerhalb des »[sql]« -Blocks definiert ist. In der Standardkonfiguration verweist die Datei dort auf eine SQlite-Datenbank, für das konkrete Beispiel – MySQL ist auf Alice beheimatet – ist der Eintrag im Hinblick auf die zuvor angelegte MySQL-Datenbank wie folgt zu setzen:

[sql]
connection = mysql://keystonedbadmin:Ue0Ud7ra@192.168.122.111/keystone
idle_timeout = 200

Damit Keystone weiß, wie es seine Service-Definitionen zu speichern hat, sollten in »keystone.conf« außerdem die folgenden Einträge zugegen sein:

[identity]
driver = keystone.identity.backends.sql.Identity
[catalog]
driver = keystone.catalog.backends.sql.Catalog

»keystone.conf« ist damit bereits fertig; wenn die Datei gespeichert und der Editor geschlossen ist, folgt im nächsten Schritt das Anlegen aller von Keystone benötigten Tabellen in seiner Datenbank. Das geht mit dem dafür vorgesehenen Werkzeug: »keystone-manage db_sync« . Im Anschluss startet »service keystone restart« den Dienst neu, sodass er einsatzbereit ist.

Des Admins erste Handlung nach der Konfiguration ist es sinnvollerweise, einen Grundstock an Tenants und Benutzern anzulegen. In der Praxis geschieht das nicht händisch, sondern mittels vorgefertigter Skripte. Ein speziell auf diesen Artikel abgestimmtes Skript findet sich unter [1]. Es nutzt den zuvor in »keystone.conf« genutzten Schlüssel »geheim« und legt damit einen Tenant namens »admin« an, dem ein Benutzer gleichen Namens angehört und der als Passwort ebenfalls »geheim« nutzt. Zudem kümmert sich das Skript darum, dass ein »service« -Tenant entsteht, der Benutzer für sämtliche Dienste enthält und für jeden dieser Benutzer als Passwort auch »geheim« verwendet. Das Skript ist lediglich herunterzuladen und dann auf Alice über die Kommandozeile auszuführen.