Zeile 55: |
Zeile 55: |
| group: ansible | | group: ansible |
| uid: 425 | | uid: 425 |
− | password: "$6$rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXh." | + | password: "$6$rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXh." |
| # encrypted password created with | | # encrypted password created with |
| # mkpasswd --method=sha-512 | | # mkpasswd --method=sha-512 |
Zeile 131: |
Zeile 131: |
| Will man das Kommando als root ausführen, setzt man <code>--become</code> hinzu: | | Will man das Kommando als root ausführen, setzt man <code>--become</code> hinzu: |
| ansible pia2016 --become -m command -a "whoami" | | ansible pia2016 --become -m command -a "whoami" |
| + | |
| + | Das hier verwendete Modul command nutzt jedoch nicht die Shell-Erweiterungen. Dafür müsste man das Modul <code>shell</code> nennen. |
| + | |
| + | ==== Debug-Hilfe ==== |
| + | |
| + | Das Modul "Debug" kann Hilfsausgaben erzeugen. Beispiel: |
| + | ansible blacky -m debug -a <nowiki>'msg="{{ ansible_ssh_user }}"'</nowiki> |
| | | |
| === Playbooks === | | === Playbooks === |
Zeile 149: |
Zeile 156: |
| install_recommends: false | | install_recommends: false |
| update_cache: true | | update_cache: true |
| + | |
| + | === Roles === |
| + | |
| + | Roles ist ein Konzept, um bestimmte Funktionalitäten zu bündeln; diese können dann auf verschiedenen Rechnern wiederverwendet werden. |
| + | |
| + | Mit ansible-galaxy können diese Rollen auch leicht an andere Benutzer weitergegeben werden. |
| + | |
| + | ==== Nginx Ansible Role ==== |
| + | |
| + | Die offizielle Rolle für den [[Nginx]]-Server nennt sich [https://galaxy.ansible.com/nginxinc/nginx nginxinc.nginx]. Sie lässt sich folgendermaßen installieren: |
| + | |
| + | ansible-galaxy install nginxinc.nginx |
| + | |
| + | Die Rolle lässt sich dann folgendermaßen ins Playbook integrieren: |
| + | <pre> |
| + | |
| + | - hosts: NGINXRECHNER |
| + | roles: |
| + | - role: galaxy/nginxinc.nginx |
| + | vars: |
| + | nginx_debug_output: true |
| + | nginx_install_from: os_repository |
| + | </pre> |
| + | |
| + | === Ansible und Container === |
| + | |
| + | Im Zusammenspiel mit podman bietet ansible-bender eine Möglichkeit Container-Images zu erstellen und zu betreiben. |
| + | |
| + | Auch das reine Ansible bietet im Zusammenspiel mit Docker vielfältige Möglichkeiten Docker-Container-Images zu erstellen und laufen zu lassen. Siehe |
| + | * https://tech.labs.oliverwyman.com/blog/2019/08/30/docker-without-dockerfiles/ |
| + | |
| + | === Ansible und Hetzner Cloud === |
| + | Siehe |
| + | * https://www.unixwitch.de/de/sysadmin/tools/hcloud-ansible |
| + | * https://community.hetzner.com/tutorials/howto-hcloud-ansible |
| + | |
| + | == Fehlerbehebung == |
| + | |
| + | Ansible hat Probleme, wenn die kontrollierende Maschine auf Python2 und die kontrollierte auf Python3 läuft. Das äußert sich z.B. mit folgender Warnung:<cite> |
| + | [WARNING]: Module invocation had junk after the JSON data: AttributeError("module 'platform' |
| + | has no attribute 'dist'") |
| + | </cite> |
| + | |
| + | Daher lässt man auf dem Zielrechner (hier: <code>TARGET</code>) auch Python2 laufen, indem man die <code>inventory.yaml</code> ändert: |
| + | |
| + | TARGET: |
| + | ansible_python_interpreter: "/usr/bin/python2" |
| | | |
| == Weiterführendes == | | == Weiterführendes == |