• 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>

• 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)

• 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