diff --git a/.gitignore b/.gitignore index 7a6cb57..fb139c4 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ ansible.log ansible.cfg .vaultpass +collections/ansible_collections diff --git a/README.md b/README.md index a7c4019..65f2f92 100644 --- a/README.md +++ b/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 ./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=` 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 + diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 0000000..4fe1175 --- /dev/null +++ b/docs/README.md @@ -0,0 +1,4 @@ +# Dokumentationen + +- [haproxy](./haproxy.md) + diff --git a/docs/haproy.md b/docs/haproy.md new file mode 100644 index 0000000..a78cc9d --- /dev/null +++ b/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 `. +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. + + diff --git a/playbooks/prepare_automation_user.yml b/playbooks/prepare_automation_user.yml new file mode 100644 index 0000000..f1c0a14 --- /dev/null +++ b/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 +