- Ein pragmatischer Trick, um Kosten- und Komplexitätsprobleme beim Betrieb einer Datenbank für Entwicklung und Tests zu lösen
- VPS, Cloud-VMs, Managed Services usw. verursachen laufende Kosten und Speichergebühren
- Die Einrichtung ist komplex, und selbst bei Nichtnutzung fallen Ressourcenkosten an
- Alternative: Datenbankbetrieb mit GitHub Actions und S3
- Eine temporäre Datenbank nur bei Bedarf mit GitHub Actions ausführen
- Daten dauerhaft mit AWS S3 oder S3-kompatiblem Storage speichern
- Nach Ende des Workflows bleiben die Daten erhalten, während die Laufzeitumgebung entfernt wird, was Kosten spart
- Per Tunneling kann die Datenbank vorübergehend öffentlich aus dem Internet zugänglich gemacht werden
- Wichtige Hinweise zur Nutzung
- Dieser Ansatz eignet sich nur für kurzfristige Integrationstests, temporäre Demos und einfache Entwicklungsaufgaben
- GitHub Actions nicht als langfristige Service-Plattform missbrauchen
- Wenn dauerhaftes und langfristiges Datenbank-Hosting benötigt wird, ist ein Self-Hosted Runner oder ein separater Datenbankdienst die passendere Wahl
- Der Betrieb muss unter Einhaltung der GitHub-Nutzungsrichtlinien erfolgen
Kernidee
- Temporäre Rechenumgebung von GitHub Actions nutzen
- Eine MySQL-kompatible Datenbank nur bei Bedarf als Teil eines CI/CD- oder Test-Workflows ausführen
- Dauerhafte Datenspeicherung über S3-kompatiblen Storage
- Daten in Object Storage wie AWS S3 oder Cloudflare R2 speichern
- Auch wenn die temporäre Umgebung beendet wird, bleiben die Daten sicher im Object Storage erhalten
- Tunneling für öffentlichen Zugriff
- Die Datenbank für Tests oder Demos vorübergehend über das Internet erreichbar machen
- Für kurzfristige Nutzung geeignet
- Die Datenbank läuft nur während der Ausführungszeit des Workflows
- Nach Ende des Workflows werden die temporären Rechenressourcen freigegeben; dies ist keine dauerhafte Hosting-Lösung
- Wenn es vollständig kostenlos sein soll
- S3-kompatible Dienste mit Free Tier wie Cloudflare R2 in Betracht ziehen
Anwendungsfälle
- CI/CD-Integrationstests: Eine MySQL-kompatible Umgebung real ausführen, testen und danach beenden
- Temporäre Demos: Schnell eine teilbare Datenbankinstanz für kurze Zeit bereitstellen
- Kurzfristige Entwicklungsaufgaben: Tests in einer echten Datenbankumgebung ohne laufenden Wartungsaufwand
- Nicht empfohlene Anwendungsfälle:
- Langfristiges Datenbank-Hosting
- Einen ständig aktiven öffentlichen Datenbank-Endpunkt aufrechterhalten
- Die GitHub-Actions-Nutzungsrichtlinien umgehen
- Wichtig: GitHub Actions ist keine Plattform für dauerhafte Services, sondern für CI/CD konzipiert. Wenn langfristiges Datenbank-Hosting benötigt wird, sollte die Einrichtung eines Self-Hosted Runners in Betracht gezogen werden
13 Kommentare
Das wirkt auf mich wie eine nicht beabsichtigte Nutzung. Nur weil etwas technisch möglich ist, sollte man bewusst keine Methode verwenden, die nicht empfohlen wird.
Es steht dort ja als „Trick, um Kosten- und Komplexitätsprobleme beim Betrieb einer Datenbank für Entwicklung und Tests zu lösen“ — wer über gesunden Menschenverstand verfügt, wird das schon richtig einordnen.
Wenn man an Hyrums Gesetz (https://www.hyrumslaw.com/) denkt,
ist das vermutlich eine Methode, auf die früher oder später irgendjemand kommen könnte.
Aber wie andere hier schon sagen, bringen solche Fehl- und Zweckentfremdungen letztlich noch größere Unannehmlichkeiten mit sich.
Wenn GitHub Actions im GitHub-Free-Tier erst einmal verschwunden sind … ah … dann merkt man erst, dass das doch etwas Gutes war …
Ich halte das nicht für Missbrauch.
Wie stark belastet es einen Server schon, eine Datenbank zu starten … Und laut dem Artikel wird sie ja auch nur kurzzeitig gestartet.
Es scheint problematisch zu sein, dass hier nicht im CI-Prozess eine Test-DB gestartet wird, sondern der Workflow absichtlich verzögert wird, um daraus eine gehostete DB zu machen. Auch die Definition von „kurzzeitig“ ist unklar.
„Nur dann, wenn es als Teil einer CI/CD- oder Test-Workflow benötigt wird“, oder?
Für zahlende Nutzer dürfte das doch in Ordnung sein, oder?
Schließlich nutzt man es ohnehin innerhalb des vorgegebenen Kontingents.
Alles darüber hinaus wäre dann kostenpflichtig.
https://docs.github.com/en/site-policy/…
Ich weiß nicht, wie weit der Spielraum von „okay“ reicht, aber in der Dokumentation steht ausdrücklich, dass die Nutzung nur zum Zweck des Programmtestens empfohlen wird, solange nicht klar angegeben ist, ob dafür Gebühren anfallen. Und natürlich hat GitHub bei Missbrauch des Dienstes das Recht, den Account zu kündigen.
Haha, echt witzig. Wie viel könnte man damit wohl sparen..
Das ist Missbrauch. Ich denke, dass damit Ressourcen zweckentfremdet werden, die in dem Maß, in dem sie durch ein solches Verhalten verbraucht werden, eigentlich guten Privatpersonen und Open Source zugutekommen sollten, dass dadurch die Betriebskosten von GitHubs kostenlos bereitgestellten Diensten steigen und diese am Ende auf alle umgelegt werden.
Wie damals, als man mit Actions Krypto-Mining betrieben hat, wird die Politik wohl nach und nach verschärft werden, wenn solche Verhaltensweisen zunehmen.
Um Tunneling zu verhindern, müsste man den Outbound-Verkehr einschränken, wodurch normale Nutzer immer stärker beeinträchtigt würden.
Ich stimme zu.
In den Hacker-News-Kommentaren gibt es Kritik, dass das an sich schon Missbrauch sei.
https://news.ycombinator.com/item?id=42397167
Der Beitrag ist bereits öffentlich, und ich poste ihn hier einfach mal auf dem Niveau von: Ach, so etwas ist also möglich?