Was ist Ansible?

Ansible ist ein Werkzeug für:

• Konfigurations-Management
• Deployment
• Orchestrierung
• Provisionierung

Konfigurations-Management

Die Wunschkonfiguration eines Zielsystems wird deklariert. Ansible stellt die Wunschkonfiguration des Zielsystems her, indem es z. B.:

• Benötigte Pakete installiert
• Konfigurationsdateien erstellt bzw. mit den benötigten Parametern befüllt
• Datei- und Verzeichnisberechtigungen setzt
• Dienste in den definierten Status versetzt (running, stopped, reloaded, etc.)

Deployment

Der Ausdruck Deployment wird in diesem Kontext verwendet, wenn Software auf Server verteilt, eingerichtet und die benötigten Dienste zu starten sind.

Ansible kann sowohl zum Konfigurations-Management als auch zum Deployment genutzt werden. Da beide Bereiche eng miteinander verzahnt sind, erleichtert es die Arbeit, da ein Werkzeug für beide Aufgaben verwendet werden kann.

Orchestrierung

Von Orchestrierung wird gesprochen, wenn die Reihenfolge, wann welche Aufgaben ausgeführt werden, eine entscheidende Rolle spielt. Zum Beispiel weil Abhängigkeiten aufzulösen sind oder mehrere Server an einem Deployment beteiligt sind. Beispiel:

1. Datenbank starten
2. Webserver starten
3. Webserver in Loadbalancer eintragen

Provisionierung

Provisionierung beschreibt den Bereistellungsprozess einer neuen virtuellen Maschine in virtuellen/Cloud-Umgebungen.

• Installation einer VM aus einem Template
• Registrierung von IP-Adresse und FQDN
• Konfiguration der Hostparameter
• Etablierung benötigter Regeln in z. B. Firewall oder Loadbalancer

Grundlegende Eigenschaften und Rahmenbedingungen

• Arbeitet "Push-Based"
• Benötigt keinen Agenten auf den Zielsystemen
• Bietet Playbook- und Ad-Hoc-Modus
• Der Control Node kann unter BSD, Linux, macOS und Solaris betrieben werden;
  Windows wird als Control Node nicht unterstützt
• Der Control Node benötigt ab Ansible 4.0.0 bzw. ansible-core 2.11 Python >= 3.8
• Managed Nodes müssen via SSH erreichbar sein und über Python 2 (Version >= 2.6) oder Python 3 (Version >= 3.5) verfügen
• Auch Windows-Hosts können gemanaged werden, wenn auf diesen PowerShell >= 3.0 und .NET >= 4.0 installiert ist
• Ansibles Playbooks basieren auf der YAML-Syntax (einfach zu lesen)

Push vs. Pull

Verarbeitungsablauf bei Pull-Verfahren

1. Änderung am Konfigurations-Management-Skript wird durchgeführt
2. Änderung wird auf den zentralen Master-Host übertragen
3. Agent auf dem Zielserver wird timergesteuert aktiviert
4. Agent auf dem Zielserver verbindet sich zum Master
5. Agent auf dem Zielserver lädt das neue Konfigurations-Management-Skript herunter
6. Agent auf dem Zielserver führt das Konfigurations-Management-Skript lokal aus

Verarbeitungsablauf bei Push-Verfahren

1. Änderung am Playbook wird durchgeführt
2. Änderung wird auf Control Machine übertragen
3. Playbook wird manuell oder zeitgesteuert ausgeführt
4. Ansible verbindet sich zu den Zielsystemen und führt die Änderungen durch

Die Architektur im Überblick

Inventory

[hosts-to-patch-by-jka]
isl-p1.hrz.uni-bielefeld.de
jka-rhel7-t1.hrz.uni-bielefeld.de
jka-rhel8-t1.hrz.uni-bielefeld.de
nbde-ptang1.hrz.uni-bielefeld.de
nbde-ptang2.hrz.uni-bielefeld.de
uhrz-tcpdump-p1.ad.uni-bielefeld.de
rhel-s0[1:5].hrz.uni-bielefeld.de
rpm-repo.hrz.uni-bielefeld.de
rpm-repo-p2.hrz.uni-bielefeld.de
virt-who-p1.hrz.uni-bielefeld.de
rhel-t2.hrz.uni-bielefeld.de
uhrz-rhel-t3.ad.uni-bielefeld.de
rhel-t4.hrz.uni-bielefeld.de

[t-stage:children]
t-hosts
pgsql-t

[i-stage:children]
hio-i-all

[q-stage:children]
q-hosts
pgsql-q
hio-q-all-1
hio-q-all-2
hio-k-all-1
hio-k-all-2

[p-stage:children]
p-hosts
hio-p-all-1
hio-p-all-2
pgsql-p

[t-hosts]
rhel-t[0:2].hrz.uni-bielefeld.de
rhel-t4.hrz.uni-bielefeld.de
rhel-t5.hrz.uni-bielefeld.de
rhel-s0[1:5].hrz.uni-bielefeld.de
				

Inventory

• Inventory als statische Datei
• Auflistung von Hosts als FQDN, IP oder Alias aus ~/.ssh/config
• Möglichkeit der (Mehrfach-)Gruppierung
• Dynamisches Inventory als Alternative oder im Mischbetrieb
• Kann aus Datenquellen wie LDAP, Amazon EC2, vSphere, etc. erstellt werden
• Bedarf zum Teil eigener Entwicklung
• Gruppierung z. B. nach OS zur Laufzeit

Module

Ansible kann genutzt werden, um "gewöhnliche" Shell-Skripte parallel auf Hosts auszuführen. Für viele Standardfälle existieren Module, welche die Nutzung vereinfachen. Module haben dabei folgende Eigenschaften:

• Deklarativ – Es wird der Zielstatus beschrieben, z. B.:

  user: name=hrzadm group=wheel status=present

• Idempotent – Module können problemlos mehrfach auf den gleichen Server angewendet werden

Module können dabei sowohl in Playbooks, als auch in Ad-hoc-Kommandos verwendet werden.

Sehr dünner Abstraktionslayer

• Vorteil: Geringe Lernkurve
• Nachteil: Verwaltung von Servern mit unterschiedlichen Betriebssystemen mit dem gleichen Modul häufig nicht möglich

Playbooks

Die Konfigurations-Management-Skripte werden in Ansible als Playbooks bezeichnet.

---
# Register RHEL-System add subscription and disable repo
- name: Register System and add Subcription
  hosts: all
  tasks:
    - name: Register system and add standard subscription
      redhat_subscription:
        activationkey: "some-string"
        org_id: 1234567
        state: present

    - name: Disable repo in redhat.repo
      command: /usr/sbin/subscription-manager repos --disable=rhel-7-server-rpms
				

Verarbeitungsablauf eines Playbooks

Ansible wird für jeden Task im Playbook:

1. Ein Python-Skript generierent
2. Das Skript auf die Hosts kopieren
3. Das Skript auf den Hosts ausführen
4. Die Ausführung auf allen Zielhosts abwarten
5. Weiter zum nächsten Task

Verarbeitungsablauf eines Playbooks

• Ansible führt die Tasks in der im Playbook angegebenen Reihenfolge aus
• Ansible führt jeden Task parallel auf den Zielhosts aus
• Ansible wartet, bis alle Hosts einen Task verarbeitet haben, bevor es mit der Verarbeitung des nächsten Tasks beginnt
• Schlägt ein Task auf einem Host fehl, wird dieser für alle folgenden Tasks nicht weiter berücksichtigt

Running the Playbook

root@ansible-pctrl01>ansible-playbook -i staging register_rhel.yml

PLAY [Register System and add Subscription] ************************************

TASK [setup] *******************************************************************
ok: [rhel-t2.hrz.uni-bielefeld.de]
ok: [avnscan-t01.hrz.uni-bielefeld.de]

TASK [Register system and add standard subscription] ***************************
ok: [avnscan-t01.hrz.uni-bielefeld.de]
ok: [rhel-t2.hrz.uni-bielefeld.de]

TASK [Disable repo in redhat.repo] *********************************************
changed: [avnscan-t01.hrz.uni-bielefeld.de]
changed: [rhel-t2.hrz.uni-bielefeld.de]

PLAY RECAP *********************************************************************
avnscan-t01.hrz.uni-bielefeld.de : ok=3    changed=1    unreachable=0    failed=0
rhel-t2.hrz.uni-bielefeld.de : ok=3    changed=1    unreachable=0    failed=0
				

Skalierung durch Rollen

• Rollen ermöglichen die Aufteilung von großen und komplexen Playbooks auf mehrere Dateien
• Rollen werden wie Tasks einem oder mehreren Hosts zugeordnet
• Über die Webseite Ansible Galaxy können (kostenlos) fertige Rollen für verschiedenste Anwendungszwecke bezogen werden.

Skalierung durch Rollen

roles/
`-- common            # Name der Rolle
    |-- defaults
    |   `-- main.yml  # Default-Variablen die überschrieben werden können
    |-- files
    |   `-- main.yml  # Dateien die auf verknüpfte Hosts hochgeladen werden
    |-- handlers
    |   `-- main.yml  # Zur Rolle gehörende Handlers
    |-- meta
    |   `-- main.yml  # Definition der Abhängigkeiten einer Rolle
    |-- tasks
    |   `-- main.yml  # Tasks
    |-- templates
    |   `-- main.yml  # Enthält Jinja2-Vorlagen
    `-- vars
        `-- main.yml  # Variablen die nicht überschrieben werden dürfen
				

Jede Datei ist optional. Wenn eine Rolle keine Handler enthält, besteht keine Notwendigkeit eine leere Datei handlers/main.yml zu erstellen.

Einsatz im BITS

Aktuelle wird Ansible im BITS genutzt durch:

• Linux-Admins
• WWW-Admins
• SAP-Admins
• Einige Einzelkämpfer

Nutzung durch die Linux-Admins

• Initiale Baseline-Konfiguration neu provisionierter Hosts
• Registrierung und Subskriptions-Management
• Konfiguration von Standard-Repos
• Installation von Softwarepaketen
• Konfiguration von DNS, Postfix und NTP
• Konfiguration von Firewall und SELinux
• Initiale Konfiguration von rheladm, root, sysadm und syscfg
• Sophos-AV
• RHEL-Patchmanagement: Zentral gesteuerte Installation von Red Hat Security Advisory
• Ad-Hoc-Administration von einzelnen Hosts und Hostgruppen

Nutzung durch die WWW-Admins

• Provisionierung von Anwendungs-Servern (z.B. MediaWiki, Mahara, Moodle, RStudio/Shiny, eLabFTW, Squid-Proxies, Portainer)
• Deployment von Anwendungen (z.B. Mahara und Moodle)
• Anpassung bestehnder Server (Benutzer anlegen, ...)
• Software-Installation und -Konfiguration
• Hilfsdienste anlegen (podman/docker, acme.sh, keepalived, memcached, ...)
• Cluster-Konfiguration (MediaWiki und Squid) und Staging

Nutzung durch die SAP-Admins

1. SAP-Instanz stoppen
2. Oracle-Instanz stoppen
3. VM herunterfahren
4. Snapshot der VM erstellten
5. VM wieder starten
6. AV stoppen
7. Update-Installation
8. Oracle starten
9. SAP wieder starten
10. Snapshot löschen