• Befehle die sofort und ohne Playbook ausgeführt werden

Syntax:

ansible <Host-Gruppe> -i Hostdatei -u <Login-User> -m <Modul> -a "<Optional Argumente>" -b 

• -b sorgt ggf. dafür das man root wird (wenn der Login-User ein anderer ist) (ich nehme an sudo)

• Führt einen Satz von vorher definierten Befehlen und für bestimmte Host-Gruppen aus

ansible-playbook <Play-Book> -i <Pfad zur Host-Datei> -u <Einloogen als>

• Geschrieben in YAML
• oberste Ebene besteht aus einer Liste von Plays
  • darunter folgt ein Dictionary mit den Eigenschaften des Plays als Dictionary-Einträge:
    • name des Plays
    • hosts
    • tasks → enthält die Tasks
    • handlers → die Handlers

- name: <Beschreibung des Plays>
  hosts: <Liste der Hosts für die das Play ausgeführt werden soll>
  vars:
       <variable1>:<wert1>
       <variable2>:<wert2>
  remote_user: <username>
  
  tasks:
     - name: <taskname>
       <modulename>:
           <Moduleparameter>:value

Einige Keywords auf dieser Ebene:

tasks:
    - name: <somename>
      <modulename>:
          <parameter1>: <value1>
          <parameter2>: <value2>
    - name: <somename>
      <modulname>:
          <parameter1>: <value1>
          <parameter2>: <value2>
      notify: <handler-Name der Benachrichtigt werden soll>

• Tasks ist ein Dictionary-Eintrag der eine Liste mit den Tasks enthält
  • jedes Listenelement in tasks enthält die Beschreibung eines Tasko
    • jedes Task-Listenelement enthält ein Dictionary
    • der name-Key enthält einen frei definierbaren Namen als Value
    • der modulename-Key muss der Name des Moduls sein mit dem der Task ausgeführt werden soll
      • dieser wiederum enthält ein Dictionary welches die Parameter des Moduls als Dictionary-Einträge enthält

Auch wenn Tasks mit Name beginnt, so ist der ganze Abschnitt ein gemeinsamer Listeneintrag, bestehend aus einem Dictionary mit mehreren Keys, „name“ ist nur ein Key in diesem Dictionary und könnte auch an einer beliebigen anderen Stelle im Dictionary stehen.

Dienen dazu nach dem alle Tasks durch sind notwendige Dinge zu tun: wie Neustarts von Services usw.

• Werden durch notify-Eintrag in tasks getriggered - wen der Task „changed:True“ zurück gibt (also wirklich etwas geändert werden musste)
• werden aber erst nach dem Abarbeiten aller Tasks ausgeführt
• werden nur einmal ausgeführt → egal wieviele Tasks sie getriggered haben

tasks:
    - name: <somename>
      <modulename>:
          <parameter1>: <value1>
          <parameter2>: <value2>
    - name: <somename>
      <modulname>:
          <parameter1>: <value1>
          <parameter2>: <value2>
          notify: <somename>
handlers:
    - name: <somename>
      <modulname>:
         <parameter1>: <value1>
         <parameter2>: <value2>

Der Handler wird oben im zweiten Task aufgerufen (die notify-Zeile).
In der Handler-Konfiguration existiert dann ein Handler mit dem entsprechenden Namen.
Die Handler-Konfiguration entspricht ansonstem der eines Tasks.

Sammelt alle bekannten Facts über die entsprechende Maschine.
Das kann später benutzt werden um nur bestimmte Maschinen (auf die bestimmte Facts zutreffen) anzusprechen.

Ping die Maschinen die angegeben wurden

• Datei in der alle Devices stehen
• ggf. mit Name und Gruppe
  • dadurch lassen sie sich in den Playbooks mit Name oder Gruppe ansprechen

Gruppen:

[Gruppenname]
Einträge

Variablen-Sektionen:

[Gruppenname:vars]
Variable=Wert

• Der Gruppenname kann „all“ sein → in diesem Fall bezieht es sich auf alle Gruppen

Roles erlaubt es mehrere Playbooks zu einer Rolle zusammenzufassen.

Dadurch lassen sich Playbooks thematisch aufteilen, gleichzeitig aber zusammenfassen.0
Die Roles können wiederum in anderen Playbooks genutz werden.
Sinnvoll zum Beispiel um Systeme aufzusetzen → ein System kann dabei mehrere Rollen haben z.B. Basissystem + Webserver + Datenbankserver die jeweils in eigenen Rollen definiert werden können.

• jede Rolle ist eine Verzeichnisstruktur

• Die gelisteten Optionen können in verschiedenen ansible-Werkzeugen genutzt werden

• Zentrale Konfigurationsdatei
  • /etc/ansible/ansible.cfg
  • ~/.ansible.cfg