Wie Sie mit cloud-init die Cloud automatisieren

Einsatzmöglichkeiten für cloud-Init

Ein typisches Szenario für den Einsatz ist die Netzwerkkonfiguration, bei der cloud-init dafür sorgt, dass Netzwerkschnittstellen korrekt konfiguriert werden. Das kann die Zuweisung statischer IP-Adressen oder die Konfiguration von DNS-Servern umfassen. In einer OpenStack-Umgebung kann cloud-init dafür sorgen, dass eine Instanz bei ihrem ersten Start eine IP-Adresse aus einem vorgegebenen Subnetz erhält und dabei automatisch in die richtige Netzwerkzone integriert wird.

Ein weiteres wesentliches Anwendungsgebiet von cloud-init ist das Paket-Handling. Durch das Einspielen von Updates und das Installieren von Softwarepaketen direkt beim Start kann eine Instanz so vorbereitet werden, dass sie sofort einsatzbereit ist. Das ist besonders in Umgebungen wichtig, in denen die Zeit zwischen der Bereitstellung einer Instanz und ihrem produktiven Einsatz minimiert werden muss. Zum Beispiel kann in einer AWS-Umgebung cloud-init verwendet werden, um eine EC2-Instanz mit den neuesten Sicherheits-Updates zu versehen, eine spezifische Version des Apache Webservers zu installieren und diesen direkt mit einer vordefinierten Konfigurationsdatei zu starten.

Die Benutzerverwaltung ist ein weiterer zentraler Aspekt von cloud-init. Das ermöglicht die automatisierte Erstellung von Benutzern, die Konfiguration von SSH-Schlüsseln und das Setzen von Passwörtern. In einem Szenario, in dem eine große Anzahl von Instanzen für unterschiedliche Benutzer bereitgestellt werden muss, kann cloud-init dafür sorgen, dass jeder Benutzer automatisch mit den notwendigen Zugriffsrechten und Authentifizierungsmethoden ausgestattet wird. Zum Beispiel kann in einer Azure-Umgebung cloud-init so konfiguriert werden, dass bei jeder neuen Instanz automatisch ein Benutzer mit Administratorrechten angelegt wird, der Zugriff über einen vordefinierten SSH-Schlüssel hat.

Erweiterbarkeit und Komplexität in der Praxis

Cloud-init ist flexibel und kann durch benutzerdefinierte Module und Skripte erweitert werden. In einer Multi-Cloud-Strategie, bei der Instanzen in verschiedenen Cloud-Umgebungen mit unterschiedlichen Anforderungen bereitgestellt werden, kann cloud-init so konfiguriert werden, dass es je nach Umgebung unterschiedliche Konfigurationsparameter anwendet. Zum Beispiel kann ein Unternehmen, das sowohl AWS als auch Google Cloud Platform (GCP) nutzt, cloud-init so einsetzen, dass in AWS spezifische IAM-Rollen zugewiesen werden, während in GCP entsprechende Service-Konten konfiguriert werden. Das funktioniert auch in anderen Kombinationen, zum Beispiel mit Azure.

Die Flexibilität von cloud-init geht jedoch auch mit einer gewissen Komplexität einher. In sehr großen Umgebungen kann es eine Herausforderung sein, sicherzustellen, dass alle Instanzen korrekt konfiguriert sind. Insbesondere wenn benutzerdefinierte Skripte oder nicht standardisierte Konfigurationen verwendet werden, kann das Debugging und die Fehlersuche sehr komplex werden. Ein praktisches Beispiel aus einer OpenStack-Umgebung zeigt, dass cloud-init in Kombination mit Heat, dem Orchestrierungswerkzeug von OpenStack, verwendet werden kann, um komplexe Multi-Tier-Anwendungen zu provisionieren. Dabei muss cloud-init sicherstellen, dass jede Instanz nicht nur korrekt konfiguriert wird, sondern auch in der richtigen Reihenfolge startet und sich korrekt in die übergeordnete Infrastruktur integriert.

Vorteile und Herausforderungen beim Einsatz von cloud-init

Der größte Vorteil von cloud-init liegt in der Automatisierung der Initialisierungsprozesse, was die manuelle Arbeit erheblich reduziert und die Konsistenz der Konfigurationen sicherstellt. In einem DevOps-Kontext, in dem Infrastruktur als Code verwaltet wird, ist cloud-init oft ein zentraler Bestandteil von CI/CD-Pipelines, da es die sofortige Einsatzbereitschaft neuer Instanzen sicherstellt.

Im folgenden Beispiel wird cloud-init verwendet, um beim ersten Start einer EC2-Instanz auf Ubuntu-Basis einen Apache-Webserver zu installieren, eine einfache Webseite zu erstellen und den Webserver automatisch zu starten.

#cloud-config
package_update: true
package_upgrade: true
packages:
  - apache2
runcmd:
  - echo "<html><body><h1>Willkommen auf meinem Apache-Server!</h1></body></html>" > /var/www/html/index.html
  - systemctl enable apache2
  - systemctl start apache2

In diesem Beispiel stellen package_update und package_upgrade sicher, dass das System vor der Installation der Pakete auf dem neuesten Stand ist. Unter packages wird Apache2 zur Installation angegeben. Bei runcmd werden Befehle angegeben, die nach der Paketinstallation ausgeführt werden. In diesem Fall wird eine einfache HTML-Datei erstellt, der Apache-Webserver wird aktiviert und gestartet.

Beispiel: Netzwerkkonfiguration mit statischer IP in einer OpenStack-Umgebung

In diesem Beispiel wird cloud-init verwendet, um eine Instanz in einer OpenStack-Umgebung mit einer statischen IP-Adresse zu konfigurieren.

#cloud-config
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

Die Netzwerkkonfiguration wird durch die network-Anweisung definiert. version: 2 weist auf das aktuelle Netzwerkkonfigurationsschema hin. Unter ethernets wird das Interface eth0 konfiguriert, wobei dhcp4: false den Verzicht auf DHCP und die manuelle Zuweisung einer IP-Adresse ermöglicht. Die statische IP-Adresse, das Gateway und die DNS-Server werden explizit angegeben.

Beispiel: Anlegen eines Benutzers und Konfiguration eines SSH-Schlüssels

In diesem Beispiel wird cloud-init verwendet, um einen neuen Benutzer anzulegen und einen SSH-Schlüssel für den sicheren Zugriff auf die Instanz zu konfigurieren.

#cloud-config
users:
  - default
  - name: devuser
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArD3ZcXs...your-public-key... user@host

Der Abschnitt users spezifiziert die Benutzerkonfiguration. Der Benutzer devuser wird mit sudo-Rechten (ohne Passwortabfrage) angelegt. Der SSH-Schlüssel im Abschnitt ssh_authorized_keys ermöglicht den SSH-Zugriff auf die Instanz ohne Passwort.

Beispiel: Bereitstellung eines Nginx-Containers

Mit cloud-init können Admins auch Container automatisiert bereitstellen oder Container-Hosts. Im folgenden Beispiel wird cloud-init genutzt, um Docker zu installieren und einen Nginx-Container zu starten:

package_update: true
package_upgrade: true
packages:
  - docker.io
runcmd:
  - systemctl start docker
  - systemctl enable docker
  - docker run -d -p 80:80 nginx

Docker wird hier als Paket installiert. Danach startet runcmd den Docker-Daemon, aktiviert ihn für den automatischen Start und führt einen Nginx-Container im Hintergrund aus, der auf Port 80 lauscht.

Beispiel: Konfiguration von Multi-Tier-Anwendungen

Das nächste Beispiel zeigt, wie cloud-init in Kombination mit einem Orchestrierungs-Tool wie OpenStack Heat verwendet wird, um eine komplexe Multi-Tier-Anwendung zu konfigurieren:

#cloud-config
package_update: true
package_upgrade: true
packages:
  - mariadb-server
  - python3
  - python3-pip
runcmd:
  - systemctl start mariadb
  - systemctl enable mariadb
  - pip3 install flask
  - mkdir /opt/myapp
  - echo "from flask import Flask, jsonify" > /opt/myapp/app.py
  - echo "app = Flask(__name__)" >> /opt/myapp/app.py
  - echo "@app.route('/')" >> /opt/myapp/app.py
  - echo "def hello_world():" >> /opt/myapp/app.py
  - echo "    return jsonify({'message': 'Hello, World!'})" >> /opt/myapp/app.py
  - echo "if __name__ == '__main__':" >> /opt/myapp/app.py
  - echo "    app.run(host='0.0.0.0')" >> /opt/myapp/app.py
  - python3 /opt/myapp/app.py &

In dieser cloud-init-Konfiguration wird eine Instanz so eingerichtet, dass sie als Server für eine einfache Flask-Webanwendung fungiert. Der Prozess beginnt mit der Aktualisierung des Systems und der Installation der erforderlichen Pakete. Dazu gehören der MariaDB-Server, Python3 und pip3, das Paketverwaltungs-Tool für Python. Diese Pakete werden durch die packages-Anweisung installiert.

Anschließend führt runcmd eine Reihe von Befehlen aus, um die Umgebung für die Webanwendung zu konfigurieren und diese zu starten. Zuerst wird der MariaDB-Dienst gestartet und so konfiguriert, dass er bei jedem Systemstart automatisch ausgeführt wird. Danach wird Flask über pip3 installiert, da es das Webframework ist, das in dieser Konfiguration verwendet wird.

Es wird dann ein Verzeichnis /opt/myapp erstellt, das die Anwendung beherbergt. Mit einer Reihe von echo-Befehlen wird ein einfaches Flask-Skript in eine Datei namens app.py im zuvor erstellten Verzeichnis geschrieben. Dieses Skript definiert eine einfache Flask-Anwendung, die eine JSON-Antwort mit einer Begrüßungsnachricht (Hello World!) zurückgibt, wenn die Root-URL (/) aufgerufen wird.

Zuletzt wird die Anwendung mit Python gestartet. Das &-Zeichen am Ende des Befehls python3 /opt/myapp/app.py & weist das System an, den Python-Prozess im Hintergrund auszuführen. Das ist in der Regel sinnvoll, da der Start der Flask-Anwendung den weiteren Ausführungsprozess nicht blockieren sollte. Daher ist das &-Zeichen in diesem Kontext korrekt und gewollt, da es sicherstellt, dass der Befehl nicht den gesamten init-Prozess blockiert und die Anwendung im Hintergrund läuft.