Je pense qu’ils en ont 
Attendez que cette PR soit fusionnée, puis suivez les étapes indiquées :
Environ 100 Go 
je le ferai
Donc, en réfléchissant à l’automatisation de cette mise à niveau, il me vient à l’esprit que déterminer le moment opportun pour effectuer cette opération de saut de migration post-déploiement est plutôt complexe.
Pour les installations en conteneur unique, sauf en cas de migration bizarre (c’est la première dont j’ai connaissance en quatre ans), il n’y a aucun avantage à procéder de cette manière. La plupart des mises à niveau comportent peu de migrations, et probablement aucune qui soit intensive en calcul.
Pour les installations en deux conteneurs, il est toujours judicieux de définir SKIP_POST_DEPLOYMENT_MIGRATIONS, car vous pouvez désactiver votre site si les migrations cassent le conteneur en cours d’exécution, ce qui atténue l’avantage de pouvoir amorcer le nouveau conteneur pendant que l’ancien continue de fonctionner. MAIS même dans ce cas, toutes les mises à niveau n’incluent pas de migrations qui cassent les choses, de sorte que la solution à deux redémarrages proposée par ce commit (très bienvenu) risque de entraîner plus de temps d’arrêt (deux cycles de redémarrage) que de simplement vivre à la limite.
Ma réflexion actuelle est qu’une meilleure solution consisterait à ce que l’amorçage exécute toujours les migrations avec SKIP_POST_DEPLOYMENT_MIGRATIONS=1, puis effectue une migration au premier démarrage. Je n’ai pas encore de solution élégante pour savoir exactement comment cela pourrait fonctionner. Existe-t-il un moyen rapide de déterminer si des migrations sont en attente ? Je suppose que le script de démarrage pourrait inclure un if migrations en attente, exécuter une migration juste après le démarrage de unicorn ? C’est assez fastidieux, cependant, et probablement inutile pour la plupart des installations la plupart du temps.
Ce n’est absolument pas la peine de le faire la plupart du temps, mais si les mises à jour de votre logiciel prennent rarement (mais parfois) 10 fois plus de temps que d’habitude, c’est un vrai problème pour beaucoup d’utilisateurs.
Après cela, je ne lancerai plus les mises à jour de Discourse avant au moins une semaine après la sortie. Bien sûr, vous pourriez dire que je suis un idiot de ne pas avoir attendu dès le début, que je me l’ai cherché, que je devrais mieux savoir, et tout cela est tout à fait exact ! Pourtant, rendre les temps de mise à jour plus cohérents et prévisibles serait un grand service pour tous les autres idiots qui existent.
Sinon, la mise à jour via l’interface utilisateur par l’intermédiaire de docker_manager gère cela automatiquement.
C’est génial ! Je ne mets jamais à jour de cette façon, donc je n’aurais jamais pensé à cette possibilité. Merci.
Désolé, pour être clair, si nous ajoutons cette variable d’environnement à notre conteneur d’application :
Soit :
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
ou
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
Lorsque nous exécutons le lanceur, cela sautera-t-il toutes les migrations de base de données lors de la reconstruction ?
Est-ce la bonne compréhension ?
Pas tout à fait. Voir Introducing Post Deployment Migration
Bonjour, j’ai réussi à tout mettre à jour avec cette méthode (c’est-à-dire via l’interface utilisateur), mais ensuite cela lance une opération de déploiement avec des instructions de migration (celles qui avaient été ignorées depuis le début) et ainsi de suite, ce qui finit par planter après un certain temps, en indiquant que la mise à niveau a échoué. Cependant, le forum fonctionne normalement et le tableau de bord administrateur affiche tout comme étant mis à jour.
Ma question est la suivante : dois-je faire autre chose ? Plus précisément concernant cette opération de déploiement, dois-je l’exécuter en ligne de commande (pour éviter le plantage) ? Y a-t-il des commandes spécifiques à utiliser et cela va-t-il interrompre le forum pendant son exécution ?
Avez-vous toujours les journaux pertinents ? Vous devez exécuter les migrations, sinon la recherche sera dysfonctionnelle sur le site.
./launcher enter app
bundle exec rails db:migrate
Pas de journaux, mais il s’agissait des mêmes requêtes mentionnées précédemment dans ce sujet.
Avant de lancer ce processus et de le laisser s’exécuter, cela va-t-il temporairement interrompre le site web (comme une reconstruction) ou est-ce « sûr » ? Désolé d’insister sur ce point précis, mais il s’agit d’un site de production et une interruption de 10 à 15 minutes est acceptable, tandis qu’un ou deux jours ne le sont pas et doivent être soigneusement envisagés si aucune autre option n’est disponible.
Si vous avez déjà mis à niveau vers la dernière version, l’exécution des migrations n’entraînera aucune interruption de service sur votre site. Par « mis à niveau », j’entends que la nouvelle version a été déployée, mais que la migration post-déploiement décrite dans ce sujet a échoué.
Merci. J’ai fini par revenir aux mises à jour via l’interface utilisateur, j’ai essayé une nouvelle fois et les migrations de base de données post-déploiement ont finalement été appliquées. Cela a pris plusieurs heures (et beaucoup de CPU 
), mais elles ont été terminées et tout est maintenant entièrement mis à jour ! 