Ansible

Ansible ist ein Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern. Es kombiniert Softwareverteilung, Ad-hoc-Kommando-Ausführung und Konfigurationsmanagement. Es verwaltet Netzwerkcomputer unter anderem über SSH und erfordert keinerlei zusätzliche Software auf dem zu verwaltenden System. Module nutzen zur Ausgabe JSON und können in jeder beliebigen Programmiersprache geschrieben sein. Das System nutzt YAML zur Formulierung wiederverwendbarer Beschreibungen von Systemen. Quelle: Wikipedia

Ansible ist in Python implementiert und führt Befehle über SSH aus.

• Vergleich zwischen ansible und puppet
• Variable precedence: Where should I put a variable?
• Using filters to manipulate data
• Ansible 2.8 Porting Guide - notwendige Codeanpassungen für Version 2.8
• Ansible escaping: https://stackoverflow.com/questions/43091919/ansible-escaping-in-shell-module
• shell vs. reboot: http://www.mydailytutorials.com/introduction-shell-command-module-ansible/
• ansible reboot: https://stackoverflow.com/questions/29955605/how-to-reboot-centos-7-with-ansible
• Ansible playbooks Shellskript-style: paternoster
• ansible-xml ab Version 2.4 in ansible enthalten
• API von all-inkl
• How to Parse the XML response of a URI in ansible
• Learning ansible eBook (PDF) gut: looping
• Whitespace Control
• Control Whitespace in Ansible Templates

• ad-hoc-Befehl ausführen (nicht interaktiv, hier auf Gruppe „all“):

  ansible -i hosts -m shell -a "uname -a" all

• ad-hoc-Befehl ausführen (interaktiv mit ansible-console):

  ansible-console -i hosts

  anschließend kann auf der Gruppe „all“ (oder mit cd $GRUPPE auf einer anderen Gruppe) module benutzt werden. Beispiel: shell date führt auf allen hosts den Befehl date via shell-modul aus.

• facts: sind Variablen die auf dem Host erhoben werden, z.B. vom setup-modul:

  ansible $HOSTNAME -i hosts -m setup

  • gather_facts: False|True
  • subsets (network, hardware, virtual, facter, ohai):

    gather_subset: network

• inventory: Liste der Ziele (via SSH) auf die Aufgaben angewendet werden sollen
• module: Funktionen von Ansible
• variablen (in Playbooks, als host- oder groupvars, als extra-vars ) siehe auch: Variablen precedence
• handlers: Aufgaben die bei Bedarf ausgeführt werden, z.B service restart
• playbook: Eine Art Drehbuch was zu tun ist (Liste von Anweisungen, Variablen, Tasks und Verweise auf Rollen):

  ansible-playbook --limit=$HOSTNAME -i hosts playbooks/$mein-Playbook.yml

  • --limit grenzt auf bestimmte hosts ein, kann aber auch umgekehrt zum Ausschluss benutzt werden:

    --limit 'all:!not_this_host_or_group'

  • der Checkmode liefert eine Abschätzung ob alles in Ordnung ist

    -C, --check: don’t make any changes; instead, try to predict some of the changes that may occur

  • Diff was in Dateien geändert werden würde:

    -D, --diff when changing (small) files and templates, show the differences in those files; works great with –check

• roles („Rollen“): ausgelagerte Playbooks, die zur Wiederverwendung optimiert sind
• collections: Verbreitungsformat für playbooks, roles, modules, and plugins
• tags ¹⁾: nur einzelne ausführen

  --tags foo

  oder

  --skip-tags always|tagged|untagged

  . Aber Achtung: eine Aufzählung in folgendem Format ist eine „ODER“-Verknüpfung

  - name: debug baz
    debug: msg=baz
    tags:
      - foo
      - bar

• tasks: einzelne Arbeitsschritte die jeder Host durchläuft
• vault: Speicher für Zugangsdaten
• ansible-galaxy (requirements): Sammlung von Rollen unter https://galaxy.ansible.com
• YAML: ist einfache Auszeichnungssprache dessen Syntax alle Dateien haben müssen

Am Ende jedes Laufes wird ein „Play Recap“ angezeigt:

PLAY RECAP **********************************************************************************************
Host1      : ok=6    changed=1    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0

Bedeutung:

• Ok: Zustand vom task ist gegeben
• changed: Aufgabe wurde ausgeführt um das Ziel des taks zu erreichen (ggf. wurden handler ausgelöst)
• unreachable: host nicht erreichbar
• failed: task fehlgeschlagen, Ausführung endet hier für diesen Host
• skipped: tasks wurden wegen Bedingung nicht ausgeführt
• rescued: ein fehlgeschlagener taks wurde durch einen rescue-Block abgefangen

• https://docs.ansible.com/ansible/latest/plugins/callback.html
• https://docs.ansible.com/ansible/latest/collections/community/general/diy_callback.html

Definition von Idempotenz (engl. „idempotence“): „the property of certain operations in mathematics and computer science that can be applied multiple times without changing the result beyond the initial application“ (Quelle)

Generell geht darum bestimmte Aufgaben wiederholbar zu machen, d.h. eine Aufgabe sollte nicht bei jedem Lauf neu ausgeführt werden (was weitere Aktionen wie Server-restarts bedeuten kann) sondern nur wenn sich etwas ändert. Das Ergebnis sollte aber auch jedes mal die gleiche sein.

• Ensuring a Command Module Task is Repeatable with Ansible
• Idempotency, changed_when & Facts

Anforderungen: ansible-core support matrix (Debian10 wird also nur noch von ansible 10.7.0 / ansible-core 2.17.7 unterstützt da es kein Python 3.8 enthält)

Grundsätzlich ist es möglich die Paketquelle der Distribution zu benutzen und auch Python und Jinja2 darüber zu installieren. Ich rate allerdings davon ab weil die Entwicklung bei Ansible und Python (incl. jinja2) schneller geht als man den ausführenden Rechner aktuell halten kann (und der ist entscheidend weil dort der Code geparst wird!).

Mit pip können die installierte Version schnell und unabhängig vom System verändert werden.

pip kommt mit dem Paket python3-pip oder über andere Methoden.

Systemweit

• aktuelle Version: sudo -H pip3 install ansible
• bestimmte-Version: sudo -H pip3 install ansible==2.9.22 ²⁾

nur für den aktuellen Benutzer (nach /.local/bin):

• pip3 install ansible (bei Versionsänderung später: pip3 install ansible --upgrade)
• Pfad erweitern (in der .bashrc): PATH=~/.local/bin/:$PATH

Nach der Installation sollte verifiziert werden das ansible auch wirklich python3 benutzt (mit Version 2 gibt es zunehmend Problem aktuelle Module nachzuinstallieren):

ansible --version | grep "python version"

Der Ablauf der Interpreter discovery wird hier erklärt, auf den Zielhost wird oft noch python2 benutzt wenn der Stand-Python-Interpreter auf python2 steht.

Überschreiben lässt sich dies z.B. mit group_vars/all:

ansible_python_interpreter: /usr/bin/python3

• win_get_url doesn't follow redirects

# direkt auf ansible 2.10 geht nicht:
# pip3 install --upgrade ansible
 
pip3 uninstall ansible
 
pip3 install ansible
# ansible-base ist dependency!

Neuer Begriff: fcdn (fully qualified community module)→ module clash wenn Name gleich in unterschiedlichen collections. Siehe Ausgaben von „-vv“ Text ähnlich „redirecting (type: modules)“.

ansible-galaxy collection install community.general

Portin guides

Integrierte module sollten mit dem fully-qualified collection name (FQCN) angesprochen werden, siehe auch: Liste aller Module.

https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.10.html

Statt 2.11 wurde Version 3.x veröffentlicht, 2.12 ist dann 4.x. minor releases sind dann 3.1, 3.2, … bzw 4.1, 4.2 … usw. Neben der Migration von Rollen in Community-Roles wurde eine gemeinsame requirements-Datei für roles und collections eingeführt:

---
# ansible-galaxy install -r requirements.yml

roles:
  - src: geerlingguy.git
collections:
  - name: community.zabbix

ansible-lint kann aber weiterhin nur automatisch roles/requirements.yml bzw. collections/requirements.yml benutzen. Und ansible-semaphore hat dafür auch keinen support und nur einen teilweise fix.

Eine saubere Installation via pip: pip3 uninstall ansible ansible-base ansible-core && pip3 install 'ansible<4.4'

Mittlerweile sind die meisten module in die comunity (oder andere) collection gewandert. Diese lassen sich einzeln upgraden: ansible-galaxy collection install community.general –upgrade eine spezielle Version wird so installiert: ansible-galaxy collection install community.general:==X.Y.Z

Diese liegen dann in ~/.ansible/collections/ansible_collections.

ansible.cfg
.ansible-lint
collections/requirements.yml
group_vars/all
host_vars/.gitkeep
hosts
playbook1.yml
README.md
roles/requirements.yml
templates/.gitkeep
vault.yml

Einen Ordner „playbooks“ anzulegen, würde ich nicht unbedingt empfehlen, dann müssen die Rollen und Collections unterhalb dieses Ordner legen (u.a. ansible semaphore, ansible-lint suchen dann immer unterhalb des Ausführungsordners nach roles/requirements.yml bzw. collections/requirements.yml, da müsste man mit u.U. symlinks arbeiten was die Sache evtl. nicht wert ist).

Globale ansible-config (/etc/ansible/ansible.cfg), ggf. in ~/.ansible überschreiben:

[defaults]
# ggf. lieber in ssh-config:
remote_user = $MEIN_USER
private_key_file =
interpreter_python = /usr/bin/python3
remote_tmp = /tmp
gathering = smart
retry_files_enabled = False

Ordner:

/home/$USER/$PFAD_WO_ROLLEN_AUSGECHECKT_SIND /etc/ansible/roles none bind 0 0
/home/$USER/$PFAD_WO_FILTER_AUSGECHECKT_SIND /etc/ansible/filter none bind 0 0
/home/$USER/$PFAD_WO_FILES_AUSGECHECKT_SIND /etc/ansible/files none bind 0 0

Anforderung: Login via eigenem Systembenutzer, gemeinsames Repo und Vault ³⁾. gemeinsame Gruppe: admins

• Einrichtung:

  sudo chgrp admins /etc/ansible-vault-password
  sudo chmod g+ws /etc/ansible-vault-password
  sudo chgrp admins /etc/ansible
  sudo chmod g+ws /etc/ansible
  cd /etc/ansible
  sudo chgrp admins -R *
  sudo chmod g+ws -R *
  sudo chmod g+w .gitignore
  sudo chgrp admins .gitignore
  sudo chmod g+ws .git
  sudo chgrp admins .git
  cd .git
  sudo chmod g+ws -R *
  sudo chgrp admins -R *

• das /etc/ansible-Verzeichnis ist für die Gruppe admins schreibbar
• neue Dateien werden durch sticky-bit auf Gruppe admins gesetzt
• umask muss 002 sein, bereits in der /etc/profiles eingetragen:

  if [ $UID -gt 199 ] && ([ "`id -gn`" = "`id -un`" ] || [ "`id -gn`" = "admins" ] ); then
      umask 002
  else
      umask 022
  fi

• vault-passwort außerhalb des Repos /etc/ansible-vault-password
• ansible.cfg

  [defaults]
  host_key_checking=False
  remote_user=root
  private_key_file = /etc/ansible/.priv_key/id_rsa_deploy
  
  # format of string {{ ansible_managed }} available within Jinja2:
  ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S on {host}
  
  # vault
  # handling: "ansible-vault view|edit|rekey vault_tpi.yml"
  vault_file = MyVault.yml
  vault_password_file = /etc/ansible-vault-password

Yaml verträgt keine Tabs, die müssen vom Editor in Leerzeichen umgewandelt werden. Jeder Editor hat hier seine eigenes Einstellungsformat.

Beispiel für globale Einstellungen:

vim ⁴⁾ ~/.vimrc oder ~/.vim/vimrc:

set tabstop=2
set shiftwidth=2
set expandtab
# autocmd Filetype yml setlocal tabstop=2

nano (~/.nanorc):

set tabsize 2
set tabstospaces

Das Passwort kann

• aus einer Umgebungsvariable kommen (hier ansible_become_pass:

  ansible-playbook -e "ansible_sudo_pass=$ansible_become_pass" [...]

• oder durch interaktive Eingabe --ask-become-pass
• oder durch andere methoden (aus einer subshell, keepass etc. siehe https://stackoverflow.com/questions/21870083/specify-sudo-password-for-ansible ).

per playbook:

- hosts: all
  become: yes
  become_user: 'root'
  become_method: 'sudo'

  tasks:
  - name: whoami
    ansible.builtin.command: id
    register: id

  - name: Show whoami
    ansible.builtin.debug: msg="{{ id.stdout_lines }}"

das ganze geht auch per task oder global in der ansible.cfg:

[privilege_escalation]
become = True
become_method=sudo

Siehe auch: https://docs.ansible.com/ansible/latest/user_guide/become.html

Problem: Bei neue Hosts sind die Fingerprints lokal unbekannt, d.h. Ansible scheitert an der interaktiven Nachfrage von SSH (ob der Fingerprint akzeptiert werden soll).

Das könnte auf zwei Arten gelöst werden:

1. Entweder man deaktiviert den Check komplett
   1. per Config (es werden alle Fingerprints ignoriert): in ansible.cfg (/etc/ansible/ansible.cfg oder ~/.ansible.cfg)

      [defaults]
      host_key_checking = False

2. fallweise über Umgebungsvariable (ANSIBLE_HOST_KEY_CHECKING = False), z.B. mit export ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook …
3. etwas unschöner auch über die SSH-Config (fallweise –ssh-common-args='-o StrictHostKeyChecking=no' bzw. permanent)
4. oder einen task schreiben um die neuen Fingerprints lokal abzulegen:

     - name: Write the new ec2 instance host key to known hosts
       connection: local
       ansible.builtin.shell: "ssh-keyscan -H {{ inventory_hostname }} >> ~/.ssh/known_hosts"

Quellen: https://stackoverflow.com/questions/32297456/how-to-ignore-ansible-ssh-authenticity-checking

Firewallfreischaltungen für ansible-Rollen:

PIP:

• pypi.python.org (oder *.python.org)
• pypi.org
• python.org
• files.pythonhosted.org

github:

• github.com
• *.github.com oder api.github.com + codeload.github.com)
• raw.githubusercontent.com
• objects.githubusercontent.com (self-hosted agents in GitHub workflows)

docker

• hub.docker.com

• Rollen/Collections suchen: ansible-galaxy role search $NAME
• Installieren ansible-galaxy install $NAME
• einzelne git-Rolle auschecken: ansible-galaxy install git+$GIT-Adresse

Ablage: .ansible/roles bzw. ~/.ansible/collections/ansible_collections/

Beispiel: das inventory in der Datei hosts enthält ein Gruppe „meine-Server“ auf denen der Befehl „uname -a“ ausgeführt werden soll: ansible -i hosts meine-Server -a 'uname -a'

Passwort (für den vault) angeben:

• Interaktiv: --ask-vault-pass
• in Skripten: --vault-password-file ~/.vault_pass
  • mehrere Passwörter (via ansible.cfg:

    # $HOME does not work!
    # just lowercase to prevent problems on different OS (windows ignores upper/lower-case):
    vault_identity_list=~/.ansible_vault_devops_password,~/.ansible_vault_dev_common_password,~/.ansible_vault_dev_specific_password

• via Umgebungsvariable: ANSIBLE_VAULT_PASSWORD_FILE (export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt)
• Anweisung vault_password_file = /path/to/vault_password_file via config-Datei:
  • Umgebungsvariable ANSIBLE_CONFIG (export ANSIBLE_CONFIG=~/.ansible.cfg)
  • pro Benutzer: ~/.ansible.cfg
  • systemweit: /etc/ansible/ansible.cfg
• via gnome linux session keyring: https://stackoverflow.com/a/70346557
• external vault-plugin

• anlegen: ansible-vault create myVaultfile.yml
• editieren ⁵⁾: ansible-vault edit myVaultfile.yml
• anzeigen: ansible-vault view myVaultfile.yml
• entschlüsseln: ansible-vault decrypt myVaultfile.yml
• Passwort ändern: ansible-vault rekey myVaultfile.yml

Statt eines vault-files sind auch einzelne verschlüsselte Zeichenketten (encrypt_string) möglich, beispielweise z.B. um einzelne Variablen zu befüllen.

Beispiel: Hier bekommt die Variable DB_password den Inhalt „test“, was mit Passwort „test“ verschlüsselt wird:

• interaktiv nach verschlüsselter Zeichenkette fragen: ansible-vault encrypt_string
• … oder den Standard-input (=stdin) nehmen (via echo, cat, …) und die Ansible-Variable DB_password befüllen:

  echo -n test | ansible-vault encrypt_string --stdin-name 'DB_password'
  New Vault password: 
  Confirm New Vault password: 
  Reading plaintext input from stdin. (ctrl-d to end input)
  DB_password: !vault |
            $ANSIBLE_VAULT;1.1;AES256
            34343731306634383662333232613932373137626262643234633561356464663430343430636532
            3863333730383735363965643363386462376634366136650a353463663661316163373530386337
            38353365383830613935363838653833636530353537383834643865333130323032386661643132
            3132306637383466610a626164653830323565333635396662653066636237656262313965373263
            6264
  Encryption successful

→ diese Ausgabe kann direkt in yaml-Dateien benutzt werden.

Ein Playbook das verschlüsselte vault-strings benutzt muss von nun an bei m Aufruf entschlüsselt werden: ansible-playbook site.yml --ask-vault-pass

In awx/tower muss der credential type=Vault vorhanden sein: https://docs.ansible.com/ansible-tower/latest/html/userguide/credentials.html#id13

Ansible muss wissen das Variablen im vault-file liegen:

  vars_files:
    - myVaultfile.yml

–vault-id @prompt

https://docs.ansible.com/ansible/latest/user_guide/vault.html#vault-ids-and-multiple-vault-passwords

in awx/tower: https://docs.ansible.com/ansible-tower/3.4.0/html/administration/multi-creds-assignment.html#ag-multi-vault

ansible-pull kann sich selbst playbooks aus einem entfernten Repo ziehen, für einige Anwendungsfälle (kein Zugriff von Extern) ist das nötig.

ansible-pull -U $url_gitrepo

• rundeck und ansible-plugin

Red Hat Ansible Automation Platform Life Cycle Vergleich

https://github.com/ansible/awx / ansible automation plattform: unterstützt hop und excecution nodes ⁶⁾ zur Ausführung komplexen Topologien (in anderen Netzen/Umgebungen), siehe https://media.ccc.de/v/clt23-147-konfigurationsmanagement-uber-verschiedene-netze-mit-awx#t=1522 .

AWX: simple Anleitung (Installation ohne k8s!): https://github.com/selfhostx/ansible/blob/main/instructions/awx-manual-install.txt

ansible semaphore ist auf Minimaliät getrimmt, API, zeitgesteuert templates („cron“), spezielle Runner-nodes (bezahltes Pro-feature), interaktive Abfrage („survey“), alles wichtige ist dabei.

• rolle: https://github.com/selfhostx/ansible/tree/main/roles/semaphore
• playbook: https://github.com/selfhostx/ansible/blob/main/playbooks/semaphore.yml

Reihenfolge bei der Einrichtung:

1. Projekt anlegen
2. deploy key oder access tokens (z.B. gitlab) bei git-Repo authorisieren
3. Key store
   1. SSH-Zugriff System → Typ: ssh
   2. Repository-Zugriff → Typ: ssh oder access token (→Typ: login_password)
   3. vault password → Typ: login_password
4. repo+branch hinzufügen
5. Inventory (plain oder yaml): Achtung: User credentials wird für die Verbindung zum Host benutzt (SSH), also hier nicht den Access zum Repo angeben!
6. Environment (minimal zwei mal { } )
7. Template (task) anlegen mit den Details von oben

Zu beachten:

• pro Mandant ein semaphore einsetzen, da die ansible-runs noch nicht hart voneinander isoliert sind: https://github.com/ansible-semaphore/semaphore/issues/162 bzw. https://github.com/ansible-semaphore/semaphore/issues/1185 .
• Status von LDAP? (Test steht noch aus) issue #2240
• HA? (Test steht noch aus, sollte aber kein Problem sein mit der Rolle und Datenbank-cluster)

dynamische inventories werden nicht direkt unterstützt, können aber über override in templates angelegt werden:

[
  "-i",
  "./library/SKRIPT.py"
]

Datei /etc/ansible/hosts umfasst alle Server die durch Ansible angesprochen/verwaltet werden. Es ist möglich die Server sinnvoll in [Gruppen] zu unterteilen. Es können außerdem Gruppen aus anderen Gruppen erstellt werden.

Wichtig ist dabei zu beachten:

• Hostnamen sollen als FQDN angegeben werden.
• Gruppennamen in Kleinbuchstaben (mit Unterstrichen als Trenner) wie bei Pythons Variablennamen

Beispiel: „gruppen“ setzt sich zusammen aus gruppe1 und gruppe2:

[gruppen:children]
gruppe1
gruppe2

[gruppe1]
host1
...

[gruppe2]

Anzeige als Graph (inklusive aller Variablen aus host_vars/group_vars und deren Werten!): ansible-inventory -i hosts --graph

@all:
  |--@gruppe1:
  |  |--@host1:
  |  |  |--{ansible_python_interpreter = /usr/bin/python3}
[...]

• aus SQL

Special Variables

Alle Variablen (facts) anzeigen:

ansible -i hosts -m setup all

Gefiltert auf ansible_distribution*:

ansible -i hosts -m setup all -a "filter=ansible_distribution*"

Variablen können vielseitig überschrieben werden. Ein paar Auswahlmöglichkeiten:

• die role-defaults /roles/$Rollenname/vars/defaults/main.yml (wichtige Variablen werden definiert und sinnvolle/sichere Standardwerte gesetzt)
• inventory-vars (hostspezifisch): neben dem hostname variable=wert
• group-vars (gruppenspezifisch): group_vars/GRUPPENNAME oder all
• playbook-vars (für diesen run, diese Verwendung, z.B. create, destroy-Abzweigungen)
• extra vars (bei der Laufzeit des playbooks übergeben): export system_variable=test; ansible-playbook …

  playbook_Variable: "{{ lookup('env', 'system_variable') }}"

Siehe auch die vollständige Reihenfolge.

Variablen können verschiedene Typen haben, die teilweise intern umgewandelt werden könnten.

Den Typ der Variable kann mit dem Filter type_debug bestimmt werden (hier eine Zahl):

- debug:
    msg: "Datentyp der Variable Variablenname ist {{ Variablenname | type_debug }}"

Ergäbe dann bei einer Zahl eine Ausgabe wie:

Datentyp der Variable Variablenname ist int

Typen:

• boolean: true, false (yes, no)
• Zahl (integer/int):

   Variablenname: 1

• Zeichenkette (string/str):

   Variable: "1"

  oder

   Variablenname: '1'

• Liste (list):

  Variablenname: [a, b, c]

  oder

  Variable: 
    - a
    - b
    - c

• Dictionary (dict):

  Variablenname: {key1: value1, key2: value2}

  oder

  Variablenname: 
    - key1: value1
    - key2: value2

  oder

  Variablenname: 
    key1: value1
    key2: value2

Variablenname: 
  - key1: value1
    attribute: value1 
  - key2: value2
    attribute: value2

Links

• How to work with lists and dictionaries in Ansible
• loop over dictionaries
• Ansible : Loop inside loop

Understanding multi line strings in YAML and Ansible (Part I - YAML)

Oft benutzt: der „literal style“ (Format bleibt erhalten):

inhalt_bleibt_exakt_so: |+
  inhalt1
  inhalt2

Wiederverwendbare tasks/Aufgaben sollten möglichst in wiederverwendbare Rollen ausgelagert werden.

Suchreihenfolge von Ansible ist standardmäßig:

1. zuerst in ./roles
2. dann Benutzerverzeichnis ~/.ansible/roles (das wäre mit einem individuellen Login schlecht weil für andere nicht auffindbar)
3. dann in /etc/ansible/roles

Falls auf dem ansible-master mit mehreren Benutzer gearbeitet werden soll, kann auch der Systempfad /etc/ansible/roles benutzt werden.

Für verwendete Rollen lässt sich eine requirements.yml anlegen.

sudo ansible-galaxy install --roles-path=/etc/ansible/roles -r external-requirements-ansible-host.yaml

ansible-galaxy init role_name

Use the --remove option to disable and remove a Travis integration: ansible-galaxy setup --remove ID

siehe auch: Galaxy Developer Guide.

Siehe Liste: https://github.com/selfhostx/ansible/blob/main/ROADMAP.md

collections sind ein Verbreitungsformat für playbooks, roles, modules, and plugins. Link: Installing content

ansible-galaxy collection install my_namespace.my_collection

aus einem tar-ball:

ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections

Collections werden in ~/.ansible/collections/ansible_collections abgelegt.

Limitationen:

• es ist eine aktuelle Version von Ansible nötig (mind. 2.9 besser 2.10)
• Rollen können nicht von collections abhängen
• Installation via ansible-galaxy und einer requirements.yml funktioniert nur für roles ODER collections:

  ansible-galaxy role install -r requirements.yml
  ansible-galaxy collection install -r requirements.yml

im collection Verzeichnis: ansible-galaxy collection init my_namespace.my_collection

siehe Creating collections.

Ansible ist modular aufgebaut

• set_fact-Module (die Liste der facts erweitern)

• shell – Execute commands in nodes
• command / win_command
• script – Runs a local script on a remote node after transferring it
• raw – Executes a low-down and dirty SSH command

• Controlling playbook execution: strategies and more
• Delegation, Rolling Updates, and Local Actions

Stichworte:

ansible-playbook --forks=1
any_errors_fatal: true
max_fail_percentage: 30
serial: 11
einzelne tasks: "run_once: true"

auf einem bestimmten host

- name: "run on that_one_host host"
  ansible.builtin.shell: this_command_should_run_on_one_host
  when: ansible_hostname == 'that_one_host'

weitere Module siehe Files modules.

Achtung bei Dateirechten in octal-Schreibweise

die Angaben in octal (z.B. 600 für owner rw) müssen komplett als mode: 0644 oder in einfachen Anführungszeichen mode: '600' geschrieben werden. Alles andere bringt sonderbare Rechtemasken hervor

• package – Generic OS package manager win-package
• apt module
• yum

• ovirt
• dig - query DNS using the dnspython library
• ipaddr filter

• Action Plugins
• Arbitrary host name resolution in Ansible

templates sind via jinja2 implementiert, siehe Dokumentation.

pip install ansible-lint

bzw. upgrade:

pip install ansible-lint --upgrade

[301] Commands should not change things if nothing needs doing

      changed_when: false
      check_mode: yes

https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html

[602] Don't compare to empty string

-    changed_when: output.stdout != ""
+    changed_when: output.stdout | length > 0

[403] Package installs should not use latest Vorgeschlagene Lösung: „Package installs should use state=present with or without a version“**

Je nach Situation: Fehlalarm wenn explizit die letzte, aktuell verfügbare, Version installiert werden soll (aber die Version egal ist).

ansible-lint listet die Fehler auf

• Variable-Namen: nur Kleinbuchstaben und „_“
• Rollen-Namen: ^[a-z][a-z0-9_]+$
• Task-Bennennung: möglichst prägnant, Modul-Name als Präfix im Namen?
• Modul-Coding: https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html

Beispie: Warnung „no-changed-when“ ausschalten:

- name: 'Task mit unnützer Warnung durch ansible-lint' # noqa no-changed-when

Ansible hat das Henne-Ei-Problem Python zu benötigen aber um das zu Installieren braucht man bereits Python. Bei Debian/Ubuntu in der Minimalinstallation ist Python z.B. nicht installiert.

Aber auch das lässt sich mit Ansible-Mitteln lösen, dazu muss

• erstmal das erheben der facts („gather_facts: False“) abgeschaltet werden (weil das bereits mit Python realisiert ist)
• dann mittels raw-Modul direkt ein SSH-Kommando abgesetzt werden (Achtung: das beachtet kein Umgebungsvariablen wie z.B. Proxy-Einstellungen!)
• und zuletzt explizit nachgeholt werden (mit dem setup-Modul) um in weiteren tasks auf die facts zugreifen zu können.

Hier ein passendes Playbook:

---
- hosts: all
  gather_facts: False
  # become: yes
  pre_tasks:
  - name: Install python for Ansible
    ansible.builtin.raw: test -e /usr/bin/python || (apt-get -y update && apt install -y python)
    register: output
    changed_when: output.stdout != ""
  tasks:
  - name: Gathering Facts now
    ansible.builtin.setup:

https://gist.github.com/gwillem/4ba393dceb55e5ae276a87300f6b8e6f

Achtung: Wiederverwendung der Variable myoutput in anderen taks führt auch bei skip des tasks zur Veränderung des Inhaltes, siehe https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#registering-variables .

---
- hosts: all
  tasks:
    - name: uname anzeigen
      ansible.builtin.command: uname -a
      register: myoutput
 
    - name: show output (alle attributes)
      ansible.builtin.debug:
        msg: "{{ myoutput }}"
 
    - name: show standard output (stdout multiline)
      ansible.builtin.debug:
        msg: "{{ myoutput.stdout_lines }}"
      when: myoutput.stdout_lines is defined and myoutput.stdout_lines != '' and myoutput.stdout_lines != none
 
    - name: show error output (stderr multiline)
      ansible.builtin.debug:
        msg: "{{ myoutput.stderr_lines }}"
      when: myoutput.stderr_lines is defined and myoutput.stderr_lines != '' and myoutput.stderr_lines != none

Die Verwendung undefinierter Variablen führt zu Fehlern (Abbruch), Benutzern kann in einem extra tasks ein Hinweis gegeben werden.

- name: DNS sanity checks
  ansible.builtin.assert:
    that:
      - variable1 is defined
      - variable1|length>0
    msg: "Variable 1 muss definiert sein und einen Wert enthalten"
  run_once: true

https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html

„ignore_errors: true“ ist nicht ideal, mit failed_when bzw. changed_when können Bedingungen genannt werden wann ein task den Status „failed“ ⁷⁾ bzw. „changed“ bekommt.

Beispiel1: der task „ZFS mount“ soll nicht fehlschlagen bzw. changed sein wenn das Dateisystem bereits gemountet war ⁸⁾.

- name: ZFS mount
  ansible.builtin.shell: "zfs mount {{ item.zfs_dataset }}"
  register: zfs_mount_output
  failed_when: zfs_mount_output.rc != 0 and "filesystem already mounted" not in zfs_mount_output.stderr
  changed_when: zfs_mount_output.rc == 0 or (zfs_mount_output.rc == 255 and "filesystem already mounted" not in zfs_mount_output.stderr)

Beispiel2: task failed_when exitcode nicht 0 oder 32:

- name: Unmount server
  ansible.builtin.raw: "sudo umount {{ mountpoint }}"
  register: umount_result
  failed_when: umount_result.rc not in [ 0, 32 ]

• include_tasks

•   include_role:
      name: meineRolle

• import_playbook

Bestimmte Aufgaben werden nur bei bestimmten Anlässen gestartet. Das lässt sich einerseits über Bedingungen erledigt (when: Bedingung == true) andererseits können sog. handler von beliebigen Aufgaben aus angesteuert werden um eine Aufgabe wie z.B. einen Service-restart zu erledigen (Anlass: Config geändert).

Dies lässt sich mit „notify“ erledigen (Beispiel vmware-tools installieren + Dienst starten incl. autostart):

- name: "Ensure vmware guest tools are installed"
  ansible.builtin.package: name="open-vm-tools" state=present
  when:
    - ansible_virtualization_role == "guest"
    - ansible_virtualization_type == "VMware"
  notify: Start and enable vmtoolsd

ein entsprechender handler wäre dieser:

handlers/main.yml

---
- name: Start and enable vmtoolsd
  ansible.builtin.service:
    name: vmtoolsd
    state: started
    enabled: yes

Der handler wird nur ausgeführt wenn sich etwas ändert (task: „changed“), d.h. ist das Paket installiert ABER der Dienst nicht gestartet oder aktiviert wird der handler nie aufgerufen.

Robuste Abfragen sollten berücksichtigen dass die Variable run_task1 nicht definiert sein könnte und Typumwandlungen beachten (siehe unten):

- include_tasks: Aufgabe1.yml
  when: run_task1 is defined and run_task1|bool

---
 hosts: <hosts>
 tasks:
   - name: Use a block to group tasks
     block:
       - name: Task1
         ...

Es ist auch möglich "rescue" (Fehlerbehandlung) und "always" (z.B. cleanup) zu benutzen.

Durch das Zuammenspiel von YAML, Jinja2 und Python ergeben sich mögliche Probleme bei der Verwendung von True, true, False, false und yes, no:

https://chronicler.tech/red-hat-ansible-yes-no-and/

https://github.com/ansible/ansible/issues/11905. Lösung:

a: !!str yes
b: 'yes'

Beispiel und Erklärung: php_display_errors: !!str On (speichert „On“ explizit als string damit php_display_errors: On' erhalten bleibt).

Ein weiteres Beispiel ist javascript: Hier muss in templates explizit „true“ herauskommen (nicht True). Hier kann mit dem Filter $Variable|lower gearbeitet werden (Unwandlung in einen „lowercase string“).

Zusätzlich muss die Auswertung von bool-Variablen in Zukunft (ab Version 2.12) explizit angegeben werden:

[DEPRECATION WARNING]: evaluating ntp_enabled as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see 
CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Beispiel:

- name: Ensure NTP is running and enabled as configured.
  ansible.builtin.service:
    name: "{{ ntp_daemon }}"
    state: started
    enabled: yes
  when: ntp_enabled -> when: ntp_enabled|bool

Die Bedingung (when: …) ist optional.

- name: Set my_variable to true if undefined
  ansible.builtin.set_fact:
    my_variable: true
  when: my_variable is undefined

• die Bedingung (when: …) ist optional
• changed_when ist hier aktiviert weil ein changed-Status hier keinen einen Sinn macht

- name: Set machine_is_virtual when virtualization_role is guest
  ansible.builtin.group_by:
    key: machine_is_virtual
  changed_when: false
  when: ansible_facts['virtualization_role'] == "guest"

oder (etwas eleganter mit entweder Gruppe machine_is_virtual oder machine_is_metal in einer Zeile.

- name: Classify hosts (virtual or bare metal)
  ansible.builtin.group_by:
    key: machine_is_{{ "virtual" if ansible_facts['virtualization_role'] == "guest" else "metal" }}
  changed_when: false

statt lineinfile: blockinfile module – Insert/update/remove a text block surrounded by marker lines, Beispiel: https://stackoverflow.com/questions/22844905/how-to-create-a-directory-using-ansible

Dynamische passwort-Lookups würden jedes mal ein neues Passwort erzeugen, oft will man pro Host ein Passwort erzeugen und dies in einer Variable speichern.

Statt „/dev/null“ kann das Passwort auch (auf dem wo es läuft) in eine Datei geschrieben werden.

- name: Demo
  hosts: all
  gather_facts: False
  tasks:
    - set_fact:
        host_individual_password: "{{ lookup('password', '/dev/null length=16 chars=ascii_letters') }}"
      no_log: True
    - debug:
        msg: "{{ host_individual_password }}"

Es kann aber auch ein Passwort aus dem environment des masters geholt werden (das gilt dann aber für alle Hosts gleichermaßen!):

- name: Demo2
  hosts: all
  gather_facts: False
  vars:
    password_from_master: "{{ lookup('env', 'password_from_master') }}"
  tasks:
    - set_fact:
        password_from_master: "{{ lookup('env', 'env_password') }}"
      no_log: True
    - debug:
        msg: "{{ password_from_master }}"