Docker Compose im Heimnetzwerk: Organisation, Profile und Best Practices

Informatec Digital » Ressourcen » Docker Compose im Heimnetzwerk: Organisation, Profile und Best Practices

Der Aufbau eines modernen Heimlabors mit Containern hat sich für viele Technikbegeisterte zu einem beliebten Hobby entwickelt. Docker Compose spielt dabei fast immer eine zentrale Rolle : Dienste werden in YAML definiert, mit Git versioniert und die gesamte Umgebung mit einem einzigen Befehl gestartet.

Wenn das Unternehmen jedoch wächst, ändert sich die Situation: Aus zwei oder drei Containern werden Dutzende von Diensten, internen Netzwerken, Reverse-Proxys, Datenbanken und CI-Runnern . Dann stellt sich die entscheidende Frage: Eine einzige große Docker-Compose-Instanz oder viele kleine Dateien? Wie organisiere ich Profile, Netzwerke, Backups und Sicherheit und wie gestalte ich die Migration gleichzeitig so einfach wie möglich?

Praxisnahe Ansätze zur Einrichtung von Docker Compose in einem Heimlabor

In der Praxis arbeiten Nutzer, die Homelabs schon länger verwenden, üblicherweise mit drei verschiedenen Compose-Organisationsmodellen, von denen jedes seine eigenen Vor- und Nachteile hat. Die Wahl des richtigen Ansatzes erspart Ihnen viel Ärger beim Skalieren oder beim Umzug auf einen neuen Rechner.

Auf der einen Seite gibt es diejenigen, die mit eigenständigen Docker-Run-Befehlen begonnen, dann zu Portainer gewechselt und schließlich zu Docker Compose übergegangen sind . Das ist ein typisches Szenario: Portainer bietet hervorragende Übersichtlichkeit, eine benutzerfreundliche Oberfläche, Vorlagen usw., aber letztendlich wird das Bearbeiten komplexer Parameter oder das Migrieren von Konfigurationen mühsam, wenn man keine entsprechenden Dateien hat.

Am anderen Ende des Spektrums steht derjenige, der alles in einer einzigen "Mega"-docker-compose.yml-Datei zusammengefasst hat, die in der Lage ist, absolut alle Homelab-Dienste auszuführen: Reverse-Proxy, Medien, Hilfsprogramme, Überwachung, LLMs, Datenbanken... Alles in einem einzigen Stack.

Viele Anwender bevorzugen dazwischen einen gemischten Ansatz: mehrere kleine docker-compose.yml-Dateien, die nach Kontext gruppiert sind (z. B. Medien, Infrastruktur, Produktivität, Überwachung), alle unter demselben Repository und in der Regel mit gemeinsam genutzten globalen Umgebungsvariablen.

Eine elegante Lösung vereint beide Ansätze: eine Docker-Compose-Datei im Stammverzeichnis, die weitere Dateien einbindet (jeweils in einem Unterordner von Anwendungen oder Diensten). So behält man den Überblick über das gesamte Heimnetzwerk, ohne sich durch eine tausendzeilige, unlesbare YAML-Datei quälen zu müssen.

Profile, Gruppierung nach Funktion und große Heimlabore

Wenn Ihr Heimnetzwerk 30, 40 oder 50 Dienste umfasst (einschließlich Backup-Dienste wie Datenbanken, Caches oder Indexer), ist es unerlässlich, diese zu strukturieren. Hier kommen sowohl die Gruppierung nach Funktion als auch die Verwendung von Docker Compose-Profilen ins Spiel.

Ein sehr gängiges Vorgehen besteht darin, alles in einem einzigen Compose-„Projekt“ zusammenzufassen, dieses aber logisch nach Profilen zu unterteilen. Zum Beispiel:

• Kernprofil: Homelab-Kern, mit Traefik als Reverse-Proxy und einem Identitätsanbieter (z. B. OAuth oder Authentik) zur Authentifizierung aller Apps unter derselben Domain mit HTTPS.
• MedienprofilDienste wie Plex, Sonarr, Radarr, Ombi, SABnzbd oder qBittorrent sind für das Kuratieren, Herunterladen und Bereitstellen von Multimedia-Inhalten zuständig.
• Utilities-ProfilTools wie Portainer, Watchtower (falls verwendet), Diun, dockcheck oder ähnliche zur Verwaltung und Überwachung von Containern und Updates.
• Infrastruktur-/Überwachungsprofil: Traefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle und alles, was mit Monitoring und Logging zu tun hat.
• Experimentelle Profile oder LLM: spezielle Stacks für LLMs oder ungewöhnliche Anwendungen (ChatGPT Next Web local, LibreOffice Online usw.), die normalerweise standardmäßig deaktiviert sind.

Der Vorteil von Profilen liegt darin, dass Sie nur einen Teil der Infrastruktur nach Bedarf bereitstellen können. Beispielsweise können Sie auf einem stromsparenden Mini-PC nur das Kern- und Infrastrukturprofil ausführen und auf dem großen Server mit mehr Festplatten und GPUs nur das Medienprofil bereitstellen.

In gut strukturierten Repositories befindet sich üblicherweise eine „master“-docker-compose.yml-Datei im Stammverzeichnis, die mithilfe von `include` einzelne Dateien in einen `apps/`- oder `services/`-Ordner einbindet . Zusätzlich werden fast alle Dienste über eine einzige globale `.env`-Datei konfiguriert , und einige Geheimnisse werden in einem `secrets/`-Verzeichnis gespeichert , was die Ersteinrichtung erheblich vereinfacht.

Nach diesem Muster reduziert sich die Verwaltung des Heimnetzwerks im Wesentlichen auf das Bearbeiten der .env-Datei und der zugehörigen Geheimnisse, das Aktivieren oder Deaktivieren von Profilen und das Festlegen, welche Dienste auf den einzelnen Hosts gestartet werden sollen . Dies ist ideal, wenn Sie dieselben Anwendungen auf mehreren Rechnern bereitstellen möchten.

Eine einzige riesige Docker-Compose-Datei im Vergleich zu mehreren kleinen Dateien

Dies ist die ewige Debatte: Eine einzige docker-compose.yml-Datei, die alles enthält, oder mehrere Dateien pro Dienst/Stack? Die eigentliche Antwort lautet meist: „Es kommt darauf an, was Sie priorisieren möchten: Einfachheit der Migration oder Übersichtlichkeit pro Dienst.“

Diejenigen, die sich für eine zentrale Masterdatei aussprechen, heben typischerweise mehrere Vorteile hervor:

• Die Migration von Hosts ist kinderleichtSie klonen das Repository, kopieren die .env-Datei und die Secrets, mounten die Volumes und führen `docker compose up -d` aus. Es ist nicht nötig, jedes Verzeichnis einzeln zu bearbeiten.
• Infrastruktur als WahrheitscodeDie gesamte Topologie des Heimnetzwerks (Dienste, Netzwerke, Volumes, Abhängigkeiten) befindet sich an einem Ort.
• Zentralisierte UpdatesSie ändern eine Image-Version, eine Neustartrichtlinie oder einige Protokollierungseinstellungen und wissen genau, wo Sie ansetzen müssen.

Doch es hat auch klare Nachteile: Eine riesige YAML-Datei ist schwerer zu pflegen, Merge-Konflikte nehmen zu, und bei der Fehlersuche muss man sich durch einen Code-Wahnsinn mit Hunderten von Zeilen kämpfen. Es ist nicht ungewöhnlich, ein wenig Bedauern zu verspüren, wenn alles zu groß wird.

Der andere Ansatz besteht darin, für jede Anwendung oder jeden logischen Stack eine docker-compose.yml-Datei innerhalb einer Struktur wie dieser zu haben:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

Dadurch wird jeder Container beispielsweise mit bookstack-app-1 oder traefik-reverse-proxy-1 benannt , was Ihnen hilft, Probleme schnell zu lokalisieren: Wenn der Container bookstack-app-1 abstürzt, wissen Sie genau, in welchem ​​Ordner Sie suchen müssen.

Optisch ist es deutlich übersichtlicher und ermöglicht die unabhängige Verwaltung jedes Dienstes (Starten, Stoppen oder Aktualisieren, ohne die anderen zu beeinträchtigen). Darüber hinaus nutzen Anwendungen wie Dozzle separate Stacks, um Protokolle besser zu organisieren.

Der Nachteil besteht darin, dass bei einer zu starken Trennung der einzelnen Komponenten die Koordination zwischen gemeinsamen Diensten (wie Traefik oder gemeinsam genutzten Netzwerken) etwas mehr Sorgfalt erfordert : Man muss externe Netzwerke und spezifische Traefik-Labels deklarieren und sich die Nomenklatur der von anderen docker-compose erstellten Netzwerke merken.

Bewährte Vorgehensweisen mit .env, Überschreibungen und Versionskontrolle

Einer der am meisten unterschätzten Tricks ist die Zentralisierung der Konfiguration in .env-Dateien . Anstatt Ihre docker-compose.yml mit Umgebungsvariablen zu überfluten, definieren Sie etwa Folgendes:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Im YAML-Code werden sie dann als ${DB_USERNAME} oder ${DB_PASSWORD} referenziert . Dadurch ist Compose auf einen Blick lesbar, Variablen können zwischen mehreren Diensten geteilt werden , und – was am wichtigsten ist – Passwörter werden in einer separaten Datei gespeichert (die Sie von Git ausschließen können).

Für verschiedene Umgebungen (Produktion, Test, Entwicklung) ist die Verwendung von docker-compose.override.yml sehr hilfreich . Die Idee ist, eine Basis-docker-compose.yml-Datei zu haben und in der Überschreibung nur die Änderungen vorzunehmen: Ports, Pfade, Debug-Flags usw.

Beispielsweise können Sie während der Entwicklung eine Überschreibung laden, in der Sie einen anderen Port freigeben, das Debugging aktivieren und den lokalen Quellcode einbinden . Sie ändern dabei nicht die Haupt-YAML-Datei, sondern passen den Stack an die jeweilige Umgebung an.

Die Versionsverwaltung mit Git ist natürlich unerlässlich, wenn Ihr Heimnetzwerk auch nur annähernd professionell wirken soll . Normalerweise sieht das etwa so aus:

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

Von dort aus initialisieren Sie das Repository, übertragen die Infrastrukturänderungen und können im Fehlerfall innerhalb von Sekunden zu einer vorherigen Compose-Version zurückkehren . Für ambitionierte Heimlabore ist dies nicht nur eine Option, sondern die einzige Möglichkeit, nicht den Verstand zu verlieren.

Netzwerke, Traefik und die sichere Offenlegung von Diensten

In nahezu allen fortgeschrittenen Heimnetzwerken findet sich dieselbe Kombination: Traefik als Reverse-Proxy und ein zentraler Identitätsanbieter (Auth oder Authentik) . Dadurch können zahlreiche Anwendungen unter Subdomains mit HTTPS und SSO bereitgestellt werden.

Ein klassischer Ansatz ist die Einrichtung eines dedizierten Docker-Netzwerks, beispielsweise reverse_proxy oder eines ähnlichen Dienstes, in dem Traefik und alle extern bereitgestellten Webdienste angebunden sind. Die übrigen Container (Datenbanken, Caches usw.) verbleiben in isolierten internen Netzwerken.

Wenn Sie Traefik verwenden und Ihre Dienste in verschiedene Docker Compose-Instanzen aufteilen, müssen Sie ein gemeinsames externes Netzwerk definieren . Etwa so:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

Hier wird das Netzwerk traefik_default vom Traefik-Stack erstellt, und die anderen Dienste werden über ein externes Netzwerk namens traefik-net hinzugefügt. Labels teilen Traefik mit, welches Netzwerk für das Routing des Datenverkehrs verwendet werden soll.

Wenn ein einzelner Stack Backend-Dienste umfasst (z. B. einen Webcontainer und dessen Datenbank), können Sie diese mit einem gemeinsamen Standardnetzwerk verbinden und nur dem Webcontainer Zugriff auf das Traefik-Netzwerk gewähren . Die Datenbank erhält das Label `traefik.enable=false`, sodass Traefik sie ignoriert.

Diese Konfiguration bietet zwei entscheidende Vorteile: Isolation zwischen Diensten und kontrollierte Erreichbarkeit . Nur die Container, die Sie mit Traefik-Labels versehen und die sich im Proxy-Netzwerk befinden, sind von außen zugänglich.

Datenpersistenz, Volumes und Festplattenstruktur

Ein Heimnetzwerk ohne persistente Daten ist wenig nützlich: Datenbanken, Konfigurationen, Mediendateien, Dokumente… alles muss einen Docker Compose Down überstehen. Volumes und Bind-Mounts sind dabei überlebenswichtig.

Viele Menschen organisieren ihren Stauraum nach einem ähnlichen Schema:

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

Die Idee ist, dass Downloader (qBittorrent, SABnzbd usw.) nur den Download-Ordner sehen , Manager wie Radarr/Sonarr Zugriff auf Downloads und Medien haben (um Hardlinks zu verschieben/zu erstellen), und Server wie Plex oder Jellyfin nur den Medienordner sehen.

Dadurch wird das Prinzip der minimalen Berechtigungen angewendet : Jeder Container greift nur auf das zu, was er tatsächlich benötigt. Die klare Trennung erleichtert zudem die Entscheidung, welche Volumes oder Pfade in der Cloud oder auf externen Laufwerken gesichert werden sollen.

Das srv-Verzeichnis dient typischerweise zur Speicherung von Anwendungskonfigurationen (z. B. /srv/jellyfin/config, /srv/traefik, /srv/paperless usw.). Es ist üblicherweise teilweise versioniert (Vorlagen, Caddyfile usw.), wobei kritische oder ressourcenintensive Elemente ausgelassen werden.

In manchen Fällen ist es sinnvoll, Hardlinks in der Downloadkette zu verwenden: Dienste wie Radarr oder Sonarr können heruntergeladene Dateien verlinken, um das Seeding aufrechtzuerhalten, ohne Speicherplatz zu duplizieren. Die von Anleitungen wie TRaSHGuides vorgeschlagene Verzeichnisstruktur basiert genau auf diesem Prinzip.

Automatisierte Bereitstellungen mit GitHub Actions und lokalen Runnern

Wer noch einen Schritt weiter gehen möchte, kann Heimnetzwerk-Updates mit CI/CD automatisieren . Einige Nutzer haben Jenkins und ähnliche Tools durch einen Workflow ersetzt, der GitHub Actions und einen selbst im Heimnetzwerk gehosteten Runner verwendet.

Der Mechanismus ist einfach: Jedes Mal, wenn Sie Änderungen in den Hauptzweig Ihres Heimlabor-Repositorys pushen, wird ein GitHub Actions-Workflow gestartet, der Tests und Linter ausführt und, wenn alles gut geht, die Änderungen auf dem Server bereitstellt.

Ein typischer Arbeitsablauf umfasst unter anderem folgende Schritte:

• Geheimscanner vom Typ Gitleaks: für den Fall, dass Sie versehentlich Passwörter oder Tokens in das Repository hochgeladen haben.
• Flusen von YAML- oder Infrastrukturcode, um ein lesbares und einheitliches Format zu gewährleisten.
• Aktualisierung des Repositorys innerhalb des Heimnetzwerks selbst: git pull auf dem Zielserver.
• Kontrollierte Wiederbelebung von Containern: Die alten Prozesse stoppen, die neuen starten und den Status überprüfen.

Vorteile: erhöhte Sicherheit (Sie kontrollieren das Durchsickern von Geheimnissen), bessere Codequalität und wiederholbare Bereitstellungen mit einem einzigen Push . Da Sie einen lokalen Runner verwenden, verlassen die Images und Volumes Ihr Netzwerk nicht; Sie nutzen einfach die GitHub-Oberfläche, um die Pipelines zu visualisieren.

Warum Docker Compose das Leben in einem Heimlabor so viel einfacher macht

Viele Anwender haben jahrelang auf Docker Run und Portainer vertraut , bis sie nach einem Vorfall oder einer Migration gezwungen waren, ihren Ansatz zu überdenken. Wenn ein Host ausfällt oder Dienste auf einen anderen Rechner verschoben werden müssen, ist es eine Falle, sich ausschließlich auf isolierte Befehle oder Konfigurationen innerhalb von Portainer zu verlassen.

Der große Unterschied beim Wechsel zu Compose besteht darin, dass die gesamte Servicedefinition zu Text wird : Volumes, Ports, Netzwerke, Labels, Variablen… Alles in einer YAML-Datei, die Sie kopieren, teilen, versionieren und wiederverwenden können.

Das Bearbeiten eines Dienstes bedeutet nicht mehr, einen Container manuell neu zu erstellen; es genügt nun, eine Zeile in einer Datei zu ändern, zu speichern und `docker compose up -d` auszuführen . Sie müssen sich weder den ursprünglichen Befehl merken noch sich durch mehrere Portainer-Fenster klicken.

Wenn Sie mit mehreren Servern (Mini-PCs, NAS, Desktop-PCs) arbeiten, ist es zudem äußerst praktisch , dieselbe Compose-Datei auf einen anderen Rechner kopieren, vier Pfade anpassen und denselben Stack auf unterschiedlicher Hardware ausführen zu können . Viele Anwender bestätigen, dass Compose ihnen nach Datenverlust oder chaotischen Migrationen in der Folge viel Zeit erspart hat.

Ein weiterer Vorteil ist, dass das Erstellen neuer Dienste aus alten Diensten trivial wird: Beispielsweise dauert das Klonen der Plex-Konfiguration zur Einrichtung von Jellyfin durch Wiederverwendung der gleichen Medienpfade und Transkodierungsgeräte nur wenige Minuten, wenn man dies durch Kopieren von YAML-Blöcken tut.

Optimierung: Kontext erstellen, mehrstufige Builds und Ressourcen

Obwohl viele Homelab-Container auf öffentlichen Images basieren, müssen Sie in manchen Fällen Ihre eigenen kompilieren. In diesen Fällen ist es wichtig, den Build-Kontext zu verwalten : Laden Sie nicht das gesamte Repository ungefiltert hoch, sondern beschränken Sie sich auf Ihren Projektordner (mithilfe einer aussagekräftigen `.dockerignore`-Anweisung), um schnelle und ressourcenschonende Builds zu gewährleisten.

Eine weitere sehr nützliche Technik ist die Verwendung mehrstufiger Builds in Ihren Dockerfiles: Im ersten Schritt installieren Sie die Abhängigkeiten und kompilieren das Image, im zweiten Schritt kopieren Sie nur die benötigten Artefakte in ein kleines Basis-Image. Das Ergebnis: deutlich kleinere und sicherere finale Images , da diese keine unnötigen Toolchains oder Bibliotheken enthalten.

Auf der Compose-Seite können Sie CPU- und RAM-Grenzwerte festlegen (insbesondere in Swarm-Umgebungen oder wenn Docker diese Parameter berücksichtigt), um zu verhindern, dass ressourcenintensive Anwendungen zu viele Ressourcen belegen. In Heimnetzwerken hilft dies, zu verhindern, dass ein falsch konfigurierter Dienst das restliche System lahmlegt.

Vergessen Sie nicht die Neustartrichtlinien (Neustart: immer, außer wenn gestoppt, bei Fehler): Mit ihnen stellen Sie sicher, dass kritische Dienste (Reverse-Proxy, VPN, wichtige Datenbanken) nach einem Neustart oder einem einmaligen Fehler automatisch neu gestartet werden.

Abschließend empfiehlt es sich, regelmäßige Aufräumarbeiten mit Befehlen wie docker image prune, docker container prune und docker volume prune einzuplanen , um Überreste alter Builds, gestoppter Container oder verwaister Volumes zu entfernen und so Speicherplatz freizugeben.

Gesundheitsdienste, Protokollierung und Überwachung

Damit Ihr Heimnetzwerk nicht zu einer Blackbox wird, ist es wichtig, drei Schlüsselaspekte zu beachten: Integritätsprüfungen, kontrollierte Protokollierung und Überwachung . Mit Docker Compose können Sie Integritätsprüfungen pro Dienst definieren (z. B. mit Befehlen wie `curl -f http://localhost` oder spezifischen Skripten), die den Zustand eines Containers überprüfen.

Dadurch wird sichergestellt, dass nur fehlerfreie Container Datenverkehr empfangen (z. B. über Traefik) und dass sie, falls sie nicht mehr reagieren, gemäß der konfigurierten Richtlinie neu gestartet werden. Dies erhöht die Ausfallsicherheit mit minimalem Aufwand erheblich.

Was die Protokollierung betrifft, so verhindert die Anpassung des JSON-Dateitreibers mit den Grenzwerten für maximale Größe und maximale Dateianzahl, dass die Festplatte mit Gigabytes an vergessenen Protokolldateien voll wird. Webtools wie Dozzle ermöglichen das Durchsuchen der Protokolle aller Container über einen Browser, was die Fehlersuche in bestimmten Diensten erheblich erleichtert.

Für Metriken und kontinuierliches Monitoring ist die klassische Kombination cAdvisor + Prometheus + Grafana . cAdvisor liefert Statistiken zur CPU-, Speicher-, Festplatten- und Netzwerknutzung pro Container; Prometheus erfasst diese regelmäßig, und Grafana visualisiert sie in ansprechenden Dashboards und gibt Warnmeldungen aus, sobald ein Verbrauchsspitzenwert auftritt.

Ein gut eingerichtetes Heimnetzwerk umfasst typischerweise Uptime Kuma für Verfügbarkeitsprüfungen (HTTP, ICMP, TCP usw.) und ein automatisiertes Backup-System wie Duplicati, um wichtige Daten auf andere Festplatten oder in die Cloud zu kopieren. So wissen Sie immer, was passiert, und im Fehlerfall gehen keine wichtigen Daten verloren.

Sicherheit und Fernzugriff auf das Heimlabor

Egal wie man die Einrichtung selbst vornimmt, Sicherheit ist unerlässlich. Viele Nutzer entscheiden sich dafür, ihr NAS oder dessen Dienste nicht direkt der Außenwelt auszusetzen und beschränken den Fernzugriff über ein VPN (WireGuard ist aufgrund seiner Leistungsfähigkeit und Einfachheit eine sehr beliebte Option).

In diesem Modell fungiert der Router als Gateway: Für den VPN-Server wird lediglich ein zufälliger Port geöffnet, und nach der Verbindungsherstellung werden alle Anfragen an interne Dienste durch einen verschlüsselten Tunnel geleitet . Weder Traefik noch die Anwendungen sind ohne diese vorherige Filterung dem Internet ausgesetzt.

Wer sein VPN nicht selbst verwalten möchte, greift mitunter auf Cloudflare Tunnel oder Tailscale zurück , um ohne Portöffnung auf sein Heimnetzwerk zuzugreifen. Das sind praktische Alternativen, doch wenn Datenschutz oberste Priorität hat, sollten Sie bedenken, welche Metadaten diese Drittanbieter möglicherweise erfassen.

Eine weitere bewährte Methode ist die Verschlüsselung der Server- und NAS-Festplatten , das regelmäßige Einspielen von Patches und die Einschränkung automatischer Updates (viele verzichten auf Watchtower und bevorzugen stattdessen kontrollierte manuelle Updates). Es ist besser, etwas hinterherzuhinken, aber die Kontrolle zu behalten, als die Hälfte des Heimnetzwerks durch ein nicht überprüftes Update lahmzulegen.

Wie Sie sehen, müssen Sie kein "Enterprise"-Niveau erreichen, aber es ist ratsam, ein Mindestmaß an Sicherheit und Disziplin zu gewährleisten , damit Ihr Heim-Labor nicht zu einem Sieb oder einer ständigen Quelle der Angst wird.

Letztendlich ist die Einrichtung eines ernstzunehmenden Heimlabors mit Docker Compose eine Mischung aus Organisation, gesundem Menschenverstand und der Bereitschaft zum Experimentieren: Wenn man Dienste gruppiert, die Netzwerke gut definiert, in Git dokumentiert und ein wenig automatisiert, erhält man eine Umgebung, die man mit einem einzigen Befehl starten, problemlos auf einen anderen Rechner migrieren und nach und nach erweitern kann, ohne dass sie zu einem unkontrollierbaren Dschungel wird.