Workshop Tag 1
This commit is contained in:
parent
e9383e3eda
commit
896ed4fcb7
5 changed files with 192 additions and 2 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -1,3 +1,4 @@
|
|||
ansible.log
|
||||
ansible.cfg
|
||||
.vaultpass
|
||||
collections/ansible_collections
|
||||
|
|
|
|||
75
README.md
75
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
|
||||
|
||||
|
||||
|
|
|
|||
4
docs/README.md
Normal file
4
docs/README.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# Dokumentationen
|
||||
|
||||
- [haproxy](./haproxy.md)
|
||||
|
||||
83
docs/haproy.md
Normal file
83
docs/haproy.md
Normal file
|
|
@ -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.
|
||||
|
||||
|
||||
31
playbooks/prepare_automation_user.yml
Normal file
31
playbooks/prepare_automation_user.yml
Normal file
|
|
@ -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
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue