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

• 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

• roles („Rollen“): ausgelagerte Playbooks, die zur Wiederverwendung optimiert sind
• tags: nur einzelne ausführen

  --tags package

  oder

  --skip-tags always|tagged|untagged

• 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

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

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 python-pip (bzw. python3-pip) oder über andere Methoden.

Systemweit

• aktuelle Version: sudo -H pip3 install ansible
• bestimmte-Version: sudo -H pip3 install ansible==2.8.7 ¹⁾

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.

• win_get_url doesn't follow redirects

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 = vault_tpi.yml
  vault_password_file = /etc/ansible-vault-password

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

Beispiel für globale Einstellungen:

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

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

nano (~/.nanorc):

set tabsize 2
set tabstospaces

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
       shell: "ssh-keyscan -H {{ inventory_hostname }} >> ~/.ssh/known_hosts"

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

.ansible/roles

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

• 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

https://github.com/ansible/awx

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]
...

[gruppe2]

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.

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

Software:

• Webserver
  • Apache (php-fpm ) (https://ansible-manual.readthedocs.io/en/v1.8.4-doc/apache2_module_module.html|Apache2-Module (de-)aktivieren) / Reverse-Proxy role?
  • nginx / nginx-Reverse-Proxy role?
• certbot (letsencrypt)
• docker
• gitlab
• mysql
• NTP
• Postfix
• php / phpmysql / phpmyadmin
• Samba
• kibana / logstash
• zabbix-agent / zabbix-server / zabbix-web / zabbix-proxy / zabbix-javagateway
• Nextcloud (checken):
  • https://galaxy.ansible.com/aalaesar/install_nextcloud / https://github.com/aalaesar/install_nextcloud
  • https://gitlab.com/mejo-/ansible-role-nextcloud
  • https://git.coop/webarch/nextcloud
  • https://github.com/aalaesar/install_nextcloud

Instruktur

• digitalocean
• iptables-Firewall

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

• Action Plugins
• Arbitrary host name resolution in Ansible

templates sind via jinja2 implementiert, siehe Dokumentation.

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
    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
    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
      command: uname -a
      register: myoutput
 
    - name: show output (alle attributes)
      debug:
        msg: "{{ myoutput }}"
 
    - name: show standard output (stdout multiline)
      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)
      debug:
        msg: "{{ myoutput.stderr_lines }}"
      when: myoutput.stderr_lines is defined and myoutput.stderr_lines != '' and myoutput.stderr_lines != none

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

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

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

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.
  service:
    name: "{{ ntp_daemon }}"
    state: started
    enabled: yes
  when: ntp_enabled

die letzte Zeile sollte verändert werden in „when: ntp_enabled|bool“.

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 }}"