Workshop Tag 1

.gitignore

@@ -1,3 +1,4 @@
 ansible.log
 ansible.cfg
 .vaultpass
+collections/ansible_collections

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
+
 

docs/README.md

@@ -0,0 +1,4 @@
+# Dokumentationen
+
+- [haproxy](./haproxy.md)
+

docs/haproy.md

@@ -0,0 +1,83 @@
+---
+title: haproxy Konfiguration auf Debian 13 (trixie)
+---
+# haproxy
+
+haproxy ist ein Loadbalancer.
+
+Die Grundfunktion ist die, dass es Frontend-Konfigurationen gibt, auf denen
+haproxy Anfragen per http entgegen nimmt.
+
+Den Frontend-Konfigurationen sind Backend-Konfigurationen zugeordnet, auf die
+haproxy die http-Anfragen weiterleitet.
+In den Backend-Konfigurationen können ein oder mehrere Server hinterlegt sein.
+haproxy verteilt bei mehreren Servern im Backend die Anfragen auf die Server.
+
+## Default Konfiguration
+
+Die Konfigdatei `/etc/haproxy/haproxy.cfg` enthält bereits die wichtigsten
+Standard-Einstellungen:
+
+```
+global
+	log /dev/log	local0
+	log /dev/log	local1 notice
+	chroot /var/lib/haproxy
+	stats socket /run/haproxy/admin.sock mode 660 level admin
+	stats timeout 30s
+	user haproxy
+	group haproxy
+	daemon
+
+	# Default SSL material locations
+	ca-base /etc/ssl/certs
+	crt-base /etc/ssl/private
+
+	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
+        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
+        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
+        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
+
+defaults
+	log	global
+	mode	http
+	option	httplog
+	option	dontlognull
+        timeout connect 5000
+        timeout client  50000
+        timeout server  50000
+	errorfile 400 /etc/haproxy/errors/400.http
+	errorfile 403 /etc/haproxy/errors/403.http
+	errorfile 408 /etc/haproxy/errors/408.http
+	errorfile 500 /etc/haproxy/errors/500.http
+	errorfile 502 /etc/haproxy/errors/502.http
+	errorfile 503 /etc/haproxy/errors/503.http
+	errorfile 504 /etc/haproxy/errors/504.http
+```
+
+## Einfache Loadbalancer Konfiguration
+
+```
+frontend TheFrontend
+    mode            http
+	bind			192.0.2.10:80
+	default_backend	TheBackend
+
+
+backend TheBackend
+	server			TheWebServer20 192.0.2.20:80
+	server			TheWebServer30 192.0.2.30:80
+```
+
+Das Beispiel lässt den haproxy auf der IP `192.0.2.10` auf dem Port 80 auf
+http-Anfragen lauschen.
+
+Eingehende Anfragen werden an die Server weitergereicht, die im Backend
+"TheBackend" definiert sind.
+Dort gibt es pro Server eine Zeile `server <name> <ip:port>`.
+Es sind auch noch weitere Konfigurationen pro Server möglich.
+
+haproxy liefert in der Datei `/usr/share/doc/haproxy/configuration.txt.gz` eine
+sehr unfassende Dokumentation mit.
+
+

playbooks/prepare_automation_user.yml

@@ -0,0 +1,31 @@
+---
+- name: Prepare Server for Ansible automation
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Create automation user
+      become: true
+      ansible.builtin.user:
+        name: "{{ automation_user }}"
+        home: "/home/{{ automation_user }}"
+        shell: "/bin/bash"
+        state: present
+
+    - name: Set authorized key for user ansible copying it from current user
+      ansible.posix.authorized_key:
+        user: "{{ automation_user }}"
+        state: present
+        manage_dir: true
+        key: "{{ item }}"
+      loop: "{{ automation_keys }}"
+
+    - name: Create sudo rules for automation
+      become: true
+      ansible.builtin.copy:
+        dest: "/etc/sudoers.d/{{ automation_user }}"
+        content: |
+          {{ automation_user }} ALL=(ALL) NOPASSWD: ALL
+        owner: root
+        group: root
+        mode: 0640
+