Projekt-Lebenszyklus

Steht ein Projekt einmal, läuft das meiste über die Schaltflächen im Kopf der Projektseite und das Menü Weitere Aktionen (⋯) daneben. Hier steht, was dahinter jeweils passiert.

Starten, stoppen, neu starten

Diese drei wirken auf alle Container des Projekts gleichzeitig. Beim Stoppen bleiben deine Daten erhalten. Neustart holt außerdem aktualisierte Runtime-Images, neu erstellt wird ein Container aber nur, wenn sich sein Image wirklich geändert hat.

Den Browser musst du dafür nicht offen lassen. Anlegen, Starten, Neustarten, Aktualisieren, Löschen, Backups und Wiederherstellungen laufen auf dem Server bis zum Ende durch, auch wenn du den Tab schließt oder die Verbindung abreißt. Beim nächsten Laden der Seite siehst du, wie es ausgegangen ist.

Die Projekt-Container haben die Docker-Restart-Policy unless-stopped und laufen deshalb weiter, während Envoryx selbst gestoppt oder aktualisiert wird. Sollen sie lieber Envoryx folgen, schaltest du das unter Einstellungen → Allgemein → Projekte und der Envoryx-Container ein: Stoppt Envoryx, stoppen dann auch die laufenden Projekte, und beim nächsten Start kommen die wieder, die vorher liefen - auch nach einem Neustart des Hosts.

Runtime-Images und Zurücksetzen

Die Runtime-Images werden jede Woche aus den offiziellen Images neu gebaut, dadurch kommen Patch-Releases wie PHP 8.5.3 → 8.5.4 herein. Ein laufendes Projekt behält sein Image, bis du es neu startest: Ein Neustart fragt die Registry nach dem aktuellen Build und erstellt die Container neu, deren Image sich geändert hat. Hat ein anderes Projekt schon einen neueren Build desselben Tags geholt, übernimmt ihn auch Starten. Alles andere lässt die Container auf ihrem Image. Einen Worker hinzufügen oder eine Variable ändern startet also nicht deine Datenbank neu und leert nicht Mailpit, nur weil ein Update wartete. Bis zum Neustart sagt der Status das, etwa Ein neueres php-Image wurde geladen; zum Übernehmen neu starten.

Bei Neuem ist es anders. Ein neues Projekt, der Wechsel auf eine andere Runtime-Version und ein neu hinzugefügter Dienst bekommen immer das aktuelle Image, weil einem älteren Build auf dem Host Werkzeuge fehlen könnten, auf die das aktuelle Envoryx setzt. Ohne Verbindung zur Registry nimmt Envoryx das lokale Image.

Manchmal macht so ein Patch-Release etwas kaputt. Genau dafür gibt es das Zurücksetzen: Hat ein Neustart Container durch ein neu gebautes Image ersetzt, zeigt die Übersicht neben dem Dienst Image aktualisiert und eine Schaltfläche Zurücksetzen. Sie erstellt die Container aus dem Image neu, mit dem sie vorher liefen, und das Projekt bleibt auch bei weiteren Neustarts dabei, bis du Aktuelles Image verwenden wählst. Für einen Wechsel auf eine andere Version (PHP 8.4 → 8.5) ist der Bereich Laufzeit zuständig.

Duplizieren

Projekt duplizieren kopiert ein Projekt - aus shop wird shop-test - in einem einzigen Dialog. Praktisch, wenn du ein riskantes Upgrade ausprobieren willst, ohne das Original anzufassen. Konfiguration, Umgebung, Proxy-Regeln, Ressourcenlimits und Health Check kommen immer mit. Den Rest wählst du selbst:

• die Projektdateien, auf Wunsch samt Abhängigkeiten (vendor/, node_modules/ und andere Ordner, die ein Build neu erzeugt) - langsamer, dafür läuft die Kopie ohne erneute Installation,
• den Inhalt der Datenbank, gedumpt und in den eigenen Datenbankserver der Kopie importiert,
• die Objekte im Bucket,
• die Worker und Cron-Jobs,
• die Verknüpfung mit dem Repository.

Setzt du den Haken bei Kopie starten, sobald sie fertig ist, startet sie erst, wenn Dateien und Daten drin sind. Sie läuft also nie gegen eine halb gefüllte Datenbank an.

Die Kopie bekommt einen eigenen Ordner, eigene Host-Ports und eigene Container, behält aber die Datenbank-Zugangsdaten des Originals - eine .env in den Projektdateien funktioniert also einfach weiter. Zusätzliche Domains und der Backup-Zeitplan bleiben beim Original. Hängt das Original an einem externen Datenbankserver, bekommt die Kopie stattdessen lokale Container mit diesen externen Daten.

envoryx project duplicate shop "Shop Test"

Was du in der Kopie selbst nachziehst

Mit wandern nur Datenbank, Bucket und Dateien. Redis, OpenSearch, Meilisearch, Typesense und RabbitMQ starten in der Kopie leer: Caches und wartende Nachrichten sind weg, und einen Suchindex musst du neu aufbauen. Einen Cache füllen die meisten Anwendungen von selbst wieder, das tut also selten weh. Die Ausnahme ist Shopware mit eingeschaltetem OpenSearch (SHOPWARE_ES_ENABLED=1): Ohne Index antwortet dort schon die Startseite des Storefronts mit einem 500 (no such index [sw_product]), nicht nur die Suche. Lass bin/console es:index in der Kopie laufen, bevor du sie dir ansiehst.

Was dagegen gern überrascht: Manche Anwendungen merken sich ihre eigene Adresse in der Datenbank oder in ihrer Konfiguration, und die Kopie schickt deinen Browser dann direkt zum Original zurück. WordPress macht das mit siteurl und home in der Tabelle wp_options. Kommt dein WordPress aus einem Website-Import oder aus dem Template ab Envoryx 0.20, setzt seine wp-config.php beide auf die Adresse, unter der die Seite aufgerufen wird. Die Kopie und ihr wp-admin bleiben also bei der Kopie. Seine Beiträge stecken aber weiter voller absoluter Links aufs Original, und bei einem WordPress, das auf anderem Weg ins Projekt kam, gilt das für die ganze Datenbank. WP-CLI steckt im PHP-Image, also ändert wp search-replace 'https://shop.test' 'https://shop-test.test' im PHP-Terminal der Kopie alle auf einmal, serialisierte Optionen eingeschlossen. Shopware speichert die Domains seiner Verkaufskanäle in der Datenbank; bin/console sales-channel:update:domain shop-test.test stellt sie auf die Kopie um. Bei TYPO3 ist es die base der Site-Konfiguration in config/sites/.

Umbenennen

Projekt umbenennen ändert den Namen des Projekts, und der daraus abgeleitete Bezeichner zieht überall mit: URL und Hostnamen, Container-, Netzwerk- und Volume-Namen, die SSH-Benutzer, der Projektordner (außer du hast ihn von Hand gewählt) und die Backups, die danach auch den neuen Namen tragen. Datenbankname, Login und Bucket ändern sich ebenfalls, sofern du sie nicht behalten willst, und die Begleit-Datenbanken ziehen mit der primären mit: die _test-Datenbank und in einem Rails-Projekt _queue, _cache und _cable. Dabei werden die Container neu erstellt, das Projekt ist also einen Moment lang nicht erreichbar.

envoryx project rename shop "Acme Blog" --yes

Löschen

Projekt löschen stoppt und entfernt alle Container des Projekts, sein Netzwerk, seine Volumes - samt Datenbankinhalt - und die erzeugte Konfiguration. Zur Bestätigung tippst du den Bezeichner des Projekts ein. Setzt du den Haken bei Auch Projektdateien löschen, verschwindet auch der Projektordner. Rückgängig machen lässt sich beides nicht. Wenn du die Daten vielleicht noch einmal brauchst, mach vorher ein Backup. Die Backups des Projekts überstehen das Löschen: Sie tauchen unter Einstellungen → Backups → Backups gelöschter Projekte auf, und von dort kannst du eins in ein neues Projekt wiederherstellen.

envoryx project delete shop --yes [--delete-files]

Ab und zu stößt du vielleicht auf Überbleibsel: Ressourcen mit Envoryx-Labels, deren Projekt es nicht mehr gibt, etwa nach dem Wiederherstellen eines älteren Instanz-Backups. Verwaiste Container und Netzwerke, die es selbst gelabelt hat, räumt Envoryx weg. Volumes löscht es aber nie von sich aus, und Überbleibsel ohne Label von einem Envoryx vor 0.18 lässt es ebenfalls stehen (die Seite Docker markiert sie mit älteres Envoryx). Die stehen auf der Seite Docker mit einer Schaltfläche zum Entfernen. Legst du ein Projekt mit demselben Namen neu an, übernimmt es ihre Daten.