Workshop Tag 1

README.md

@@ -3,6 +3,7 @@
 - [Vorbereitung](#vorbereitung)
   - [Beispieldateien kopieren](#beispieldateien-kopieren)
   - [Funktionstest des Inventars](#funktionstest-des-inventars)
+- [Workshop 1](#workshop-1)
 
 ## Vorbereitung
 
@@ -91,9 +92,11 @@ $ ansible-inventory --host server1.example.com
 }
 ```
 
-### Einrichten des ssh-keys für die Automatisierung
+### Installieren einer notwendigen Collection
 
-TBD
+```
+ansible-galaxy collection install ansible.posix
+```
 
 ### Das Playbooks Verzeichnis
 
@@ -123,9 +126,77 @@ Dabei werden die ssh Public-Keys bei dem User hinterlegt, die in der Variable
 Außerdem richtet das Playbook die sudo-Rules ein, die eine passwortlose
 Verwendung von sudo zulassen.
 
+Im Inventar ist in der Datei `group_vars/all.yml` bereits ein Beispiel-Key
+hinterlegt.
+In diese Liste werden einfach die weiteren ssh-Public Keys mit aufgenommen,
+die für die Automatisierung mit verwendet werden sollen.
 
+Der Server muss bereits über einen Zugang verfügungen, über den man sich per
+ssh verbinden und dann mit sudo root werden kann.
 
+Dies kann aber auf verschiedene Weise erfolgen.
+
+- Für die ssh-Verbindung wird ein anderer Benutzername verwendet (`-u`)
+- Für die ssh-Verbindung wird ein Passwort abgefragt (`-k`)
+- Beim Aufruf von sudo wird ein Passwort abgefragt (`-K`)
+
+Je nachdem, welche Situation vorliegt, werden dem Playbook für die
+Ersteinrichtung des automatisierungs-Users die Parameter mitgegeben:
+
+```
+ansible-playbook -k -K -u <user> ./playbooks/prepare_automation_user.yml
+```
+
+**ACHTUNG:** Wenn im Inventar bereits `ansible_user` konfiguriert ist, ist
+dies höherwertig als der `-u` schalter und es wird versucht, die Verbindung
+bereits mit dem Automatisierungsuser aufzubauen. Dies kann man überschreiben,
+indem man mit `-e ansible_user=<user>` mitgibt.
+
+Nachdem der User angelegt wurde, kann in `group_vars/all.yml` die Zeile mit
+`ansible_user` auskommentiert und der Automatisierungs-User dort eingetragen
+werden. Ansible verwendet ab jetzt grundsätzlich diesen User für die
+Verbindung.
 
 #### Anpingen aller Hosts
 
+Nachdem der Automatisierungs-User eingerichtet ist, können alle Hosts testweise
+einmal angepingt werden.
+
+```
+ansible -m ping all
+```
+
+Ansible baut dadurch die ssh-Verbindung auf und testet einmal, ob ein Python
+auf dem System vorhanden ist. Wenn das klappt, wird ein "pong" zurück gegeben.
+
+Mit einem `-b` kann man auch die Funktion des passwortlosen sudo-Aufrufs testen.
+
+Ein weiterer Test kann mit dem Command-Modul erfolgen. Mit `-a` wird das
+auszuführende Kommando mitgegeben. Mit dem `id -a` kann man sehr schön die
+Auswirkungen des `-b` beobachten. Mit `-b` sollten die Daten für root
+ausgegeben werden. Ohne das `-b` werden die Daten des Automatisierungs-Users
+ausgegeben.
+
+```
+ansible -m command -a "id -a" all
+```
+
+## Workshop 1
+
+In diesem Teil werden zwei Rollen entwickelt.
+
+- die Rolle `nginx` installiert den nginx auf den Webservern.
+- die Rolle `haproxy` konfiguriert den Proxy auf dem Loadbalancer.
+
+Aufgaben:
+
+1. Erstellt die Rolle `nginx`. Diese soll:
+  - nginx installieren
+  - ggf. den nginx starten
+  - eine index.html im DocumentRoot plazieren, die den `inventory_hostname` als Inhalt hat.
+2. Erstellt die Rolle `haproxy`. Diese soll:
+  - haproxy installieren
+  - eine Konfigdatei basierend auf einem Template generieren
+  - die Server, die in der Webserver-Gruppe sind, automatisch im Backend konfigurieren
+