Zum Inhalt springen

FAQ

Mehrere Dinge, die wie Bugs aussehen, sind tatsächlich bewusste Design-Entscheidungen. Hier ist die Begründung hinter den häufigsten Fragen.

OrbStack ist empfohlen. Mit OrbStack ist jeder Container automatisch vom Host als <service>.<project>.orb.local erreichbar, was den Datenbank-Zugriff schmerzlos macht. Mit Docker Desktop ist Host-DNS in Container nicht verfügbar, sodass das Erreichen einer Datenbank vom Host bedeutet, temporär einen Port von Hand zu mappen (ein zukünftiges mdocker expose wird das glätten). Alles andere funktioniert auf beiden.

Warum fragt mein Browser nach der „Lokales Netzwerk“-Berechtigung?

Abschnitt betitelt „Warum fragt mein Browser nach der „Lokales Netzwerk“-Berechtigung?“

Weil MultiDocker-Domains zu Container-IPs auf deiner Maschine auflösen, verlangen neuere macOS-Versionen die Lokales Netzwerk-Berechtigung, bevor der Browser sich verbindet. Erteile sie einmal und das HTTPS-Schloss verhält sich normal. Das ist eine macOS-Datenschutz-Abfrage, kein MultiDocker-Fehler.

Meine Demo-Tunnel-URL ändert sich ständig / hat kein Passwort

Abschnitt betitelt „Meine Demo-Tunnel-URL ändert sich ständig / hat kein Passwort“

Das ist so gewollt. Öffentliche Demo-Tunnels nutzen einen Cloudflare-trycloudflare.com-Quick-Tunnel ohne Account:

  • Die URL ist zufällig und ändert sich bei jedem Start.
  • Es gibt keinen Passwortschutz — jeder mit dem Link erreicht es.
  • Tunnels überleben keinen Reboot (der Prozess ist weg, also entfernt mdocker share ls ihn).

Named Tunnels und Passwortschutz sind auf der Roadmap; behandle einen geteilten Link vorerst als temporär und öffentlich.

Shopware-Assets im geteilten Tunnel zeigen auf meine lokale Domain

Abschnitt betitelt „Shopware-Assets im geteilten Tunnel zeigen auf meine lokale Domain“

Anwendungen, die absolute URLs erzeugen — wie Shopware, das Asset-/Link-URLs aus der Sales-Channel-Domain baut — zeigen auch durch den Tunnel weiter auf deine lokale Domain. Gleiche die Sales-Channel-Domain mit dem Traefik-Hostnamen über mdocker shop domain sync an. Siehe Shopware-Workflows.

mdocker git info zeigt veraltete ahead/behind-Zahlen

Abschnitt betitelt „mdocker git info zeigt veraltete ahead/behind-Zahlen“

Mit Absicht. Der Git-Snapshot ist komplett lokal — er führt nie ein git fetch aus. Ahead/behind spiegeln deinen letzten lokalen Sync mit dem Remote wider, sodass der Befehl schnell und ohne Seiteneffekte ist. Fetche selbst, wenn du frische Zahlen willst. Siehe Git-Status pro Projekt.

Die App und mein Terminal sehen unterschiedliche Projekte und Tunnels

Abschnitt betitelt „Die App und mein Terminal sehen unterschiedliche Projekte und Tunnels“

Auch so gewollt. Die macOS-App nutzt ~/.multidocker/config/, während das eigenständige CLI ~/.config/multi-docker/ nutzt — getrennte Config-Verzeichnisse, getrennte Registries und Tunnels. Ein in einem registriertes Projekt erscheint nicht im anderen. Siehe CLI vs. App: Getrennte Welten.

Ich habe die Basis-Domain geändert und nichts geht mehr

Abschnitt betitelt „Ich habe die Basis-Domain geändert und nichts geht mehr“

Die Änderung über mdocker config set BASE_DOMAIN <new> erzeugt das Zertifikat, die Resolver-Dateien, jedes Projekt-Override und den Edge-Stack automatisch neu. Zwei Nachfassaktionen: starte deinen Browser neu (damit er die CA neu einliest und gecachte Lookups verwirft), und wenn ein bestimmtes Projekt weiterhin daneben liegt, führe mdocker rerender <name> aus. Siehe Basis-Domain ändern.

edge down hat all meine Projekte gestoppt — ist das ein Bug?

Abschnitt betitelt „edge down hat all meine Projekte gestoppt — ist das ein Bug?“

Nein. Der Edge-Stack (Traefik, DNS, Zertifikate) ist das Fundament, von dem jedes Projekt abhängt, daher stoppt mdocker edge down bewusst zuerst alle laufenden Projekte — sonst würden sie unerreichbar am entfernten Netz hängen. Um nur den Edge neu zu starten und Projekte weiterlaufen zu lassen, nutze mdocker edge restart. Siehe Der Edge-Stack.

Nein. Zertifikate leben unter ~/.config/multi-docker/certs/ (CLI) / dem config/certs/ der App — außerhalb des versionierten Runtime-Ordners — genau damit ein Runtime-Update sie nicht überschreiben oder löschen kann. Siehe Filesystem-Layout.