Kuby-core: Prise en charge des versions récentes de kubedb

Ok, un peu de contexte supplémentaire ici. Il s'avère que la partie la plus difficile n'est pas de récupérer une licence par programme (ce qui est possible, nous devons simplement demander aux gens un jeton de serveur de licence, une adresse e-mail, etc.). Le plus dur est de _mettre à niveau_ l'opérateur kubedb et les bases de données individuelles. La désinstallation de la v0.12 est difficile en soi car vous ne voulez évidemment pas supprimer les instances de base de données existantes, mais j'ai finalement réussi à le faire fonctionner. Heureusement, l'installation de la v0.18 (la dernière version au moment d'écrire ces lignes) est assez facile avec Helm... mais bon sang, il est très difficile de mettre à niveau une instance Postgres ou MySQL existante qui est _déjà_ en cours d'exécution (sans aucun temps d'arrêt). Voici les étapes que j'ai (presque) effectuées pour Postgres :

1. Assurez-vous que la base de données existante est configurée pour la réplication logique, ce qui nécessite une modification du niveau WAL (journal d'écriture anticipée). La définition du niveau WAL nécessite un redémarrage de pg, donc le moyen le plus simple de le faire est de définir le nombre de répliques sur > 1 tout en indiquant simultanément à kubedb d'utiliser une configuration supplémentaire, ce qui entraînera un redémarrage. De toute façon, vous voulez plusieurs répliques afin que les redémarrages n'entraînent pas de temps d'arrêt.
2. Désinstallez l'ancienne version de l'opérateur kubedb et installez la nouvelle, en faisant particulièrement attention à ne pas mettre hors service votre ou vos instances de base de données existantes. Cela peut être un peu délicat car k8s est assez réticent à supprimer le CRD Postgres s'il y a encore des instances Postgres en cours d'exécution. Logique. Heureusement, il existe des moyens de tromper les k8 pour qu'ils fassent ce que vous voulez.
3. Créez une nouvelle instance postgres avec WAL = logical et créez le pub/sub nécessaire entre l'ancien et le nouveau afin que tous les enregistrements de l'ancienne base de données soient copiés dans la nouvelle base de données. Veillez à donner à l'utilisateur postgres un mot de passe dans la nouvelle base de données si l'utilisateur que vous utilisez pour accéder à la base de données à partir de rails _n'est pas_ postgres (Kuby utilise root par défaut) . Ceci est nécessaire à cause de ce que je pense être un bogue dans les scripts d'initialisation de kubedb. Cette nouvelle base de données doit évidemment avoir un nom différent de l'ancienne, ce qui pose problème. Le nom de la base de données détermine le nom DNS auquel les rails se connectent, que nous ne pouvons pas vraiment changer. Hmm...
4. Déployez l'application rails et dirigez-la d'une manière ou d'une autre vers le nouveau service de base de données.
5. Supprimer l'ancienne base de données
6. Profit

Je suis actuellement coincé à essayer de comprendre comment pointer facilement l'application Rails vers le nouveau service de base de données. L'URL du service est essentiellement codée en dur et ne peut pas changer de manière dynamique. De plus, le nouveau service de base de données ne peut pas avoir le même nom que l'existant, il faudrait donc stocker le "bon" quelque part (peut-être une annotation sur le déploiement ?) et le consulter à chaque... docker build cuz c'est alors que nous réécrivons le database.yml ? POUAH.

Une autre solution pourrait être d'utiliser une sorte de proxy qui pourrait diriger dynamiquement le trafic vers un service ou un autre, comme un équilibreur de charge mais au-dessus des services.

Bien que kuby puisse faire des choses délicates pour obtenir une licence automatiquement, cela ne semble pas particulièrement moral (ou peut-être même légal ?)

Tamal est un bon gars et je ne pense pas qu'il s'en souciera du tout, tant que vous exposez les détails de ce qui se passe aux utilisateurs afin qu'ils ne soient pas surpris lorsque la licence temporaire expire à la fin du mois. (? Que se passe-t-il lorsque la licence expire, je me demande maintenant? Si cela signifie que les sauvegardes sont arrêtées, cela pourrait être mauvais; si cela signifie que d'autres choses commencent à échouer, cela pourrait également être mauvais ... si cela signifie que vous ne pouvez tout simplement pas créer de nouvelles bases de données pour maintenant, jusqu'à ce que la licence soit renouvelée, ce n'est peut-être pas si grave.)

Il existe déjà une option pour la base de données externe, donc les utilisateurs ont la possibilité de continuer avec KubeDB ou de prendre les bases de données en main d'une autre manière, ce qui n'est franchement pas un problème difficile aujourd'hui, sauf si vous n'utilisez pas un fournisseur de cloud qui prend en charge le type de base de données dont vous avez besoin.

Merci pour la visite guidée sur ce qui est nécessaire pour mettre à niveau ! J'ai une licence pour mon KubeDB, qui est généreusement accordée à Team Hephy pour notre cluster de production, et j'ai des bases de données plus anciennes qui ont besoin de mises à jour, qui n'ont jamais été démarrées ou hébergées à partir de KubeDB ; J'ai obtenu la licence pour apprendre à utiliser les sauvegardes de base de données, j'ai à la fois PostgresQL et MariaDBs, tl; dr J'ai également du pain sur la planche dans ce domaine.

Je viens d'apprendre à utiliser un pilote CSI de stockage approprié avec mon cluster de laboratoire domestique, et je pense que cela fera une énorme différence dans la façon dont je gère les bases de données et améliore les propriétés de récupération après sinistre de mon cluster "de production". 🎉

Kuby pourrait aussi, à terme, s'avérer être un excellent vecteur de vente pour KubeDB. Je ne sais pas ce que vous en penserez !