Wer Ansible noch nicht kennt: Man kann sich Ansible als eine Art mächtiges SSH-Werkzeug vorstellen, welches diverse Operationen auf definierten Ziel-Maschinen ausführt (hauptsächlich für Linux-Server genutzt, Windows-Kisten lassen sich damit allerdings ebenfalls ansprechen).
Der Vorteil von Ansible? Man benötigt keine Client-Agents oder ähnliche Software – eine funktionierende SSH-Verbindung zum Zielrechner ist ausreichend. Ansible ist hierbei auch der Zustand des Zielrechners egal. Wenn z.B. das Paket „apache2“ via APT auf dem debian-basierten Zielrechner installiert werden soll, wird geprüft, ob auf dem Zielrechner bereits apache2 installiert ist. Ist dies der Fall, wird von Ansible nichts weiter unternommen. Ist dies nicht der Fall, installiert Ansible das Paket.
Was ebenfalls ziemlich schick ist: Es wird auch keine Server-Node benötigt. Ansible kann von jedem SSH-fähigen Client oder Server ausgeführt werden. I.d.R. geht man dabei so vor, dass die eigenen Configs, bzw. Aufgaben (bei Ansible „Playbooks“ genannt) versioniert werden (Github, Gitlab, o.ä.) und bei Bedarf versioniert erweitert und angepasst werden können. 12 Server und auf allen soll „htop“ nachinstalliert werden? Eine Zeile in Ansible und die Sache ist geritzt.
Ein kleines Beispiel einer möglichen Ansible-Anwendung ist das Aktualisieren sämtlicher Server-/Rechner-Nodes, auf welche man generell Zugriff via SSH hat. Im Folgenden als kurze Orientierung das Playbook („in etwa“ YAML-Format):
dist-upgrade.yml
Die Datei „dist-upgrade.yml“ ist das sog. Playbook des Ansible-Auftrags. In dieser Datei wird beschrieben, was auf welchen Hosts ausgeführt werden soll. Grundsätzlich orientiert sich ein Ansible-Playbook an der YAML-Syntax. Tatsächlich findet man allerdings verschiedene Formate und Markups in einer solchen Datei. Neben reinem YAML kommen zusätzlich eigene sog. „Custom Keys“, Python-Code und stellenweise Jinja2-Syntax vor.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
- hosts:
all
become: true
gather_facts: no
vars:
verbose: true
log_dir: "log/dist-upgrade/{{ inventory_hostname }}"
pre_tasks:
- block:
- setup:
rescue:
- name: "Install required python-minimal package"
raw: "apt-get update && apt-get install -y --force-yes python-apt python-minimal"
- setup:
tasks:
- name: Update packages
apt:
update_cache: yes
upgrade: dist
autoremove: yes
register: output
- name: Check changes
set_fact:
updated: true
when: not output.stdout is search("0 upgraded, 0 newly installed")
- name: Display changes
debug:
msg: "{{ output.stdout_lines }}"
when: verbose or updated is defined
- block:
- name: "Create log directory"
become: no
file:
path: "{{ log_dir }}"
state: directory
changed_when: false
- name: "Write changes to logfile"
become: no
copy:
content: "{{ output.stdout }}"
dest: "{{ log_dir }}/dist-upgrade_{{ ansible_date_time.iso8601 }}.log"
changed_when: false
when: updated is defined
connection: local
ansible.cfg
In der ansible.cfg-Datei werden Einstellungen für Ansible gespeichert. Wichtig: Ansible nutzt eine solche Datei, wenn der Befehl im selben Verzeichnis ausgeführt werden soll. Befindet sich keine ansible.cfg-Datei im aktuellen Verzeichnis, greift Ansible auf die globale Einstellungsdatei unter /etc/ansible/ansible.cfg zurück. Dies ist der Speicherort unter Arch Linux bei Installation via Pacman.
2
inventory = ./hosts
Aufgerufen wird das Playbook – also die YAML-Datei über den Befehl ansible-playbook dist-upgrade.yml. Im Anschluss wird jeder Server aus der hosts-Datei abgearbeitet und entsprechende Rückmeldungen – falls es welche gibt – in einer Log-Datei pro Server und Durchlauf festgehalten.
