• Automatisiert administrative Vorgänge auf Systemen
  • Linux, Windows, Netzwerkgeräte
• benötigt keinen Agenten auf dem Zielsystem
  • für komplexere Aufgaben werden ansible modules übertragen und ausgeführt und anschließend wieder gelöscht
    • sind im Prinzip Code-Schnipsel/Scripte
• Anweisungen werden in Playbooks abgelegt
  • yaml-Files die definieren was passieren soll
  • dadurch Ablegen in git möglich
• Inventare die leicht zu verändern sind definieren auf welchen Maschinen Aktionen ausgeführt werden sollen
• benutzt Python
• Bestandteile sind idempotent
  • ein Play definiert einen Zustand in dem ein System sein soll
    • ist es schon in dem Zustand wird es nicht geändert
    • ein Play kann beliebig oft aufgerufen werden für ein System ohne etwas kaputt zu machen
  • gleiches gilt für Tasks (einzelne Schritte) und Modules die als Teil von Tasks aufgerufen werden

• Ansible bringt Plugins mit
  • inventory → zur Inventory-Verwaltung
  • modules → Komplexe Aktionen die auf den Inventory Hosts ausgeführt werden können
  • connection → Kümmern sich um die Verbindungen
  • become → Verwaltet die Privilegien → also zum Beispiel sudo-Plugin
  • vars → Benutzung von Variablen in den ansible Playbooks
  • lookup → Um Daten von anderen Quellen abzurufen (zum Beispiel Datenbanken, LDAP usw.)
  • callback → Andere Funktionen aufrufen bei Erfolg/Miserfolg

• Konfigurationsdatei auf dem Controller
• ini-Dateiformat
• per ansible -v kann man sehen welche Datei die mit der höchsten Priorität ist
  • so wie einige andere Pfade
• Die Dateien werden ihrer Piorität nach abgearbeitet (aufsteigende Priorität), nachfolgende Dateien überschreiben ggf. Werte der vorhergehenden
  • /etc/ansible/ansible.cfg
  • ~/.ansible.cfg
  • ./ansible.cfg → ansible.cfg im aktuellen Verzeichnis
  • $ANSIBLE_CONFIG=<filename> → eine Umgebungsvariable die auf eine ansible.cfg verweist

[defaults]
inventory = ./inventory
remote_user = myuser
ask_pass = false

[privilege_escalation]
become = True
become_ask_pass = False
become_user = root
become_method = sudo

• Datei besteht aus Sektionen
• defaults definiert die Defaults → wenn im Play nicht anders definiert
  • inventory → wo das Inventory zu finden ist
  • remote_user → User der zum Login genutzt wird
  • ask_pass → Ob nach einem Passwort gefragt werden soll
• privilege_escalation
  • Soll der Benutzer nach dem Login gewechselt werden (in der Regel zu einem mit höheren Rechten)
  • become → Aktiviert/Deaktiviert die Eskalation
  • become_ask_pass → Ob nach einem Passwort gefragt werden soll
  • become_method → Die Methode über die die höheren Privilegien erreicht werden sollen (in diesem Fall sudo)

• Daher kommen die Managed Hosts gegen die ein Play ausgeführt werden soll

• kann eine Datei sein (es gibt auch Plugins für andere Quellen)
• kann ein Verzeichnis mit mehreren Dateien sein
  • die Dateien können verschiedene Formate haben oder sogar Scripte sein
• hat keinen spezifischen Namen
• ist im ini-Format oder yaml-Format (sind die unterstützten Default-Formate → weitere gehen über Plugins, auch andere Quellen)
  • yaml-Format ist besser verständlich/einfacher zu erfassen

Als ini-Datei:

10.1.55.13

[Mailserver]
mail1.somewhere.de
mail2.somewhere.de

[DNSServer]
ns1.somewhere.de
ns2.somewhere.de


[webserver]
web[1:10].somweher.de

[production:children]
DNSServer
Mailserver

[debianserver]
mail1.somewhere.de
10.1.53.13

• ManagedHost können in oder außerhalb von Gruppen stehen
  • eine Gruppe ist ein Abschnitt in einer ini-Datei mit [Name] eingeleitet
• Managed Host-Namen können Bereiche beinhalten
  • siehe web[1:10] → dies erzeugt eine Liste von Hosts mit den Namen web1.somewhere.de, web2.somewhere.de usw.
• Gruppen können aus anderen Gruppen bestehen
  • Gruppenname hat dann den Suffix :children
  • siehe [production:children]
  • in der Gruppe stehen dann die Namen der Kind-Gruppen
• Managed Hosts können Teil von mehreren Gruppen sein
  • zum Beispiel geordnet nach Funktion, Ort, Betriebssystem usw.

Als yaml-File:

ungrouped:
  hosts:
    10.1.55.13:

Mailserver:
  hosts:
    mail1.somewhere.de:
    mail2.somewhere.de:

DNSServer:
  hosts:
    ns1.somewhere.de:
    ns2.somewhere.de:

webserver:
  hosts:
    web[1:10].somweher.de:

production:
  children:
    DNSServer:
    Mailserver:

debianserver:
  hosts:
    mail1.somewhere.de:
    10.1.53.13:

mixed:
  children:
    DNSServer:
  hosts:
    10.1.35.55

• im Gegensatz zu ini-Dateien können Children und Hosts in der gleichen Gruppe verwendet werden (siehe mixed-Gruppe)

• Es gibt 2 impliziert Gruppen
  • all → alle Einträge
  • ungrouped → Einträge die keiner Gruppe angehören
    • spielt nur bei ini-Dateien eine Rolle, bei yml-Dateien gibt es keine Einträge außerhalb von Gruppen

ansible-inventory ist das zu den Inventories gehörende Werkzeug.

ansible-inventory -i <Inventory-File/Directory> <Option> <Action>

Actions:

• --list

  → gebe das gesamte Inventory aus. Wird genutzt um Inventory an ansible zu übergeben

• --graph

  → gebe die Inventory-Struktur als Graph aus

• --host <Host>

  → gebe die Daten über einen bestimmten Managed Host aus

• wird in yaml-Dateien definiert
• ein Playbook definiert was gemacht werden soll
• Plays werden seriell (in der Reihenfolge wie sie dort stehen) ausgeführt
  • das gilt auch für Tasks

- name: Name of play 1
  hosts: group_or_name_of_hosts
  tasks:
    - name: NameofTask1
      modulename1:
        parameter1: value1
        parameter2: value2
    - name: NameofTask2
      modulename2:
         parameter1: value1
         parameter2: value2
- name: Name of play2
  hosts: group_or_name_of_hosts
  tasks:
    - name: NameofTask1
      modulename2:
        parameter1: value1
        parameter2: value2

• Playbook ist eine Liste von Plays
  • jedes Play ist ein Dictionary
    • name → optionaler Name für das Play
    • hostst → Ein Host, eine Liste (yaml-Liste) oder eine Gruppe oder Liste von Gruppen (aus dem Inventory) für den dieses Play gültig ist
    • Tasks → eine Liste von Tasks die ausgeführt werden sollen
      • Name → optional ein Name für den auszüführenden Task
      • Modulename → Name des Modules das den Task ausführen soll
        • Module kann man hier finden: https://docs.ansible.com/ansible/latest/collections/index_module.html
        • Dictionary definiert Parameter für das Modul

ansible-playbook <Option> <Playbookfile>

Führt das entsprechende Playbook aus

ansible-playbook <Playbookfile>

• ermöglichen Aktionen nur auszuführen wenn ein Task in einer Aktion resultiert
  • also wenn der Zustand den der Task erwartet nicht gegeben ist
• werden erst nach dem alle Tasks ausgeführt wurden ausgeführt
• Reihenfolge ist wie sie in der handlers-Sektion stehen
• Jeder Handler wird pro System maximal 1 mal ausgeführt

- name: My Play
  hosts: hosta
  force_handlers: true
  tasks:
    - name: Get kernel
      notify: Reboot after kernel installation
      ansible.builtin.apt:
        name: linux-image-amd64
        state: latest
  
  handlers:
    - name: Reboot after kernel installation
      ansible.builtin.reboot:

• Es wird geprüft ob die letztet Version des Paketes linux-image-amd64 installiert ist
  • wenn nicht wird er installiert
• Wenn alle Tasks abgearbeitet sind wird die Handler-Sektion der Reihe nach abgearbeitet
• der „get Kernel“ task sendet eine Notification an Handler „Reboot after kernel installation“ wenn der Task tatsächlich etwas tun musste (also nicht wenn der Kernel bereits vorhandeln war)

• force_handlers → Wenn true werden handler auch ausgeführt obwohl ein nachfolgender Task im play fehlgeschlagen ist.
  • Hat task A ein Notify und Task B schlägt fehl wird normalerweise der Handler von A nicht ausgeführt (trotz Notify). force_handlers sorgt dafür das Handler auch ausgeführt werden (die die eine Notification bis zu dem Zeitpunkt haben) wenn nicht alle Tasks erfolgreich sind
• notify → sendet eine Nachricht an einen Handler wenn der Task tatsächlich etwas ändert (state changed), die Bedingung die der Task sicherstellen soll also nicht gegeben war
• state: latest stellt sicher das die letzte Version eines Paketes installiert ist
• handlers: Liste von Modulen die aufgerufen werden wenn ein Task eine Notification für sie gesendet hat.
  • Die Liste wird erst nach dem alle Tasks im Task-Attribute des Plays abgearbeitet sind aufgerufen
    • Wenn es also 2 Tasks im Play gibt und der erste eine Notification an einen Handler sendet, wird erst noch Task 2 abgearbeitet, bevor der Handler aufgerufen wird
    • Handler werden nur für die Hosts aufgerufen wo ein Task „changes“ vorgenommen hat
    • Handler werden nach der Reihenfolge abgearbeitet wie sie in der handler-Sektion stehen
      • aber jeweils nur einmal pro System (auch wenn mehrere Tasks für das gleiche System und den gleichen Handler Notifies gesendet haben)

• Bedingung
• Block oder Task wird nur ausgeführt wenn die Bedingung erfüllt ist
• Bedingung ist ein Jinja-2-Ausdruck, ohne die {}

- name: My first play
  tasks:
    - name: First task
      hosts: hostA
      when: ansible_facts['os_family'] == "Debian"
      ansible.builtin.apt:
        name: neovim
        state: latest

• Führt den Task nur aus wenn die os_family in den Ansible-Facts Debian ist
  • kann Sinn machen wenn man zum Beispiel verschiedene Systeme mit verschiedenen Betriebssystemen hat und deswegen verschiedene Module verwenden muss

• gruppieren Tasks
  • Statements des Blocks werden vererbt an die Tasks → z.B. Become
  • when-Statements gelten für den gesamten Block usw.

- name: My first play
  hosts: myhosts 
  tasks:
    - name: First Block 
      when: ansible_facts['os_family'] == "Debian"
      become: true
      become_method: sudo
      block:
        - name: First task
          ansible.builtin.apt:
            name: neovim
            state: latest
            update_cache: True
        - name: Make a temporary file
          ansible.builtin.tempfile:
            prefix: myfile

• die Tasks im Block werden nur ausgeführt wenn die os_family==„Debian“ ist
  • when-Statement auf Block-Level
• Alle Tasks im Block werden mit root-Rechten ausgeführt
  • become: true und become_method: sudo auf Blocklevel
  • Tasks in einem Block erben die Statements auf Blockebene

• werden von Tasks aufgerufen und sind die eigentlichen Aktionen
• sind idempotent
  • sie prüfen vorher ob der Status den sie herstellen sollen schon gegeben sind und tun dann nichts
  • letzten Endes stellen sie sicher das ein bestimmter Zustand gegeben ist (zum Beispiel ein Dienst gestartet)

• können hier gefunden werden https://galaxy.ansible.com/ui/
• Dokumentation findet man hier: https://docs.ansible.com/ansible/2.8/modules/list_of_all_modules.html
  • Version in URL beachten

• Einige öfter genutzte Module

• Dokumentation für installierte Module

• können an verschiedenen Stellen und mit verschiedenen Gültigkeitsbereichen definiert werden
  • abhängig davon wo sie definiert werden überschreiben sie ggf. andere Definitionen
• https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html

Im Inventory:

mygroup:
  vars:
    myvar: 5
  hosts:
    85.206.62.161:
      myvar: "Coming from 56.108.82.247 inventory host config"
    57.17.117.156:

• Die vars-Sektion unterhalb der Gruppe definiert die Variable (myvar) für alle Hosts dieser Gruppe
• myvar unterhalb des Hosts definiert myvar für diesen Host-Eintrag
  • das überschreibt für diesen Host den Wert der in der Gruppe definiert ist. Während für 57.17.117.156 weiterhin der Wert der Gruppe genutzt wird

In var-Directories:

• hat Vorrang vor Inventory-Einträgen
• unterhalb des Verzeichnisses wo das playbook liegt
• für Gruppen
  • group_vars/<Gruppenname>/beliebigerDateiname.yml
    • group_vars/dnsservers/vars.yml
• für einzelne Hosts
  • host_vars/<Hostname>/belieberdateiname.yml
    • host_vars/192.168.2.13/vars.yml

Inhalt der Datei sind key-Value-Pairs:

<variable>: <Wert>

package: apache2

In Playbooks:

• Plays können eine vars-Sektion haben

- name: Play-Name
  hosts: myhostlist
  vars:
    myvar: myvalue
  tasks:
    - name: sometaskt
      ansible.builtin.debug:
        msg: "{{myvar}}"

• das Play hat ein vars-Dictionary in dem myvar definiert wird
• Variablen können über Jinja2-Syntax genutzt werden

  {{Variable}}

  • es empfiehlt sich wenn sie in Strings genutzt werden diese in „“ zu setzen

- name: Play-Name
  hosts: myhostlist
  tasks:
    - name: sometask
      vars:
        myvar: someothervalue
      ansible.builtin.debug:
        msg: "{{myvar}}"

• Fassen Tasks zusammen um eine größere Aufgabe zu erledigen
• Machen die Wiederverwendbarkeit von Abläufen einfacher
• können aus Playbook aufgerufen werden
• Konfiguration erfolgt über Variablen

- name: Play-Name
  hosts: myhostlist
  roles:
    - <role-name>

• Tool zum Verwalten von Rollen

Roles und Modules sind in Collections zusammengefasst, die heruntergeladen werden können (von ansible oder woanders).

Wenn ein Modul:

ansible.builtin.debug

heißt, dann ist „ansible.builtin“ die Collection.

• Ist das Tool zum verwalten und managen von Collections

• Plugins sind Erweiterungen von Ansible
  • Module sind eine Unterkategorie von Plugins
• befinden sich in Collections und können über ansible-galaxy installiert werden

• können hier gefunden werden https://galaxy.ansible.com/ui/
• Dokumentation findet man hier: https://docs.ansible.com/ansible/2.8/modules/list_of_all_modules.html
  • Version in URL beachten

• Liefert Dokumentation für installierte Module