Playbooks

Für einfache Aufgaben reicht diese Vorgehensweise sicherlich aus, für komplexere Aufgaben sollten jedoch die Ansible Playbooks zum Einsatz kommen. Playbooks lassen sich beliebig komplex zusammenstellen. Das Beispiel aus Listing 3 zeigt ein einfaches Beispiel. Zuerst beschreibt es, für welche Hosts aus der Inventory-Datei die folgenden Anweisungen gelten sollen. Dann folgen drei Tasks. Ansible soll eine Template-Datei aus dem lokalen Ordner »/srv« auf die Systeme kopieren und diese im Verzeichnis »/etc/yum.repos.d/« speichern, dann findet die Installation des Software-Paketes »kubernetes« mittels »yum« statt und zum Schluss soll Ansible dann dafür sorgen, dass ein Dienst aus dem Software-Paket startet. Jeder Task wird hier durch einzelne Module und Parametern zu den Modulen dargestellt. Statt die Software mittels »yum« zu installieren, hätten Sie natürlich auch auf ein anderes Software-Modul zurückgreifen können, beispielsweise auf »apt« .

Listing 3

atomic.yaml

---
- hosts: atomic
  tasks:
  - name: install kubernets yum repo file
    template: src=/srv/kubernetes.conf dest=/etc/yum.repos.d/kubernetes.conf
  - name: ensure kubernetes is at the latest version
    yum: pkg=kubernetes state=latest
  - name: ensure kube-apiserver is active
    service: name=kube-apiserver state=started

Rufen Sie dieses Playbook nun auf, so erhalten Sie die in Listing 4 dargestellte Ausgabe. Hier ist schön zu sehen, wie die einzelnen Tasks auf den beiden Systemen ausgeführt werden.

Listing 4

Ruft man das Playbook auf, führt Ansible die verschiedenen Tasks auf den einzelnen System aus.

# ansible-playbook -i inventory atomic.yaml
PLAY [all] ********************************************************************
GATHERING FACTS ***************************************************************
ok: [192.168.100.100]
ok: [192.168.100.101]
TASK: [install kubernets yum repo file] ***************************************
changed: [192.168.100.100]
changed: [192.168.100.101]
TASK: [ensure kubernetes is at the latest version] ****************************
changed: [192.168.100.100]
changed:: [192.168.100.101]
TASK: [ensure kube-apiserver is active] ***************************************
changed:: [192.168.100.100]
changed:: [192.168.100.101]
PLAY RECAP ********************************************************************
192.168.100.100                  : ok=4    changed=3    unreachable=0    failed=0
192.168.100.101                  : ok=4    changed=3    unreachable=0    failed=0

Fazit

Der Artikel konnte nur einen sehr kleinen Einblick in die Welt von Ansible geben. Aber alleine die dargestellten Beispiele zeigen, wie flexibel das Tool ist und welche Möglichkeiten es bietet. Nicht umsonst wird es von Größen wie Spotify oder auch der NASA eingesetzt. Die Dokumentation [4] zeigt weitere Möglichkeiten der Software auf.

comments powered by Disqus
Mehr zum Thema

Netzwerkautomatisierung mit Ansible und AWX

Um in der Ansible-Erweiterung AWX eine Automatisierung zu starten, drückt der Admin nach dem Erstellen seiner Playbooks auf den Rakete-Button. Wie sich die so bildhaft dargestellte Beschleunigung der Konfiguration zahlreicher Netzwerkgeräte automatisch mit Ansible und AWX umsetzen lässt, zeigt dieser Workshop.

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

Ausgabe /2021