Compose-Override-Dateien

Viele Stacks halten lokale Anpassungen in einer zweiten Datei neben compose.yaml, meistens compose.override.yaml: einen zusätzlichen Dienst wie Mailpit, eine Port-Zuordnung, ein Volume. docker compose lädt diese Datei automatisch nur, wenn du keine Dateien mit -f angibst. Bis 2.7.2 hat Containly immer die Hauptdatei angegeben, Override-Dateien wurden also ignoriert. Seit 2.7.3 übergibt Containly jede Datei.

Welche Dateien Containly verwendet

1. Die Dateien, die Docker festgehalten hat. Jeder von Compose gestartete Container trägt das Label com.docker.compose.project.config_files mit den Dateien dieses Deploys in ihrer Reihenfolge. Containly verwendet diese (von allen Containern des Stacks), ein mit docker compose -f compose.yaml -f prod.yaml up -d gestarteter Stack behält also beide Dateien und ihre Reihenfolge. Eine Standard-Override-Datei (siehe 2.), die im Ordner liegt, aber im Label fehlt, kommt am Schluss dazu.
2. Vor dem ersten Deploy oder wenn keine festgehaltene Datei brauchbar ist, gilt dieselbe Regel wie bei docker compose ohne -f: die Hauptdatei plus die erste vorhandene von compose.override.yml, compose.override.yaml, docker-compose.override.yml, docker-compose.override.yaml.

Es werden nur normale Dateien innerhalb des Stack-Ordners verwendet. Pfade ausserhalb des Ordners und symbolische Links werden ignoriert (und protokolliert).

Jede Aktion von Containly auf dem Stack nutzt diese Liste: Deploy, Pull, Start, Stopp, Neustart, Down, Logs, der App-Katalog, Git-Stacks, CI-Redeploys, Backups und Wiederherstellungen sowie das Verschieben eines Stacks auf einen anderen Host.

Im Editor

Hat ein Stack Override-Dateien, zeigt der Editor sie als Tabs neben der Hauptdatei, zum Beispiel compose.yaml und compose.override.yaml (markiert mit Override). Beide lassen sich mit denselben Prüfungen bearbeiten, ungespeicherte Änderungen sind am Tab markiert, und Vor dem Deploy prüfen listet die gespeicherten Änderungen jeder Datei seit dem letzten Deploy.

Versions-Updates

Ein Update eines festen Versions-Tags (zum Beispiel axllent/mailpit:v1.20.0 auf v1.21.0) durchsucht jetzt alle Compose-Dateien des Stacks und .env. Containly ändert genau die Datei, die den Tag festlegt: die Override-Datei, wenn das Image nur dort steht, .env, wenn der Tag eine Variable ist. Legen ihn mehrere Dateien fest, werden alle gemeinsam angepasst. Schlägt das Neu-Ausrollen fehl, wird jede geänderte Datei wiederhergestellt. Steht der Tag in keiner Datei, nennt die Meldung die durchsuchten Dateien.

Gut zu wissen

• Ein Stack, den du mit docker compose up -d in seinem Ordner gestartet hast, trägt die Override-Datei schon im Label, für dich ändert sich nichts.
• Hat ein älteres Containly so einen Stack neu ausgerollt und dabei den Override-Dienst entfernt, rolle ihn einmal aus Containly 2.7.3 aus: Die Override-Datei kommt wieder dazu, weil sie im Ordner liegt.
• Soll eine Override-Datei nicht mehr gelten, benenne sie um oder lösche sie und rolle den Stack neu aus.