129 lines
3.1 KiB
Markdown
129 lines
3.1 KiB
Markdown
# Ansible Workshop
|
|
|
|
[[_TOC_]]
|
|
|
|
## Vorbereitung
|
|
|
|
### Beispieldateien kopieren
|
|
|
|
Check dieses Repostitory mit git aus und wechsel in das Verzeichnis
|
|
|
|
```
|
|
git remote add origin https://git.serverwg.de/fager/ansible-workshop.git
|
|
cd ansible-workshop
|
|
```
|
|
|
|
Kopiere das Beispielinventar:
|
|
|
|
```
|
|
cp -r inventory/demo inventory/myinv
|
|
```
|
|
|
|
Kopiere die Beispiel ansible.cfg:
|
|
|
|
```
|
|
cp ansible.cfg.dist ansible.cfg
|
|
```
|
|
|
|
Passe die Konfiguration an Dein Inventar an:
|
|
|
|
```
|
|
[defaults]
|
|
inventroy = ./inventory/myinv
|
|
...
|
|
```
|
|
|
|
Für die Demos werden 3 VMs benötigt. Diese müssen bereits existieren und
|
|
sind nicht Bestandteil des Workshops.
|
|
|
|
Im Beispiel-Inventar sind drei Server vorgesehen:
|
|
|
|
- server1.example.com
|
|
- server2.example.com
|
|
- server3.example.com
|
|
|
|
Die Servernamen werden an verschiedenen Stellen im Inventar verwendet und
|
|
referenziert.
|
|
|
|
Es ist daher empfehlenswert, die Servernamen zuerst so zu belassen und im
|
|
Inventar die IP der Systeme anzupassen.
|
|
|
|
Dafür öffnest Du die Dateien `inventory/myinv/host_vars/server[1-3].example.com.yml`
|
|
und passt die Host-Konfiguration an die IP Deiner VMs an:
|
|
|
|
```
|
|
---
|
|
ansible_host = 192.0.2.10
|
|
```
|
|
|
|
### Funktionstest des Inventars
|
|
|
|
Alle Befehle in diesem Workshop beziehen sich auf das Verzeichnis `ansible-workshop`.
|
|
|
|
Die Ansible-Befehle suchen im aktuellen Verzeichnis nach einer `ansible.cfg` und
|
|
verwenden diese dann als Ihre Konfiguration.
|
|
|
|
Ob das Inventar sauber eingelesen wird, lässt sich durch `ansible-inventory` testen.
|
|
|
|
```
|
|
$ ansible-inventory --graph
|
|
@all:
|
|
|--@ungrouped:
|
|
|--@loadbalancer:
|
|
| |--server1.example.com
|
|
|--@webserver:
|
|
| |--server2.example.com
|
|
| |--server3.example.com
|
|
```
|
|
|
|
Ebenso können zum Testen einmal alle Variablen für einen Host abgefragt werden.
|
|
|
|
```
|
|
$ ansible-inventory --host server1.example.com
|
|
{
|
|
"ansible_host": "192.0.2.10",
|
|
"automation_keys": [
|
|
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMj6DlLhdnhknWeC4Zz48P7pzTH6JNFUTcOaxm/8V9fa fager@t530fedo"
|
|
],
|
|
"automation_user": "ansible"
|
|
}
|
|
```
|
|
|
|
### Einrichten des ssh-keys für die Automatisierung
|
|
|
|
TBD
|
|
|
|
### Das Playbooks Verzeichnis
|
|
|
|
Im Playbooks-Verzeichnis werden alle Playbooks zu diesem Projekt gespeichert.
|
|
|
|
Es sind zwei Playbooks bereits als Beispiel enthalten:
|
|
|
|
- `playbooks/prepare_automation_user.yml`: Richtet den Automatisierungsuser ein
|
|
- `playbooks/ping.yml`: pingt alle Hosts im Inventar an
|
|
|
|
#### Ausrollen des Automatisierungs-Users
|
|
|
|
Wir gehen davon aus, dass auf dem Zielsystem ein ssh-Server läuft und es einen
|
|
Benutzer auf dem System gibt, der sich per sudo zu root machen kann.
|
|
|
|
Für die Automatisierung benötigen wir einen Benutzer, bei dem die Anmeldung
|
|
über einen ssh-Key möglich ist und der sich ohne sudo-Passwort root-Rechte
|
|
verschaffen kann.
|
|
|
|
Dies erledigt das Playbook `playbooks/prepare_automation_user.yml` für uns.
|
|
|
|
Das Playbook richtet den User ein, der im Inventar in der Variable
|
|
`automation_user` hinterlegt ist.
|
|
Dabei werden die ssh Public-Keys bei dem User hinterlegt, die in der Variable
|
|
`automation_keys` hinterlegt sind.
|
|
|
|
Außerdem richtet das Playbook die sudo-Rules ein, die eine passwortlose
|
|
Verwendung von sudo zulassen.
|
|
|
|
|
|
|
|
|
|
#### Anpingen aller Hosts
|
|
|
|
|