Déploiement Blue Green avec une base de données unique
J'essaie d'analyser la stratégie de déploiement bleu vert pour fournir des mises à niveau sans temps d'arrêt pour nos clients. Nous avons une entreprise Java qui utilise Oracle comme magasin de données. Il y a quelques défis que j'aimerais obtenir des contributions d'experts
Avec tous les types d'objets de base de données (procédures, tables, index, contraintes, etc.), nous avons besoin d'une gestion spéciale, la plupart d'entre eux sont indiqués ici . Cela nécessite finalement une gestion fine du code pour chaque cas d'utilisation.
Avec les déploiements bleu vert, comment traitons-nous les sessions Web des utilisateurs actifs? Détectons-nous les événements de fermeture de session?
L'effort de mise en œuvre d'une telle approche nécessite du temps (environ un an comme le suggère le message) et un soin particulier pour nous assurer de bien faire les choses. Existe-t-il des alternatives plus simples et meilleures à cela?
Merci!
Load Balancer
Pour le deuxième point, utilisez un équilibreur de charge approprié. Vous pouvez transférer une partie du trafic, d'abord pour prouver le nouveau déploiement, puis pour l'augmenter lentement. Il permet également une stratégie de retrait rapide.
versionnage de la base de données
Il y a deux façons d'aborder cela:
- Rendre la forme de données autorisée (le schéma SQL) rétrocompatible entre les versions vertes/bleues (toute ancienne version du schéma/procs/etc peut être abandonnée/supprimée/vidée).
- Déplacez la source faisant autorité des données ailleurs et traitez le schéma SQL comme une vue mise à jour dynamiquement. Reconstruisez simplement cette vue sur chaque déploiement avec tous les procs/schema/etc ont un préfixe de version quelconque.
Dans la première méthode, il peut être judicieux de distancer votre application de la représentation des données et de déplacer tous les transferts de données via les procédures stockées. Cela garantit une interface propre qui peut être portée vers l'avant. Cela permet au chemin de migration d'être comme:
- Créez de nouveaux types/tables et ajoutez de nouvelles colonnes aux tables actuelles, effectuez tout nettoyage de l'ancienne version.
- Déployez des procédures stockées qui peuvent gérer des structures de données nouvelles et anciennes. Lisez tout, écrivez nouveau.
- Effectuez la migration et le massage des données indispensables au nouveau déploiement.
- Échangez le trafic vers une application fraîchement déployée.
- Effectuez une migration et un massage des données supplémentaires pour les transférer vers la nouvelle structure de données.
- Attendez un déploiement plus récent ou déployez des procédures stockées qui ne peuvent gérer que les nouvelles structures de données.
- sinon attendre effectuer le nettoyage des anciennes données, procs stockés, tables, etc ...
Si cela semble trop complexe ou si la manipulation de données en direct est trop dangereuse, il peut être nécessaire de déplacer la définition de ce qui fait autorité vers une autre source de données. Avec cela, il n'a plus d'importance ce qui est dans le magasin de données SQL (sauf s'il stocke le journal des événements dans ce cas, sauf cette partie). Le déploiement ressemble maintenant à:
- Créez un nouveau schéma, des procs stockés, des types, etc. sous un nouvel espace de noms ou avec un préfixe.
- Analysez le journal des événements à partir du premier enregistrement, mettez à jour le schéma comme il convient.
- Une fois la plupart du temps rattrapé, basculez lentement le trafic vers le nouveau déploiement.
- les utilisateurs de l'ancien déploiement peuvent toujours interagir avec les utilisateurs du nouveau déploiement, tous deux lisent le journal des événements et reçoivent des mises à jour.
- Lorsque vous êtes satisfait que tout le monde est sur le nouveau déploiement et qu'aucune restauration n'est requise, arrêtez l'ancien système.
- supprimer l'ancien schéma, procs, etc ...
Votre application devra saisir deux fois les données, d'abord dans le journal des événements, puis elle devra lire le journal des événements et mettre à jour les données de la table associée. Du côté positif, cela permettra à plusieurs versions du produit de fonctionner ensemble pendant un certain temps au prix d'un travail supplémentaire.