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

© JY Lee, 123RF

Einrichtungsberater

Der erste Artikel dieses Workshops hat die Theorie hinter OpenStack beleuchtet, der zweite Teil kümmert sich um die Praxis: Wie lässt sich eine OpenStack-Wolke aus dem Boden stampfen?
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

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.

Listing 1

Datenbanken anlegen

Die folgenden Befehle legen die in MySQL benötigten Datenbanken an:

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019