# Mise à niveau auto-hébergée vers 3.1.0.beta2 avec une installation typique multi-conteneurs nécessite un temps d'arrêt supplémentaire **URL:** \ **Category:** Self-hosting\ **Created:** [Janvier 25, 2023, 8:31 UTC](https://meta.discourse.org/t/self-hosted-upgrade-to-3-1-0-beta2-with-typical-multi-container-install-requires-extra-downtime/252916 "2023-01-25T20:31:40Z")\ **Posts on this page:** 1\ **Showing post:** 18
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [Janvier 26, 2023, 3:54 UTC](https://meta.discourse.org/t/self-hosted-upgrade-to-3-1-0-beta2-with-typical-multi-container-install-requires-extra-downtime/252916/18 "2023-01-26T03:54:29Z")
> [@supermathie](#): > > Je soupçonne qu’un très petit nombre d’utilisateurs effectuent des déploiements blue/green multi-conteneurs, mais nous serions ouverts aux suggestions sur la façon de le faire. Le script Ansible que [dashboard.literatecomputing.com](http://dashboard.literatecomputing.com) utilise exécute une tâche Rake après le lancement du nouveau conteneur pour effectuer les migrations post-déploiement. Il compte sur l’activation de `SKIP_POST_DEPLOYMENT_MIGRATIONS` dans web\_only.yml. Je ne le fais que sur les sites que je sais être gérés par mes scripts, car si vous ne comprenez pas comment cela fonctionne, cela peut être une bombe à retardement. Notez que pour de nombreuses mises à niveau, l’amorçage du nouveau conteneur ne brisera pas le conteneur en cours d’exécution, mais pour certaines, cela le fait. Il n’est pas rare qu’une mise à niveau migre de telle sorte que l’ancien conteneur ne puisse pas utiliser la base de données (sans utiliser SKIP\_POST\_DEPLOYMENT\_MIGRATIONS). --- _[View the full topic](https://meta.discourse.org/t/self-hosted-upgrade-to-3-1-0-beta2-with-typical-multi-container-install-requires-extra-downtime/252916)._