Ansible: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
(21 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | Ansible ist ein so genanntes Orchestrierungswerkzeug, mit dem man Computer automatisch konfigurieren kann. Dazu verwendet Ansible so genannte Playbooks. | + | [https://docs.ansible.com/ansible/latest/index.html Ansible] ist ein so genanntes Orchestrierungswerkzeug, mit dem man Computer automatisch konfigurieren kann. Dazu verwendet Ansible so genannte Playbooks. |
− | |||
− | |||
== Vorbereitung == | == Vorbereitung == | ||
Zeile 11: | Zeile 9: | ||
* Installation eines Minimalsystems | * Installation eines Minimalsystems | ||
+ | * Einrichten eines Benutzers speziell für Ansible (Beispiel, das bereits Ansible nutzt, siehe unten) | ||
* Installation der Pakete | * Installation der Pakete | ||
** openssh-server | ** openssh-server | ||
** sudo | ** sudo | ||
− | *** Der | + | *** Der ansible-Benutzer das passwortlose Ausführen erlauben (siehe [[Sudo]]) |
** python3 | ** python3 | ||
− | *** Verlinke python3: | + | *** Verlinke python3: <code>sudo ln -s /usr/bin/python3 /usr/bin/python</code> oder |
− | + | *** Deklarieren der entsprechenden Variable für die Rechnergruppe. Beispiel einer inventory.yaml: | |
+ | 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 <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 43: | Zeile 111: | ||
blacky: | blacky: | ||
ansible_host: blacky.fritz.box | ansible_host: blacky.fritz.box | ||
+ | ansible_user: ansible | ||
In YAML werden die Zeilen mit Leerzeichen, nicht mit Tabs eingerückt. | In YAML werden die Zeilen mit Leerzeichen, nicht mit Tabs eingerückt. | ||
+ | Siehe | ||
+ | * https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html | ||
+ | |||
+ | === 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 <code>--become</code> 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 <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 === | ||
+ | |||
+ | 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 [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 == | ||
+ | Siehe | ||
+ | * [https://www.informatik-aktuell.de/entwicklung/programmiersprachen/einfuehrung-in-ansible.html Einführung in Ansible] | ||
+ | * [https://www.grund-wissen.de/linux/shell/ansible.html Aktualisieren von Knoten mit Hilfe von Ansible] | ||
------- | ------- | ||
[[Category:Linux]] | [[Category:Linux]] |
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