Comment mettre à niveau Discourse dans une configuration multi-conteneurs ?

Bonjour ! Je viens de mettre en place une installation Discourse multi-conteneurs fraîche et je me demande quelle serait la meilleure méthode de mise à niveau.

La documentation indique :

Minimisez les temps d’arrêt lors de la mise à niveau vers de nouvelles versions de Discourse. Vous pouvez amorcer de nouveaux processus web pendant que votre site est en cours d’exécution et ne basculer vers la nouvelle image qu’une fois celle-ci construite.

En lisant cela, je me demande si cela signifie qu’il est sûr d’exécuter une version précédente de Discourse en direct pendant que l’autre conteneur se met à niveau ?

Par exemple :

Imaginons que j’ai deux conteneurs uniquement web en cours d’exécution sur des VM distinctes derrière un équilibreur de charge. Je retire l’une des instances de conteneur de l’équilibreur de charge et j’exécute l’amorçage sur la dernière version. L’ancienne version reste toujours en service pour un temps d’arrêt nul (est-ce acceptable ?). Ensuite, je rétablis le conteneur mis à jour dans l’équilibreur de charge et je répète le processus sur l’autre conteneur.

Cela semble correct, n’est-ce pas ?

1 « J'aime »

C’est à peu près exact. Pour des mises à jour sans interruption de service, vous devez initialiser le nouveau conteneur avec SKIP_POST_DEPLOYMENT_MIGRATIONS: 1, puis le lancer. Une fois que les anciens conteneurs ne sont plus en cours d’exécution, exécutez SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate. Sinon, l’initialisation peut (mais pas systématiquement à chaque mise à jour) placer la base de données dans un état incompatible avec l’ancien conteneur.

1 « J'aime »

Oh, c’est génial ! Les migrations de base de données étaient exactement ce qui m’inquiétait, alors c’est utile de savoir comment les contrôler !

2 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.