1. Vorbereitung der Lernumgebung (Ansible)¶
1.1. Einleitung: Der Sinn der Automatisierung¶
In diesem Modul bauen wir eine Infrastruktur als Code (IaC) auf. Anstatt jeden Server einzeln zu konfigurieren (was bei 100 Servern unmöglich wäre), schreiben wir ein “Rezept” (das Playbook).
Was passiert im Hintergrund?
Wenn Sie den Befehl ansible-playbook ausführen, wird Ihr Admin-PC zur Kommandozentrale. Er loggt sich auf allen Servern gleichzeitig ein, installiert Programme und kopiert Dateien. Das Ziel ist eine standardisierte Lernumgebung, in der jeder Server exakt die gleiche Softwarebasis hat.
Note
Was ist Ansible?
Ein Werkzeug, das Befehle für Sie automatisiert. Anstatt 10-mal apt install docker auf verschiedenen Servern zu tippen, sagen Sie Ansible einmal: “Sorge dafür, dass Docker überall installiert ist.”
1.2. Ziele¶
Konnektivität: Eine sichere “Vertrauensstellung” (SSH) zwischen Admin-PC und Servern aufbauen.
Provisionierung: Automatische Installation von Docker, Git und Webdiensten.
Entwicklung: Einrichten der PyCharm IDE für spätere Python-Projekte.
1.3. 1. Das Fundament: SSH-Key-Authentifizierung¶
Warum machen wir das? Ansible muss sich hunderte Male auf Servern einloggen. Würden wir Passwörter nutzen, müssten wir diese ständig tippen oder unsicher im Klartext speichern. SSH-Keys funktionieren wie ein digitaler Ausweis: Der Server erkennt Ihren Admin-PC automatisch wieder.
Schritte:
Öffnen Sie das Kali-Terminal via WSL:
wsl
Erstellen Sie Ihr digitales Schlüsselpaar:
ssh-keygen -t ed25519
Verteilen Sie Ihre “Visitenkarte” (Public Key) an die Server: (Dies erlaubt Ihrem Admin-PC den Zugriff ohne Passwort-Abfrage.)
ssh-copy-id vmadmin@192.168.110.10 ssh-copy-id vmadmin@192.168.110.11 ssh-copy-id vmadmin@192.168.110.12
1.4. 2. Die Schaltzentrale: Ansible Konfiguration¶
Wir erstellen nun die Baupläne für unsere Infrastruktur.
1.4.1. Die Bestandsaufnahme (Inventory)¶
Warum? Ansible muss wissen, wer die Zielgeräte sind und welche individuellen Daten sie haben.
Die Datei hosts.ini definiert die “Rollen”.
[nodes]
server-1 ansible_host=192.168.110.10 git_repo_url=https://github.com/GIBB-PSA/server-1.git
server-2 ansible_host=192.168.110.11 git_repo_url=https://github.com/GIBB-PSA/server-2.git
server-3 ansible_host=192.168.110.12 git_repo_url=https://github.com/GIBB-PSA/server-3.git
[nodes:vars]
ansible_user=vmadmin
Note
Der Sinn der Variablen: Mit git_repo_url geben wir jedem Server ein individuelles Paket mit (z.B. bekommt Server-1 den Python-MQTT-Agenten, während Server-3 vielleicht eine Datenbank bekommt).
1.4.2. Das Playbook (Das Rezept)¶
Warum? Hier definieren wir den “Soll-Zustand”. Es ist egal, wie der Server aktuell aussieht – nach dem Playbook wird er genau so konfiguriert sein, wie hier beschrieben.
- name: Setup GIBB-PSA Lernumgebung
hosts: nodes
become: yes # Führt Befehle als Administrator (root) aus
tasks:
- name: Software-Basis installieren
# Installiert Docker für Container und Git für den Code-Abruf
apt:
name: [git, docker.io, docker-compose]
state: present
update_cache: yes
- name: Projekt-Ordner vorbereiten
file:
path: /opt/gibb_project
state: directory
owner: vmadmin
- name: Code von GitHub beziehen
# Nutzt die Variable aus der hosts.ini, um den richtigen Code zu laden
git:
repo: "{{ git_repo_url }}"
dest: /opt/gibb_project
- name: Docker-Webserver starten
# Startet einen Nginx-Container, damit der Server über den Browser erreichbar ist
shell: "docker-compose up -d"
args:
chdir: /opt/gibb_project
1.5. 3. Ausführung: Die Automatisierung zünden¶
Jetzt führen wir alles zusammen.
Der Ping-Test: Prüfen, ob die “Leitungen” (SSH) stehen.
ansible nodes -m ping -i hosts.ini
Der Rollout: Die gesamte Infrastruktur auf einmal aufbauen.
ansible-playbook -i hosts.ini setup_env.yml
Was ist das Ergebnis? Nach dem Durchlauf sind alle Server provisioniert. Auf Server-1 läuft nun Ihr Python-Agent, auf Server-3 vielleicht eine Sicherheits-App (DVWA). Sie haben eine funktionierende Netzwerk-Umgebung geschaffen, ohne einen einzigen Server manuell konfigurieren zu müssen.