Datenbanken

Jedes Projekt kann seinen eigenen Datenbankserver bekommen: MariaDB, MySQL, PostgreSQL oder MongoDB. Er läuft als Container des Projekts mit einem dauerhaften Volume, Envoryx denkt sich die Zugangsdaten aus, und deine Anwendung findet alles Nötige in ihrer Umgebung. Die Datenbank wählst du im Assistenten im Schritt Projekt & Dienste oder fügst sie später im Bereich Datenbank des Projekts hinzu.

So findet deine Anwendung die Datenbank

Im Projektnetz heißt die Datenbank einfach database. Jeder Anwendungscontainer - PHP, Python, Go, Ruby, Java, .NET oder Node.js - bekommt diese Variablen:

Variable	Beispiel
DB_CONNECTION	mysql, pgsql oder mongodb
DB_HOST	database
DB_PORT	3306 / 5432 / 27017
DB_DATABASE, DB_USERNAME, DB_PASSWORD	pro Projekt erzeugt
DATABASE_URL	die ganze Verbindung als eine URL
DB_SERVER_VERSION	die Serverversion so, wie Doctrine sie haben will: 18, 8.4.0, mariadb-11.4.0

Bei MongoDB kommt noch MONGODB_URI dazu. Laravel, Symfony und die meisten anderen Frameworks lesen diese Namen von sich aus. Django holt sich DATABASE_URL über dj-database-url, und Rails übernimmt DATABASE_URL in config/database.yml. Das Schema einer PostgreSQL-DATABASE_URL hängt vom Container ab. PHP bekommt pgsql://, das Laravel und Doctrine lesen; jede andere Runtime, ihre Worker und Cron-Jobs bekommen postgresql://, die Schreibweise, die Active Record, SQLAlchemy, Prisma, pgx und lib/pq akzeptieren. DB_CONNECTION bleibt überall pgsql, und MariaDB und MySQL sind in jedem Container mysql://. Java bekommt zusätzlich die Variablen für Spring Boot und Quarkus und eine JDBC_URL, .NET einen ConnectionStrings__DefaultConnection - mehr dazu auf den Seiten zu Java und .NET.

DB_SERVER_VERSION gibt es für die MariaDB-, MySQL- und PostgreSQL-Server, die Envoryx selbst betreibt, nicht für MongoDB und nicht für einen externen Server (dessen Version kann Envoryx nicht kennen; brauchst du die Variable, setz sie selbst in der Projektumgebung). Der Grund dafür ist Doctrine: In der eingespeisten DATABASE_URL steht keine Serverversion, und ohne sie brechen die Migrationen von Symfony mit “Invalid platform version” ab. Der Wert folgt der Version, die du fürs Projekt gewählt hast, nicht dem Patch-Release, das der Server gerade fährt: Eine MariaDB auf 11 bekommt mariadb-11.0.0, auch wenn das Image inzwischen 11.8 ist. Das ist Absicht. So legt sich Doctrine auf eine Plattform fest, die jeder Server hinter diesem Tag beherrscht, und der Wert ändert sich nicht, nur weil das Image neu gebaut wurde. Das Symfony-Template liest die Variable schon in config/packages/doctrine.yaml. Bei einem älteren Symfony-Projekt ergänzt du unter doctrine.dbal eine Zeile:

config/packages/doctrine.yaml

doctrine:
    dbal:
        server_version: '%env(DB_SERVER_VERSION)%'

Der Bereich Tests lässt diese Datenbank in Ruhe. Eine Testsuite, die das Schema neu aufsetzt oder Fixtures lädt, würde deine Entwicklungstabellen leeren, deshalb laufen die Runner, die die Datenbank nutzen, gegen eine eigene Datenbank auf demselben Server: <datenbank>_test bei PHPUnit, Pest, Rails, Java und .NET, test_<datenbank> bei Djangos Runner und pytest-django. Envoryx legt sie vor dem Lauf als Administrator an, weil der Projekt-Login von MySQL und MariaDB keine Datenbanken anlegen darf. Die Tabellen sind Sache deiner Tests; die Einzelheiten stehen unter Aktionen und Tests.

Die Zugangsdaten stehen im Bereich Datenbank. Willst du mit einem Desktop-Programm wie TablePlus, DBeaver oder DataGrip in die Daten schauen, schalte dort Port auf dem Host veröffentlichen ein; der Bereich IDE zeigt dir dann fertige JDBC-URLs.

Was du im Bereich Datenbank so machst

Das meiste rund um die Datenbank passiert in diesem Bereich. Dort stehen Zugangsdaten und Verbindungs-Strings. Passwort rotieren erzeugt ein neues Passwort und baut die Anwendungscontainer gleich damit neu, du musst also nichts von Hand umkopieren. Unter Datenbanken kannst du neben der Projektdatenbank weitere anlegen, auflisten und löschen. Datenbank öffnen startet den eingebauten Datenbank-Browser, und weiter unten findest du Snapshots, das Klonen und die Version des Servers.

Snapshots

Ein Snapshot ist ein Dump einer einzelnen Datenbank, sonst nichts. Den machst du direkt vor einer Migration - dann ist eine schiefgegangene Migration nur noch ärgerlich und kein Drama.

Unter Datenbank → Snapshots → Snapshot erstellen legst du ihn an, gern mit einer Notiz wie „vor der Orders-Migration“. Zurück geht es, indem du den Snapshot auswählst und auf Wiederherstellen klickst; zur Bestätigung tippst du den Projekt-Bezeichner ein. Vor dem Import leert Envoryx die Datenbank. Eine Tabelle, die die missglückte Migration angelegt hat, ist danach also auch weg, und der nächste Versuch stolpert nicht über sie. Auf einem externen Server lässt Envoryx das bleiben, weil es dort nie etwas löscht: Der Dump kommt einfach über das, was schon da ist.

Das Projekt muss dafür nicht laufen. Ein gestoppter Datenbank-Container wird für den Dump oder den Import kurz gestartet und danach wieder gestoppt. Snapshots sind ganz normale Backups im Backup-Ordner des Projekts, deshalb tauchen sie auch im Bereich Backups auf und lassen sich herunterladen. Envoryx behält die zehn neuesten pro Datenbank; deine geplanten und manuellen Backups verdrängen sie nie.

Das Gleiche auf der Kommandozeile:

envoryx db snapshot shop --note "vor der Migration"
envoryx db snapshots shop
envoryx db restore shop <snapshot> --yes

Die Datenbank eines anderen Projekts übernehmen

Manchmal willst du die Daten aus einem anderen Projekt, etwa von Staging, in deinem lokalen haben. Aus einem anderen Projekt klonen ersetzt den Inhalt dieser Projektdatenbank durch den einer anderen Datenbank mit derselben Engine. Der Dump fließt direkt vom Client des einen Containers in den des anderen, unterwegs landet nichts auf der Platte. Die Quelle wird nur gelesen, beide Projekte sind währenddessen gesperrt, und das Ziel bekommt vorher einen Snapshot - außer du schaltest das ab.

envoryx db clone local --from staging --yes      # --no-snapshot lässt das Sicherheitsnetz weg

Mehr als eine Datenbank

Bei einer Datenbank pro Projekt muss es nicht bleiben. Neben der primären kannst du beliebig viele weitere mit eigenem Namen anlegen, zum Beispiel ein PostgreSQL fürs Reporting neben deiner MariaDB oder eine zweite MariaDB in einer anderen Version. Das geht im Assistenten unter Projekt & Dienste → Zusätzliche Datenbanken oder mit Datenbank hinzufügen im Bereich Datenbank.

Aus dem Namen ergibt sich alles andere. Für eine Datenbank namens analytics sieht das so aus:

Container / Volume	envoryx-<projekt>-db-analytics
Host im Projektnetz	analytics
Variablen	ANALYTICS_DB_CONNECTION, ANALYTICS_DB_HOST, ANALYTICS_DB_PORT, ANALYTICS_DB_DATABASE, ANALYTICS_DB_USERNAME, ANALYTICS_DB_PASSWORD, ANALYTICS_DATABASE_URL, dazu ANALYTICS_DB_SERVER_VERSION bei MariaDB, MySQL und PostgreSQL oder ANALYTICS_MONGODB_URI bei MongoDB

Ein Name hat 1-24 Kleinbuchstaben, Ziffern und Bindestriche und fängt mit einem Buchstaben an. In den Variablen werden aus Bindestrichen Unterstriche, aus legacy-db wird also LEGACY_DB_DB_HOST. Namen, unter denen schon ein anderer Container des Projekts erreichbar ist (database, redis, web, die Engine-Namen …), lehnt Envoryx ab, sonst würden sich die Hostnamen in die Quere kommen.

Jede dieser Datenbanken hat eigene Zugangsdaten, einen eigenen Port, eine eigene Version und eigene Upgrades, und alles im Bereich Datenbank funktioniert für jede einzeln. Backups sichern alle (database.sql.gz für die primäre, database-<name>.sql.gz für die anderen), und beim Duplizieren oder Umbenennen eines Projekts kommen sie mit. Auf der Kommandozeile nimmt jeder db-Befehl --db NAME, und project create kennt --add-database NAME=TYP[:VERSION].

Einen vorhandenen Server nutzen

Eine Datenbank muss kein Container sein. Genauso gut kann es ein Server sein, der schon irgendwo läuft: die MariaDB auf deinem NAS, ein PostgreSQL im Firmennetz, eine gemanagte Datenbank beim Hoster. Das klappt für die primäre Datenbank wie für zusätzliche.

Wähle im Assistenten oder beim Hinzufügen einer Datenbank Auf einem externen Server, trag Host, Port, Benutzer, Passwort und Datenbank ein und probier Verbindung testen. Vor dem Speichern testet Envoryx noch einmal und sagt dir, woran es hakt, wenn keine Verbindung zustande kommt.

Das funktioniert mit MariaDB, MySQL und PostgreSQL. Die gewählte Version bestimmt, welche Client-Werkzeuge Envoryx benutzt - nimm also die Hauptversion des Servers; bei PostgreSQL darf der Client nicht älter sein als der Server. Einen Server auf dem Docker-Host selbst erreichst du als host.docker.internal. localhost lehnt Envoryx ab, denn im Container ist localhost der Container selbst.

Deine Anwendung bekommt dieselben Variablen wie bei einem Container (bis auf DB_SERVER_VERSION), sie zeigen eben auf den Server. Backups, Snapshots und Wiederherstellung, Klonen, der Website-Import, Adminer sowie Datenbanken auflisten und anlegen funktionieren. Bewusst lässt Envoryx dagegen die Finger davon, eine Datenbank auf dem Server zu löschen oder ihr Passwort zu ändern, und es veröffentlicht auch keinen Port. Nimmst du die Datenbank aus dem Projekt, vergisst Envoryx nur die Verbindung.

Duplizierst du so ein Projekt, bekommt die Kopie einen lokalen Datenbank-Container mit den Daten vom externen Server. So kann eine Kopie den echten Server nie verändern.

Upgrades

Die Version stellst du im Bereich Datenbank um. Bevor irgendetwas passiert, legt Envoryx ein Datenbank-Backup an (Quelle upgrade). Geht das nicht, weil das Projekt gestoppt ist, lehnt es das Upgrade lieber ab, als deine Daten zu riskieren.

MariaDB und MySQL heben ihr Datenverzeichnis direkt auf die neue Version, auch über Hauptversionen hinweg. PostgreSQL kann das bei einer neuen Hauptversion nicht, darum lehnt Envoryx diese Upgrades ab; leg die Datenbank in der neuen Version an und spiel den Dump dort ein. Bei MongoDB ist es genauso, mit einer Ausnahme: 8.0 kann direkt auf 8.2 wechseln, denn 8.2 übernimmt die Daten von 8.0 so, wie sie sind. (Die Feature Compatibility Version bleibt auf 8.0, bis du sie selbst anhebst.) Auf eine ältere Version zurück geht es nie, weil sich das Datenformat nicht zurückdrehen lässt.

MongoDB auf neueren Linux-Kerneln

Neue Datenbanken bekommen MongoDB 8.2. 8.0 und 7.0 starten nicht auf Linux 6.19 oder neuer. Auf einem Docker-Host mit so einem Kernel kannst du sie deshalb nicht auswählen, und ein Projekt, das schon eine hat, startet ohne diese Datenbank und zeigt einen Hinweis, statt sie immer wieder neu zu starten.

Bei 8.0 hilft das Upgrade auf 8.2 von oben. Envoryx legt vorher wie bei jedem Upgrade ein Backup an. Auf einem betroffenen Host kann der alte Server für einen Dump nicht laufen, darum ist dieses Backup eine Kopie des Daten-Volumes, und Wiederherstellen, Download und Offsite-Kopien gehen mit dieser Kopie um wie mit einem Dump. Für 7.0 gibt es auf so einem Host keinen Weg zu 8.2: Entweder exportierst du die Daten auf einem Host mit älterem Kernel, oder du entfernst die Datenbank und legst sie neu an, dann sind ihre Daten weg.

Datenbank-Browser (Adminer)

Manchmal willst du nur schnell in eine Tabelle schauen, ohne extra ein Programm zu starten. Einstellungen → Datenbank-Browser schaltet dafür Adminer frei, der mit MariaDB, MySQL und PostgreSQL klarkommt. (MongoDB kann Adminer nicht; veröffentliche dafür den Port und nimm Compass.)

Bis du zum ersten Mal auf Datenbank öffnen klickst, läuft gar nichts. Dann startet Envoryx einen Adminer-Container, den sich alle Projekte teilen, hängt ihn ins Projektnetz und öffnet ihn gleich als Projektbenutzer angemeldet. Adminer läuft unter der Envoryx-Oberfläche unter /dbtool/, deine Envoryx-Anmeldung schützt ihn also, und du brauchst keinen extra Port, Hostnamen oder Zertifikat. Schaltest du den Datenbank-Browser in den Einstellungen wieder ab, verschwindet auch der Container.

Er öffnet nur, woran du auch arbeiten darfst. Envoryx prüft jede Anfrage und lässt dich in die Datenbanken der Projekte, die du bedienen darfst (als Entwickler oder Admin dort, oder mit einem operate-Token), den Root-Login eingeschlossen; jeden anderen Server lehnt es ab. Der Adminer-Container selbst antwortet nur auf Anfragen, die über Envoryx kommen, die Projektcontainer im selben Netz können ihn also nicht benutzen. Eins solltest du über die automatische Anmeldung wissen: Sie schreibt das Passwort in ein verstecktes Feld der Adminer-Anmeldeseite, das Passwort kommt also im Browser dessen an, der sie öffnet.

Container und Netz heißen nach der Instanz, envoryx-dbtool- plus die ersten 8 Zeichen der Instanz-ID. So kann ein zweites Envoryx auf demselben Docker-Host seinen eigenen Datenbank-Browser haben.