Ansible: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
(10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 9: | Zeile 9: | ||
* Installation eines Minimalsystems | * Installation eines Minimalsystems | ||
− | * Einrichten eines Benutzers speziell für | + | * Einrichten eines Benutzers speziell für Ansible (Beispiel, das bereits Ansible nutzt, siehe unten) |
* Installation der Pakete | * Installation der Pakete | ||
** openssh-server | ** openssh-server | ||
Zeile 30: | Zeile 30: | ||
vars: | vars: | ||
ansible_python_interpreter: /usr/bin/python3 | ansible_python_interpreter: /usr/bin/python3 | ||
+ | |||
+ | ==== Einrichten eines Ansible-Benutzers ==== | ||
+ | |||
+ | Das folgende Skript <code>setupAnsible.yaml</code> geht davon aus, dass auf dem Zielrechner ein frisches [[Ubuntu]] 18.04 installiert ist, auf das man sich mit [[SSH]] als normaler Nutzer einwählen kann. Dieser Nutzer ist auch in der sudo-Gruppe und kann mittels Eingabe eines sudo-Passworts root-Rechte bekommen. | ||
+ | |||
+ | <pre> | ||
+ | # Call this file with | ||
+ | # ansible-playbook -l YOURRECHNER -K -v setupAnsible.yaml | ||
+ | |||
+ | - hosts: | ||
+ | - all | ||
+ | |||
+ | tasks: | ||
+ | - name: create group ansible | ||
+ | become: true | ||
+ | group: | ||
+ | name: ansible | ||
+ | gid: 425 | ||
+ | |||
+ | - name: create user ansible | ||
+ | become: true | ||
+ | user: | ||
+ | name: ansible | ||
+ | group: ansible | ||
+ | uid: 425 | ||
+ | password: "$6$rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXh." | ||
+ | # encrypted password created with | ||
+ | # mkpasswd --method=sha-512 | ||
+ | # You can make it really complicated, since you do not need it again. | ||
+ | state: present | ||
+ | |||
+ | - name: add user ansible to sudoers with no passwd | ||
+ | become: true | ||
+ | copy: | ||
+ | src: etc/sudoers.d/ansible | ||
+ | dest: /etc/sudoers.d/ansible | ||
+ | mode: "0440" | ||
+ | validate: "visudo -cf %s" | ||
+ | |||
+ | - name: set my authorized key for user ansible | ||
+ | become: true | ||
+ | authorized_key: | ||
+ | key: "{{ lookup('file', lookup('env','HOME') + '/.ssh/id_rsa.pub') }}" | ||
+ | user: ansible | ||
+ | state: present | ||
+ | </pre> | ||
+ | |||
+ | Nach Ausführung dieses Playbooks mittels | ||
+ | ansible-playbook -i inventory.yaml -l YOURRECHNER -K -v setupAnsible.yaml | ||
+ | |||
+ | wird der Nutzer <code>ansible</code> in die <code>inventory.yaml</code> als Standard-Ansible-Nutzer eingetragen: | ||
+ | all: | ||
+ | hosts: | ||
+ | blacky: | ||
+ | ansible_host: blacky.fritz.box | ||
+ | '''ansible_ssh_user: ansible''' | ||
=== Vorbereitung des Kontrollrechners === | === Vorbereitung des Kontrollrechners === | ||
Zeile 75: | 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 93: | 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 == |
Aktuelle Version vom 21. Oktober 2020, 03:34 Uhr
Ansible ist ein so genanntes Orchestrierungswerkzeug, mit dem man Computer automatisch konfigurieren kann. Dazu verwendet Ansible so genannte Playbooks.
Vorbereitung
Vorbereitung des Zielrechners
- Installation eines Minimalsystems
- Einrichten eines Benutzers speziell für Ansible (Beispiel, das bereits Ansible nutzt, siehe unten)
- Installation der Pakete
- openssh-server
- sudo
- Der ansible-Benutzer das passwortlose Ausführen erlauben (siehe Sudo)
- python3
- Verlinke python3:
sudo ln -s /usr/bin/python3 /usr/bin/python
oder - Deklarieren der entsprechenden Variable für die Rechnergruppe. Beispiel einer inventory.yaml:
- Verlinke python3:
all: hosts: blacky: ansible_host: blacky.fritz.box children: home: hosts: blacky: python3: # All hosts that only have python3 hosts: blacky: vars: ansible_python_interpreter: /usr/bin/python3
Einrichten eines Ansible-Benutzers
Das folgende Skript setupAnsible.yaml
geht davon aus, dass auf dem Zielrechner ein frisches Ubuntu 18.04 installiert ist, auf das man sich mit SSH als normaler Nutzer einwählen kann. Dieser Nutzer ist auch in der sudo-Gruppe und kann mittels Eingabe eines sudo-Passworts root-Rechte bekommen.
# Call this file with # ansible-playbook -l YOURRECHNER -K -v setupAnsible.yaml - hosts: - all tasks: - name: create group ansible become: true group: name: ansible gid: 425 - name: create user ansible become: true user: name: ansible group: ansible uid: 425 password: "$6$rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXh." # encrypted password created with # mkpasswd --method=sha-512 # You can make it really complicated, since you do not need it again. state: present - name: add user ansible to sudoers with no passwd become: true copy: src: etc/sudoers.d/ansible dest: /etc/sudoers.d/ansible mode: "0440" validate: "visudo -cf %s" - name: set my authorized key for user ansible become: true authorized_key: key: "{{ lookup('file', lookup('env','HOME') + '/.ssh/id_rsa.pub') }}" user: ansible state: present
Nach Ausführung dieses Playbooks mittels
ansible-playbook -i inventory.yaml -l YOURRECHNER -K -v setupAnsible.yaml
wird der Nutzer ansible
in die inventory.yaml
als Standard-Ansible-Nutzer eingetragen:
all: hosts: blacky: ansible_host: blacky.fritz.box ansible_ssh_user: ansible
Vorbereitung des Kontrollrechners
sudo aptitude install ansible
Nutzen von Ansible
Konfiguration
Die Konfiguration kann durch verschiedene Dateien erfolgen, z.B.:
- ansible.cfg
- ~/.ansible.cfg
Der Inhalt einer ansible.cfg könnte z.B. lauten:
[defaults] inventory=inventory.yaml
Inventory
Die Inventory-Datei wird in YAML geschrieben, z.B.:
all: hosts: blacky: ansible_host: blacky.fritz.box ansible_user: ansible
In YAML werden die Zeilen mit Leerzeichen, nicht mit Tabs eingerückt.
Siehe
Einfache Kommandos
Ping-Test
ansible all -m ping
Ausführen eines Shell-Kommandos
Mit Ansible lässt sich auch jedes beliebige Shell-Kommando ausführen:
ansible zielrechner -m command -a "whoami"
Will man das Kommando als root ausführen, setzt man --become
hinzu:
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 shell
nennen.
Debug-Hilfe
Das Modul "Debug" kann Hilfsausgaben erzeugen. Beispiel:
ansible blacky -m debug -a 'msg="{{ ansible_ssh_user }}"'
Playbooks
Mit Playbooks kann man automatisieren, welcher Rechner welchen Zustand erreichen soll.
Dazu nutzt man Tasks in Form von Modulaufrufen (deklarative Ansible-Form von Befehlen), Rechnergruppen und Rollen.
Package-Updates
Folgender Auszug aus den Tasks eines Playbooks sollte das Paket-Updaten auf einem Debian- oder Ubuntu-System ermöglichen:
- name: update and upgrade apt packages become: true apt: name: "*" state: latest install_recommends: false 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 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:
- hosts: NGINXRECHNER roles: - role: galaxy/nginxinc.nginx vars: nginx_debug_output: true nginx_install_from: os_repository
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
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: [WARNING]: Module invocation had junk after the JSON data: AttributeError("module 'platform' has no attribute 'dist'")
Daher lässt man auf dem Zielrechner (hier: TARGET
) auch Python2 laufen, indem man die inventory.yaml
ändert:
TARGET: ansible_python_interpreter: "/usr/bin/python2"
Weiterführendes
Siehe