Die Hybrid-Cloud-Serie für dein Homelab bietet eine umfassende Anleitung zur Einrichtung einer sicheren, flexiblen und skalierbaren Homelab-Umgebung. Jeder Beitrag behandelt einen spezifischen Schritt, von der Hardware-Auswahl über Automatisierung und Containerisierung bis hin zu Bereitstellung von Applikationen wie Nextcloud oder Home-Assistant.

1. Hybrid Cloud: Die ideale Kombination aus Flexibilität, Sicherheit und Skalierbarkeit für dein Homelab
2. Ansible in der Hybrid-Cloud: Der Weg zur effizienten Automatisierung
3. Containerisierung mit Docker: Die ideale Grundlage für dein Homelab
4. Caddy als Reverse Proxy: Sichere deine Hybrid-Cloud
5. Authentik in der Hybrid-Cloud: Zentrale Authentifizierung leicht gemacht
6. Sicherer Zugriff auf deine Hybrid-Cloud: Alles über SSH-Tunneling

Caddy als Reverse Proxy: Sichere deine Hybrid-Cloud

Caddy ist ein moderner, plattformübergreifender Webserver, der sich durch seine einfache Konfiguration und automatische HTTPS-Verwaltung auszeichnet. Er wurde entwickelt, um die Bereitstellung und Verwaltung von Webanwendungen effizienter und sicherer zu gestalten. Besonders hervorzuheben ist die automatische TLS-Konfiguration, die es ermöglicht, Websites standardmäßig mit HTTPS zu betreiben, ohne dass manuelle Eingriffe erforderlich sind.

In diesem Beitrag, der Teil einer größeren Blogreihe über den Aufbau einer Hybrid-Cloud ist, geht es um die Nutzung von Caddy als Reverse Proxy. Diese Beitragsreihe behandelt die wesentlichen Bestandteile einer hybriden Umgebung, in der Dienste sowohl sicher zuhause auf dem eigenen Server als auch in der Cloud gehostet werden. Caddy spielt dabei eine zentrale Rolle, da es als Reverse Proxy für Dienste auf dem Cloud-Host und im Homelab dient.

Im letzten Beitrag haben wir die Containisierung von Anwendungen mit Docker behandelt und ein “Hello World”-Projekt erfolgreich bereitgestellt. Nun wollen wir dieses Wissen nutzen, um mittels Docker und Ansible den Caddy-Webserver als Dienst zu implementieren. Dabei wird Caddy als Container betrieben und in unsere hybride Umgebung integriert.

Herausforderungen einer Hybrid-Cloud

Eine Hybrid-Cloud bietet die perfekte Kombination aus Sicherheit und Flexibilität, indem sie Dienste sowohl lokal im eigenen Homelab als auch in der Cloud hostet. Dennoch bringt diese Architektur spezifische Herausforderungen mit sich:

• Komplexität der Konfiguration: Die Einrichtung eines Reverse Proxies kann mühsam und fehleranfällig sein, insbesondere wenn regelmäßig neue Dienste hinzugefügt oder alte entfernt werden. Jedes Mal die Proxy-Regeln anzupassen, erfordert Zeit und birgt die Gefahr von Konfigurationsfehlern.
• Sicherheitsrisiken: Unsichere Verbindungen können sensible Daten gefährden, was besonders in hybriden Umgebungen mit unterschiedlichen Sicherheitsanforderungen ein Problem darstellt.
• Verwaltung von Zertifikaten: Manuelle Updates von TLS-Zertifikaten sind nicht nur zeitaufwendig, sondern auch fehleranfällig. Abgelaufene Zertifikate können Dienste unzugänglich machen und das Vertrauen der Nutzer beeinträchtigen.
• Integration von Diensten: Lokale und cloudbasierte Anwendungen müssen nahtlos miteinander kommunizieren können, was eine konsistente und zentrale Verwaltung von Zugriffsregeln erfordert.

Die dynamische Natur von Hybrid-Cloud-Umgebungen, in denen sich die Anforderungen ständig ändern, verstärkt diese Herausforderungen. Hier kommt Caddy ins Spiel: ein moderner, plattformübergreifender Webserver, der für seine einfache Einrichtung und automatische HTTPS-Verwaltung bekannt ist. Mit Caddy können Änderungen flexibel umgesetzt werden, ohne den gesamten Konfigurationsprozess jedes Mal neu durchlaufen zu müssen.

Warum Caddy ideal für die Hybrid-Cloud ist

Caddy ist mehr als nur ein Webserver – er bietet eine ganzheitliche Lösung für die Herausforderungen moderner Hybrid-Cloud-Umgebungen. Seine Funktionen gehen über die eines klassischen Webservers hinaus und machen ihn zur optimalen Wahl für komplexe Szenarien, in denen lokale und cloudbasierte Dienste effizient und sicher integriert werden müssen. Hier sind die zentralen Merkmale, die Caddy ideal für die Hybrid-Cloud machen:

Automatische HTTPS-Unterstützung

Die automatische Erstellung und Verwaltung von TLS-Zertifikaten ist ein Alleinstellungsmerkmal von Caddy. Durch die Integration mit Let’s Encrypt erfolgt die Konfiguration und Erneuerung vollkommen automatisiert, ohne manuellen Eingriff. Dies garantiert eine sichere Kommunikation – sowohl für interne Verbindungen im Homelab als auch für externe Zugriffe in der Cloud.

Plattformübergreifende Kompatibilität

Caddy ist auf nahezu allen Plattformen lauffähig, darunter Linux, Windows und macOS. Diese Vielseitigkeit erleichtert die Integration in heterogene Umgebungen und stellt sicher, dass der Webserver unabhängig von der Infrastruktur zuverlässig arbeitet.

Intuitive Konfiguration

Mit der einfachen und klar strukturierten Caddyfile können komplexe Setups in wenigen Zeilen definiert werden. Dies reduziert die Einstiegshürde und minimiert den Zeitaufwand, selbst für Anwender mit begrenzten Vorkenntnissen im Bereich Webserver.

Erweiterbarkeit und Plugins

Caddy’s modularer Aufbau ermöglicht die individuelle Anpassung an spezifische Anforderungen. Über eine Vielzahl von Plugins können zusätzliche Funktionen wie Authentifizierung, Header-Management oder Load-Balancing nahtlos integriert werden.

Nahtlose Integration mit modernen Tools

Caddy wurde speziell entwickelt, um in containerisierten und automatisierten Umgebungen zu glänzen. Es lässt sich problemlos in Docker, Kubernetes oder Ansible-Workflows einfügen und macht die Verwaltung von Diensten in einer Hybrid-Cloud effizienter.

Effizienz und Skalierbarkeit

Dank seiner leichten Architektur und der optimierten Ressourcenverwaltung ist Caddy nicht nur performant, sondern auch hoch skalierbar. Es eignet sich sowohl für kleine Homelab-Installationen als auch für umfangreiche Cloud-Deployments.

Durch diese Eigenschaften hebt sich Caddy von anderen Webservern ab und ist besonders geeignet für hybride Umgebungen, in denen lokale und cloudbasierte Dienste nahtlos miteinander verbunden werden müssen.

Vergleich mit anderen Webservern

In der Welt der Webserver gibt es viele Optionen, die sich in ihrer Funktionalität, Komplexität und Leistung unterscheiden. Apache, Nginx und Traefik zählen zu den bekanntesten Alternativen. Jede dieser Lösungen hat ihre besonderen Stärken, aber auch Schwächen, die sie für unterschiedliche Anwendungsfälle geeignet machen:

Apache

Apache ist einer der ältesten und am weitesten verbreiteten Webserver. Mit seiner modularen Architektur bietet er eine immense Flexibilität und Unterstützung für eine Vielzahl von Szenarien. Dennoch kann die Konfiguration von Apache besonders in komplexen Setups herausfordernd und zeitaufwendig sein. In Hybrid-Cloud-Umgebungen, wo sich die Anforderungen schnell ändern können, kann diese Komplexität ein Nachteil sein.

Nginx

Nginx ist bekannt für seine Geschwindigkeit und ressourcenschonende Architektur. Er wird oft bevorzugt, wenn es um die Bereitstellung statischer Inhalte oder den Einsatz als Reverse Proxy geht. Seine Konfiguration ist effizient, erfordert jedoch ebenfalls technisches Know-how, insbesondere wenn dynamische Dienste hinzugefügt oder entfernt werden. Die fehlende automatische Zertifikatsverwaltung ist ein weiterer Punkt, der in dynamischen Hybrid-Cloud-Umgebungen zu zusätzlichem Aufwand führen kann.

Traefik

Traefik ist ein moderner, speziell für containerisierte Umgebungen entwickelter Reverse Proxy. Seine Stärken liegen in der automatischen Integration mit Plattformen wie Docker oder Kubernetes. Durch die Verwendung von Labels oder Konfigurationsdateien kann Traefik Dienste dynamisch erkennen und einrichten. Dennoch ist die Einrichtung von Traefik nicht immer intuitiv und kann bei steigender Komplexität der Infrastruktur aufwendig werden.

Warum Caddy?

Im Vergleich zu diesen Webservern zeichnet sich Caddy durch eine einzigartige Kombination von Benutzerfreundlichkeit und moderner Technologie aus. Seine Fähigkeit, dynamische Änderungen einfach und effizient zu handhaben, macht ihn besonders für hybride Umgebungen attraktiv, in denen Dienste häufig hinzugefügt oder entfernt werden. Durch die automatische Verwaltung von HTTPS und die intuitive Caddyfile reduziert Caddy den administrativen Aufwand erheblich. Während Apache, Nginx und Traefik in bestimmten Nischen exzellent sind, bietet Caddy eine vielseitige und skalierbare Lösung für die dynamischen Anforderungen einer Hybrid-Cloud.

Caddy Grundlagen: Allgemeine Übersicht

Caddy ist ein moderner, plattformübergreifender Webserver, der für seine Benutzerfreundlichkeit, automatische HTTPS-Verwaltung und flexible Konfiguration bekannt ist. Er wurde entwickelt, um die Bereitstellung und Verwaltung von Webanwendungen zu vereinfachen und eine robuste Grundlage für Webservices zu schaffen. Das Herzstück von Caddy ist die sogenannte Caddyfile, eine intuitive Konfigurationsdatei, die sowohl Einsteigern als auch erfahrenen Administratoren eine klare und logische Struktur bietet.

Überblick zur Caddyfile

Die Caddyfile ist das zentrale Werkzeug zur Konfiguration von Caddy. Mit ihrer deklarativen Syntax ermöglicht sie die einfache Definition von Servereinstellungen und Funktionen. Im Vergleich zu komplexen Konfigurationsansätzen anderer Webserver bleibt die Caddyfile übersichtlich und effizient. Jede Konfiguration beginnt mit der Angabe einer Domain oder IP-Adresse, gefolgt von spezifischen Anweisungen, die in Blöcken organisiert sind.

Grundlegendes Beispiel

Mit nur einer einzigen Datei, der Caddyfile, kann der Server bereits in Betrieb genommen werden. Folgendes Beispiel demonstriert, wie mit minimalem Konfigurationsaufwand eine statische Webseite bereitgestellt wird:

1
2
3
4

example.com {
    root * /var/www/html
    file_server
}

In dieser Konfiguration wird der Inhalt aus dem Verzeichnis /var/www/html geladen und über die Domain example.com ausgeliefert. Die Direktive file_server aktiviert die Bereitstellung statischer Dateien.

Struktur der Caddyfile

Die Caddyfile ist in Blöcke unterteilt, die jeweils eine Domain repräsentieren. Jeder Block enthält spezifische Direktiven, die den Betrieb der Domain steuern und an die jeweiligen Anforderungen angepasst werden können:

1. Domänenangabe: Definiert, unter welcher Domain oder IP-Adresse der Dienst erreichbar ist.
2. Anweisungen im Block: Hier werden spezifische Funktionen und Einstellungen wie root, reverse_proxy oder tls festgelegt.
3. Globale Parameter: Übergreifende Einstellungen können am Anfang der Caddyfile definiert werden, um alle Blöcke zu beeinflussen.

Globale Parameter bieten eine Möglichkeit, wiederkehrende Einstellungen zentral zu verwalten, was die Konfiguration vereinfacht und konsistent hält. Sie sind besonders nützlich, wenn mehrere Blöcke ähnliche Anforderungen haben. Zum Beispiel:

1
2
3
4
5
6
7
8
9

{
    debug
    admin off
}

example.com {
    root * /var/www/html
    file_server
}

Im obigen Beispiel aktiviert der Debug-Modus detaillierte Fehler- und Statusausgaben, die bei der Fehlersuche hilfreich sein können. Gleichzeitig wird das Admin-Interface deaktiviert, was die Angriffsfläche reduziert und in sicherheitskritischen Szenarien vorteilhaft ist. Globale Parameter wie diese sorgen dafür, dass solche Einstellungen nur einmal definiert werden müssen, anstatt sie in jedem Block wiederholen zu müssen.

TLS-Verwaltung in Caddy

Eine der herausragenden Funktionen von Caddy ist die automatische Verwaltung von TLS-Zertifikaten. Mithilfe von Let’s Encrypt stellt Caddy sicher, dass alle Verbindungen sicher verschlüsselt sind. Dabei wird der ACME (Automatic Certificate Management Environment)-Modus verwendet, der standardmäßig die HTTP-01-Challenge zur Verifizierung der Domain einsetzt. Alternativ kann auch die DNS-01-Challenge konfiguriert werden, die speziell für Wildcard-Zertifikate geeignet ist.

Grundlegende TLS-Konfiguration und Verifizierungsmethoden

Caddy ermöglicht mit minimalem Aufwand die sichere Bereitstellung von Websites durch automatische TLS-Verwaltung. Eine einfache Konfiguration könnte so aussehen:

1
2
3

example.com {
    tls email@example.com
}

Hier wird ein TLS-Zertifikat für example.com automatisch über Let’s Encrypt beantragt und regelmäßig erneuert. Dabei nutzt Caddy standardmäßig die HTTP-01-Challenge zur Verifizierung. In dieser Methode erstellt Caddy eine spezielle Datei, die unter einer bekannten URL bereitgestellt wird. Let’s Encrypt greift darauf zu, um zu prüfen, ob der Server die Kontrolle über die Domain hat.

Alternativ können auch benutzerdefinierte Zertifikate verwendet werden:

1
2
3

secure.example.com {
    tls /path/to/cert.pem /path/to/key.pem
}

DNS-01-Challenge

Für Wildcard-Zertifikate oder Szenarien, in denen die HTTP-01-Challenge nicht möglich ist, kann die DNS-01-Challenge verwendet werden. Hierbei wird ein spezifischer TXT-DNS-Eintrag erstellt, den Let’s Encrypt zur Verifizierung abfragt. Beispiel:

1
2
3
4
5
6

*.example.com {
    tls {
        dns cloudflare
    }
    reverse_proxy localhost:8080
}

In diesem Beispiel wird die DNS-Verifizierung über den Cloudflare-Provider durchgeführt. Dafür müssen die API-Zugangsdaten für den DNS-Anbieter in der Caddy-Umgebung verfügbar sein.

Erweiterte TLS-Einstellungen und Parameter

Für spezifische Sicherheitsanforderungen bietet Caddy die Möglichkeit, die TLS-Parameter detailliert anzupassen. Dies ermöglicht eine feingranulare Kontrolle über die Sicherheit und Leistung der Verbindungen.

1. protocols:

   • Dieser Parameter legt die unterstützten TLS-Versionen fest.
   • Im obigen Beispiel sind tls1.2 und tls1.3 aktiviert. TLS 1.3 bietet modernste Sicherheitsfunktionen und schnellere Verbindungen, während TLS 1.2 für ältere Clients genutzt wird.

2. cipher_suites:

   • Bestimmt die Verschlüsselungsalgorithmen, die für die Verbindung verwendet werden.
   • Im Beispiel sind nur starke und moderne Algorithmen wie TLS_AES_128_GCM_SHA256 und TLS_AES_256_GCM_SHA384 zugelassen, um höchste Sicherheitsstandards zu erfüllen.

Beispiel für eine vollständige Konfiguration:

1
2
3
4
5
6

secure.example.com {
    tls {
        protocols tls1.2 tls1.3
        cipher_suites TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
    }
}

Mit dieser Konfiguration wird sichergestellt, dass nur die sichersten Protokolle und Verschlüsselungssuiten verwendet werden, was insbesondere in sicherheitskritischen Umgebungen von Bedeutung ist.

Automatische Erneuerung von Zertifikaten

Caddy überprüft regelmäßig die Gültigkeit der installierten TLS-Zertifikate. Sobald ein Zertifikat kurz vor dem Ablauf steht, initiiert Caddy automatisch eine Erneuerung über das ACME-Protokoll (Automatic Certificate Management Environment). Dabei führt Caddy erneut die benötigte Verifizierung durch, entweder über die HTTP-01- oder DNS-01-Challenge, und erhält so ein neues Zertifikat. Dieser Prozess läuft vollständig im Hintergrund ab und erfordert lediglich eine aktive Internetverbindung sowie die ursprünglichen Konfigurationsparameter.

Reverse Proxy-Konfiguration

Caddy ist ein leistungsstarker Reverse Proxy, der Anfragen von einer Domain oder IP-Adresse an einen oder mehrere Backend-Server weiterleiten kann. Dies ist besonders nützlich in einer Hybrid-Cloud-Umgebung, in der lokale Dienste und Cloud-basierte Anwendungen über einen zentralen Zugangspunkt integriert werden müssen. Caddy ermöglicht eine effiziente Verwaltung solcher Umgebungen, verbessert die Sicherheit durch Verschlüsselung und Zugangskontrollen und steigert die Skalierbarkeit durch Funktionen wie Lastverteilung und Caching.

Einfaches Reverse Proxy-Setup

Ein einfaches Setup für einen Reverse Proxy zeigt, wie Caddy in einer Hybrid-Cloud-Umgebung nahtlos lokale und Cloud-basierte Dienste verbinden kann:

1
2
3

app.example.com {
    reverse_proxy localhost:8080
}

Hier leitet Caddy alle Anfragen an den lokalen Server weiter, der auf Port 8080 läuft.

Header-Manipulation

Caddy ermöglicht das Hinzufügen, Entfernen oder Bearbeiten von HTTP-Headern. Dies ist besonders nützlich, um Sicherheitsrichtlinien durchzusetzen oder spezifische Anforderungen von Anwendungen zu erfüllen:

1
2
3
4
5
6
7
8

example.com {
    reverse_proxy localhost:8080
    header {
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    }
}

• X-Content-Type-Options verhindert die Interpretation von Inhalten mit einem falschen MIME-Typ.
• X-Frame-Options schützt vor Clickjacking-Angriffen.
• Strict-Transport-Security fordert Clients auf, ausschließlich HTTPS zu verwenden.

Zeitüberschreitungen und maximale Verbindungen

Um die Stabilität des Servers zu gewährleisten, können Zeitüberschreitungen und die maximale Anzahl gleichzeitiger Verbindungen konfiguriert werden:

1
2
3
4
5
6
7
8
9

example.com {
    reverse_proxy localhost:8080 {
        transport http {
            read_timeout 30s
            write_timeout 30s
            max_connections 100
        }
    }
}

• read_timeout: Maximale Zeit, die Caddy wartet, um Daten vom Backend zu lesen.
• write_timeout: Maximale Zeit, die Caddy benötigt, um Daten an das Backend zu senden.
• max_connections: Maximale Anzahl gleichzeitiger Verbindungen zum Backend.

IP-Adressfilterung

Mit IP-Adressfilterung kannst du den Zugriff auf bestimmte Dienste einschränken. Dies ist besonders hilfreich in Umgebungen, die eine hohe Sicherheit erfordern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

example.com {
    reverse_proxy localhost:8080
    @allowed_ips {
        remote_ip 192.168.1.0/24 203.0.113.5
    }
    handle @allowed_ips {
        reverse_proxy localhost:8080
    }
    respond "Zugriff verweigert" 403
}

In diesem Beispiel haben nur bestimmte IP-Adressen Zugriff auf den Dienst, während alle anderen Anfragen mit einem 403-Fehler beantwortet werden.

Caddy einrichten: Hybrid-Cloud Setup mit Ansible und Docker

Nachdem wir uns in den vorherigen Abschnitten mit den Grundlagen von Caddy vertraut gemacht haben, widmen wir uns nun der Implementierung des Caddy-Dienstes in unserer Hybrid-Cloud. Ziel ist es, Caddy als Reverse Proxy einzurichten und mit Ansible sowie Docker Compose bereitzustellen.

Struktur der Caddy-Rolle

Wir erstellen eine eigene Rolle für Caddy, die folgende Struktur besitzt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

roles/
└── caddy/
    ├── defaults/
    │   └── main.yml
    ├── files/
    │   ├── config/
    │   ├── data/
    │   ├── etc/
    │   └── docker-compose.yml
    ├── handlers/
    │   └── main.yml
    ├── meta/
    │   └── main.yml
    └── tasks/
        └── main.yml

Diese Struktur entspricht dem Ansible-Standard und soll dem Leser das Folgende erleichtern: In den nächsten Abschnitten werden wir auf die Inhalte der Dateien für die Rolle eingehen und erläutern, wie sie für die Einrichtung von Caddy verwendet werden.

Variablen und Defaults der Rolle

Die Variablen der Rolle werden in der Datei defaults/main.yml definiert:

1
2

caddy_directory: "{{ services_directory }}/caddy"
caddy_file: "{{ caddy_directory }}/etc/Caddyfile"

• caddy_directory: Definiert das Hauptverzeichnis für den Caddy-Dienst.
• caddy_file: Gibt den Pfad zur Hauptkonfigurationsdatei für Caddy an.

Die Variable services_directory sollte bereits aus dem letzten Beitrag bekannt sein und gibt das übergeordnete Verzeichnis für alle Dienste vor.

Docker Compose und Konfiguration

Die Datei files/docker-compose.yml enthält die Definition des Caddy-Containers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

services:
  caddy:
    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
    user: "${UID}:${GID}"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./etc:/etc/caddy/
      - ./data:/data
      - ./config:/config
    environment:
      - CADDY_TELEMETRY=off
    networks:
      - external_services
      - internal_services

networks:
  external_services:
  internal_services:
    name: internal_services
    internal: true

Dabei verwenden wir das vom Caddy-Entwickler bereitgestellte offizielle Docker-Image, welches bereits optimal konfiguriert ist und eine einfache Bereitstellung ermöglicht.

• Ports: Die Ports 80 (HTTP) und 443 (HTTPS) werden freigegeben, um externe Anfragen an Caddy weiterzuleiten.
• Volumes: Die Verzeichnisse etc, data und config werden gemountet, um persistente Konfigurationen und Daten zu speichern.
• Netzwerke:
  • external_services: Dieses Netzwerk erlaubt Caddy, Anfragen von externen Clients zu empfangen. Es ermöglicht die Kommunikation zwischen dem Caddy-Container und der Außenwelt, wobei der Zugang auf die definierten Ports beschränkt bleibt.
  • internal_services: Ein vollständig isoliertes Netzwerk, das ausschließlich für die interne Kommunikation zwischen Caddy und anderen Containern vorgesehen ist. Dieses Netzwerk stellt sicher, dass Dienste wie Datenbanken oder Backend-Server nicht direkt von außen erreichbar sind. Die Isolation reduziert Sicherheitsrisiken erheblich und gewährleistet eine klare Trennung zwischen öffentlichen und privaten Diensten.

Die Verwendung von Netzwerken in Docker Compose ist essenziell, um eine sichere und effiziente Kommunikation zwischen den Containern zu gewährleisten. Während external_services den externen Zugriff ermöglicht, bleibt der Datenfluss innerhalb des internal_services-Netzwerks vollständig geschützt und auf autorisierte Dienste beschränkt.

Dynamisches Reload des Caddyfile

Um dynamische Änderungen am Caddyfile zu unterstützen, definieren wir einen Handler in handlers/main.yml:

1
2
3
4
5

- name: Reload Caddy
  community.docker.docker_compose_v2_exec:
    service: caddy
    command: caddy reload --config /etc/caddy/Caddyfile
    project_src: "{{ caddy_directory }}"

Dieser Handler ermöglicht es, den Caddy-Container bei Änderungen an der Konfiguration neu zu laden, ohne den Container komplett neu starten zu müssen. Dies wird von anderen Rollen genutzt, um Caddy über Änderungen an der Datei zu benachrichtigen und diese automatisch zu übernehmen.

Meta-Informationen der Rolle

Die Meta-Informationen der Rolle werden in der Datei meta/main.yml definiert. Diese Datei enthält Abhängigkeiten und beschreibt, welche Rollen für den ordnungsgemäßen Betrieb der Rolle benötigt werden:

1
2

dependencies:
  - role: docker

In unserem Kontext stellt die Docker-Rolle sicher, dass Docker auf dem Zielhost installiert ist. Dies ist eine grundlegende Voraussetzung, um die Caddy-Rolle erfolgreich auszuführen und sicherzustellen, dass die Container-basierte Bereitstellung reibungslos funktioniert.

Aufgaben zur Anwendung der Rolle

Die Hauptaufgaben der Rolle werden in der Datei tasks/main.yml definiert. Dabei werden zunächst die Service-Verzeichnisse erstellt und die relevanten Dateien aus dem Verzeichnis files kopiert. Dieser Schritt legt die Basis, um den Caddy-Dienst präzise zu konfigurieren und erfolgreich zu starten.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

- name: Ensure directory exists
  file:
    path: "{{ caddy_directory }}"
    state: directory
- name: Copy configuration files
  copy:
    src: files/
    dest: "{{ caddy_directory }}"
- name: Configure main
  blockinfile:  
    path: "{{ caddy_file }}"
    marker: "# {mark} CADDY MAIN CONFIG"
    create: true
    block: |
      {
             email admin@deinedomain.de
      }
      deinedomain.de, www.deinedomain.de {
             redir https://github.com
      }      
  notify:
    - Reload Caddy
- name: Deploy with Docker Compose
  community.docker.docker_compose_v2:
    project_src: "{{ caddy_directory }}"
    state: present
    remove_orphans: true
  environment:
    UID: "{{uid}}"
    GID: "{{gid}}"
- name: Publish Caddyfile path
  set_fact:
    caddy_reverse: "{{ caddy_file }}"

Anschließend erzeugen wir die Caddyfile-Konfiguration dynamisch mit dem Pfad caddy_file. Der Befehl blockinfile fügt einen Block in diese Datei ein, der mit dem in mark definierten Marker beginnt und endet. Diese Herangehensweise gewährleistet, dass Änderungen an der CADDY MAIN CONFIG konsistent bleiben, selbst wenn andere Rollen später Anpassungen vornehmen. Innerhalb dieser Konfiguration legen wir die E-Mail-Adresse für die Erstellung der SSL-Zertifikate fest und definieren die Domain, die mittels eines DNS-A-Eintrags auf die Cloud-Instanz verweist und richten eine Weiterleitung zu github.com ein.

Der zuvor definierte Reload Caddy-Handler informiert den laufenden Caddy-Dienst über die geänderte Konfiguration und sorgt dafür, dass diese ohne Neustart übernommen wird. Sollte der Dienst noch nicht gestartet sein, übernimmt das Play Deploy with Docker Compose diese Aufgabe, wie es bereits im hello-world-Beispiel gezeigt wurde.

Diese Rolle bietet eine einzigartige Funktionalität, die sie von den bisherigen und zukünftigen Rollen unterscheidet. Mit dem Play Publish Caddyfile path reverse wird ein sogenannter Fact namens caddy_reverse für den Host erstellt. Dieser Fact ermöglicht es anderen Rollen, auf den Pfad caddy_file zuzugreifen, um zusätzliche Konfigurationen für den Reverse Proxy hinzuzufügen. Dieses Feature stellt sicher, dass die Integration und Erweiterung des Caddy-Dienstes in einer Hybrid-Cloud-Umgebung nahtlos funktioniert. Im nächsten Kapitel zeigen wir, wie diese Funktionalität genutzt wird, um die Rolle für Authentik zu konfigurieren und den Fact effizient einzusetzen.

Rolle auf Hosts anwenden

Nachdem die Rolle definiert wurde, erweitern wir unser site.yml-Playbook, um Caddy nur auf Hosts der Gruppe cloud bereitzustellen:

1
2
3
4
5
6
7
8
9

- name: Apply to all hosts
  hosts: all
  roles:
    - docker
    - hello-world
- name: Apply to cloud instance
  hosts: cloud
  roles:
    - caddy

Anschließend wird das Playbook ausgeführt:

1

ansible-playbook -i inventory site.yml

Nachdem die Rolle erfolgreich angewendet wurde, kannst du auf https://deinedomain.de navigieren, um die Konfiguration zu überprüfen.

Mit der Einrichtung des Caddy-Dienstes haben wir einen zentralen Baustein für unsere Hybrid-Cloud geschaffen. Durch die Nutzung von Ansible und Docker Compose konnten wir den Prozess effizient automatisieren und eine flexible, erweiterbare Infrastruktur aufbauen. Die Besonderheit dieser Rolle, zusätzliche Konfigurationsmöglichkeiten für andere Dienste bereitzustellen, macht sie zu einem Schlüsselwerkzeug für künftige Erweiterungen. Im nächsten Kapitel werden wir diese Möglichkeiten nutzen, um Authentik als zentralen Authentifizierungsdienst in unser Setup zu integrieren.

Fazit und Ausblick

Caddy hat sich in diesem Beitrag als vielseitiger und moderner Webserver erwiesen, der speziell für die Herausforderungen hybrider Cloud-Umgebungen konzipiert ist. Mit seiner benutzerfreundlichen Caddyfile, der automatischen TLS-Verwaltung und umfangreichen Funktionen wie Header-Manipulation, Lastverteilung und Sicherheitsfilterung ist Caddy ideal, um lokale und cloudbasierte Dienste effizient und sicher zu integrieren.

Insbesondere in Homelabs oder selbst gehosteten Setups zeigt Caddy, wie einfache Konfigurationen eine leistungsstarke Infrastruktur ermöglichen können. Die Flexibilität von Caddy macht es nicht nur zu einem Werkzeug für erfahrene Administratoren, sondern auch für Einsteiger, die ihre Hybrid-Cloud umsetzen möchten.

Im nächsten Beitrag der Serie, Authentik in der Hybrid-Cloud: Zentrale Authentifizierung leicht gemacht, werden wir uns mit der Implementierung und Integration von Authentik beschäftigen. Authentik bietet eine zentrale Authentifizierungsplattform, die nahtlos mit Caddy und anderen Diensten in der Hybrid-Cloud zusammenarbeitet. Dabei zeigen wir, wie sich Benutzerzugriffe effizient verwalten und absichern lassen, ohne die Benutzerfreundlichkeit zu beeinträchtigen.

Bleiben Sie gespannt, wie sich Ihre Hybrid-Cloud weiterentwickeln kann!