21. November 2018 , 14:26 Uhr
von Marc Eggert

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.

--- - 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
Code-Sprache: JavaScript (javascript)

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 [cci lang=“bash“]/etc/ansible/ansible.cfg[/cci] zurück. Dies ist der Speicherort unter Arch Linux bei Installation via Pacman.

[defaults] inventory = ./hosts

Aufgerufen wird das Playbook – also die YAML-Datei über den Befehl [cci]ansible-playbook dist-upgrade.yml [/cci]. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

*

Durch die Abgabe eines Kommentars akzeptieren sie die Datenschutzerklärung von net73.com