Dynamic Inventory – Eine Ansible und OpenStack Lovestory

Für diejenigen unter euch, die mit Ansible möglicherweise nicht allzu vertraut sind: Es ist ein großartiges Tool, um in die Welt der Automatisierung einzusteigen und erleichtert euer Leben im Konfigurationsmanagement erheblich.  

Die Kennenlernphase

In diesem Tutorial werden wir ein grundlegendes Playbook durchgehen, welches man mit OpenStack verwenden kann, und uns mit der Verwendung dynamischer Inventare befassen. Dynamische Inventare haben einen großen Vorteil: man muss die Datei nicht jedes Mal manuell aktualisieren, wenn man einen neuen Server in einem Projekt einrichtet. Falls Ansible mit OpenStack verwendet wird, kann ein dynamisches Inventar-Plugin verwendet werden, um eine Liste der Server zu erstellen, die in der OpenStack-Umgebung ausgeführt werden. Das Plugin stellt eine Verbindung zur OpenStack-API her und sammelt Informationen über Instanzen, die bestimmte Kriterien erfüllen, beispielsweise solche mit einem bestimmten Tag oder die Ausführung eines bestimmten Images. Durch die Verwendung eines dynamischen Inventars kann man den Prozess der Erkennung und Verwaltung von Hosts in der Netzwerkumgebung optimieren, ohne eine statische Inventardatei manuell aktualisieren zu müssen. Dies ist besonders in größeren oder dynamischeren Umgebungen nützlich, in denen sich die Anzahl der Hosts ständig ändert. Die einzigen Voraussetzungen für dieses Tutorial sind Grundkenntnisse von Ansible und OpenStack. Und selbst als absoluter Anfänger sollten man dennoch in der Lage sein, den Kern dessen zu verstehen, was wir erreichen wollen. Zu Demonstrationszwecken werden wir die Server meines Projekts verwenden, in der Realität könnte es sich jedoch um beliebig viele Server handeln. In diesem Beispiel überprüfen wir lediglich die Betriebszeit aller unserer Server. Also lasst uns direkt anfangen! Die beiden wichtigsten Voraussetzungen sind (natürlich) Ansible sowie das OpenStack SDK, um die API zu steuern. Jedoch ist Vorsicht geboten: Abhängig von Ihrem System muss möglicherweise „pip3“ verwendet werden, da sich „pip“ auf „pip2“ bezieht, welches nicht mehr unterstützt wird. Zunächst installieren wir Ansible mit Pip von Python. Überprüfen wir, ob pip installiert ist: 

python3 -m pip -V

Wenn Sie die Meldung „No module named pip“ erhalten, können Sie es mit diesen Befehlen installieren: 

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py --user

Und anschließend können Sie auch Ansible installieren: 

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py --user

Mit diesem Befehl können wir überprüfen, ob es korrekt installiert wurde: 

ansible —-version

Die erste gemeinsame Wohnung

Nachdem wir Ansible nun installiert haben, kann mit dem OpenStack SDK fortgefahren werden. Nachdem wir sichergestellt haben, dass Pip definitiv installiert ist, können wir Folgendes verwenden: 

pip install openstack

Nachdem wir nun beide Programme sowie das Plugin installiert haben, können wir mit dem Schreiben eines einfachen Playbooks beginnen. Dieses Playbook ist, wie bereits erwähnt, sehr simpel gehalten und wir werden lediglich die Betriebszeit der Server überprüfen. Natürlich kann dies auch sehr viel komplexer gestaltet sein, aber das Prinzip ist immer dasselbe. Wir benötigen die folgenden Dateien in unserem Ordner, in dem wir den Ansible-Code ausführen: clouds.yaml In dieser Datei befinden sich alle unsere Anmeldeinformationen für OpenStack. Ansible benötigt diese, um Zugriff auf unser Projekt zu erhalten. Die Anmeldeinformationen erhält man, indem man die Datei vom OpenStack herunterlädt. So sieht meine aus: 

clouds:
  openstack:
    auth:
      auth_url: https://cloud.netways.de:5000/v3/
      username: “openstack-user"
      password: “super-secret-password“
      project_id: 12495myproject-id65684
      project_name: "1234-openstack-15def5"
      user_domain_name: "Default"
    region_name: "HetznerNBG4"
    interface: “public"
    identity_api_version: 3

ansible.cfg Hier habe ich einen Server eingefügt, der als Jumphost fungiert, sowie einen Benutzer, der benötigt wird um eine Verbindung zu unseren Servern herzustellen. 

[defaults]
ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p user1@jumpserver"'
remote_user=ubuntu

openstack.yml In dieser Datei geben wir an, welches Plugin wir verwenden und welche Variablen wir einschließen möchten. „private: false“ stellt beispielsweise sicher, dass wir öffentliche IP-Adressen verwenden. Dadurch wird auch unsere cloud.yaml-Datei verknüpft, sodass wir sie nicht in unseren Befehl einschließen müssen. Dies ist die Datei, die ich verwendet habe: 

---
plugin: 'openstack.cloud.openstack'
expand_hostvars: yes
fail_on_errors: yes
all_projects: false
private: false
clouds_yaml_path: ["./clouds.yml"]

playbook.yaml Dies ist das einfache Playbook, mit dem ich die Betriebszeit aller meiner Server ermittelt habe: 

---
- name: Print uptime of servers in OpenStack project
  hosts: all
  gather_facts: no
  tasks:
    - name: Print server uptime
      command: uptime
      register: uptime
    - debug: msg="{{ uptime.stdout }}"

Da nun alle Vorbereitungen getroffen sind, ist es an der Zeit, unser Playbook auszuführen und die Ausgabe zu überprüfen: 

ansible-playbook -i openstack.yml playbook.yml

Honeymoon

Nachdem das Playbook vollständig ausgeführt wurde, können wir überprüfen, ob es ordnungsgemäß funktioniert hat. Wir sollten die Ergebnisse wie oben auf dem Terminal ausgedruckt sehen. Sollte das Playbook viel komplexer sein und fehlschlagen, kann man einfach anhand der Fehlermeldungen sehen, wo das Problem aufgetreten ist. Das ist das Tolle an Ansible: Man kann das Playbook beliebig oft ausführen und erhält das gleiche Ergebnis. Dies wird auch als Idempotenz bezeichnet. Obwohl dies ein sehr grundlegendes Tutorial zu den Möglichkeiten eines dynamischen Inventars ist, kann man es ebenso ganz einfach auf viel komplexere Playbooks anwenden. Wenn das zugrundeliegende Projekt 100 Server umfasst, wäre dies ideal, da somit nicht jeder Server manuell konfiguriert werden muss. Jedoch kann dies auch bei kleineren Projekten hilfreich sein. Man muss beispielsweise die Details neuer Server nicht erneut eingeben, falls alte Server zerstört und analog neue eingerichtet werden müssen. Wenn Du mehr über IaaS erfahren oder weitere Tutorials zu verschiedenen anderen Dev-Ops-Themen lesen möchtest, sieh Dir doch unsere Blogs und die anderen Beiträge auf unserer Website an. Der Einstieg ins eigene Setup könnte nicht einfacher sein. Einer unserer MyEngineers hilft gerne dabei, Deine Projektideen zum Leben zu erwecken.