Kuby-core: Unterstützt aktuelle Versionen von kubedb

Ok, etwas zusätzlicher Kontext hier. Es stellt sich heraus, dass der schwierige Teil nicht darin besteht, eine Lizenz programmgesteuert abzurufen (was möglich ist, wir müssen die Leute nur nach einem Lizenzserver-Token, einer E-Mail-Adresse usw. fragen). Der schwierige Teil besteht darin, den kubedb-Operator und einzelne Datenbanken zu _aktualisieren_. Die Deinstallation von v0.12 ist an sich schwierig, da Sie offensichtlich keine vorhandenen Datenbankinstanzen herunterfahren möchten, aber ich habe es schließlich zum Laufen gebracht. Glücklicherweise ist die Installation von v0.18 (der neuesten Version zum Zeitpunkt des Schreibens dieses Artikels) mit Helm ziemlich einfach ... aber es ist verdammt schwer, eine vorhandene Postgres- oder MySQL-Instanz zu aktualisieren, die _bereits_ läuft (ohne Ausfallzeit). Hier sind die Schritte, die ich (fast) für Postgres gearbeitet habe:

1. Stellen Sie sicher, dass die vorhandene Datenbank für die logische Replikation eingerichtet ist, was eine Änderung der WAL-Ebene (Write-Ahead-Protokoll) erfordert. Das Festlegen des WAL-Levels erfordert einen pg-Neustart. Der einfachste Weg, dies zu tun, besteht darin, die Anzahl der Replikate auf > 1 festzulegen und gleichzeitig kubedb anzuweisen, zusätzliche Konfigurationen zu verwenden, was zu einem Neustart führt. Sie möchten ohnehin mehrere Replikate, damit Neustarts nicht zu Ausfallzeiten führen.
2. Deinstallieren Sie die alte Version des kubedb-Operators und installieren Sie die neue, wobei Sie besonders darauf achten, dass Ihre vorhandenen Datenbankinstanzen nicht heruntergefahren werden. Dies kann ein wenig schwierig sein, da k8s die Postgres -CRD nur ungern löscht, wenn noch Postgres-Instanzen ausgeführt werden. Macht Sinn. Glücklicherweise gibt es Möglichkeiten, k8s dazu zu bringen, das zu tun, was Sie wollen.
3. Richten Sie eine neue Postgres-Instanz mit WAL = logical ein und erstellen Sie den erforderlichen Pub/Sub zwischen dem alten und dem neuen, sodass alle Datensätze in der alten Datenbank in die neue Datenbank kopiert werden. Achten Sie darauf, dem Benutzer postgres in der neuen Datenbank ein Passwort zu geben, wenn der Benutzer, mit dem Sie von Rails aus auf die Datenbank zugreifen, _nicht_ postgres ist (Kuby verwendet standardmäßig root ). . Dies ist notwendig, da ich glaube, dass es sich um einen Fehler in den Init-Skripten von kubedb handelt. Diese neue Datenbank muss offensichtlich einen anderen Namen haben als die alte, was ein Problem darstellt. Der Name der Datenbank bestimmt den DNS-Namen, mit dem Rails verbunden sind, den wir nicht wirklich ändern können. Hmm...
4. Stellen Sie die Rails-App bereit und richten Sie sie irgendwie auf den neuen Datenbankdienst aus.
5. Löschen Sie die alte Datenbank
6. Profitieren

Ich stecke derzeit fest und versuche herauszufinden, wie ich die Rails-App einfach auf den neuen Datenbankdienst verweisen kann. Die Dienst-URL ist im Wesentlichen fest codiert und kann sich nicht dynamisch ändern. Außerdem kann der neue Datenbankdienst nicht denselben Namen wie der vorhandene haben, also müssten wir den "richtigen" irgendwo speichern (vielleicht eine Anmerkung zum Deployment?) Und ihn bei jedem ... Docker-Build konsultieren, weil dann schreiben wir die database.yml neu? PFUI.

Eine andere Lösung könnte darin bestehen, eine Art Proxy zu verwenden, der den Datenverkehr dynamisch auf den einen oder anderen Dienst lenkt, wie ein Load Balancer, aber zusätzlich zu den Diensten.

Während kuby einige knifflige Dinge tun könnte, um automatisch eine Lizenz zu erhalten, fühlt sich das nicht besonders moralisch (oder vielleicht sogar legal?)

Tamal ist ein guter Kerl und ich glaube nicht, dass es ihm überhaupt etwas ausmachen wird, solange Sie den Benutzern die Details darüber offenlegen, was passiert, damit sie nicht überrascht sind, wenn die temporäre Lizenz am Ende des Monats abläuft. (? Was passiert, wenn die Lizenz abläuft, frage ich mich jetzt? Wenn es bedeutet, dass Backups gestoppt werden, könnte das schlecht sein; wenn es bedeutet, dass andere Dinge fehlschlagen, könnte es auch schlecht sein ... wenn es bedeutet, dass Sie einfach keine neuen Datenbanken erstellen können für jetzt, bis die Lizenz verlängert wird, ist das vielleicht nicht so schlimm.)

Es gibt bereits eine Option für externe Datenbanken, sodass Benutzer die Möglichkeit haben, mit KubeDB fortzufahren oder Datenbanken auf andere Weise selbst in die Hand zu nehmen, was heute ehrlich gesagt kein schwieriges Problem ist, es sei denn, Sie verwenden keinen Cloud-Anbieter, der diese Art von unterstützt Datenbank, die Sie benötigen.

Vielen Dank für die Anleitung, was für ein Upgrade erforderlich ist! Ich habe eine Lizenz für meine KubeDB, die Team Hephy großzügig für unseren Produktionscluster gewährt wird, und ich habe ältere Datenbanken, die aktualisiert werden müssen, die nie von KubeDB gestartet oder gehostet wurden; Ich habe die Lizenz, um zu lernen, wie man die Datenbanksicherungen verwendet, ich habe sowohl PostgresQL als auch MariaDBs, tl;dr Ich habe auch in diesem Bereich viel zu tun.

Ich lerne gerade, wie man einen richtigen Speicher-CSI-Treiber mit meinem Home-Lab-Cluster betreibt, und ich gehe davon aus, dass dies einen großen Unterschied bei der Handhabung von Datenbanken machen und die Disaster-Recovery-Eigenschaften meines "Produktions" -Clusters verbessern wird. 🎉

Kuby könnte sich langfristig auch als großartiger Verkaufsvektor für KubeDB erweisen. Ich weiß nicht, wie du darüber denken wirst!