J’ai mis à jour mes sites de la version 3.1.0.beta1 à la version 3.1.0.beta2, et après avoir amorcé la nouvelle version, mais avant de détruire les anciens conteneurs d’applications et d’en démarrer de nouveaux, au moins un de ces sites a commencé à afficher la page d’erreur générique aux utilisateurs.
Je ne l’ai pas remarqué sur mon site de test ou sur les autres sites que j’administre, mais il est possible que cela se soit produit et que je ne l’aie pas vu.
Dans tous les cas, pour moi, dans au moins un cas, le processus de mise à jour « sans interruption de service » n’a pas réussi.
(J’utilise app pour l’application web, même pour les installations multi-conteneurs. Je sais que ce n’est pas la pratique normale. Je déteste taper web_only)
Un certain temps après avoir lancé bootstrap et avant d’avoir détruit l’application, l’ancienne version fonctionnant avec la nouvelle base de données n’affichait qu’un écran d’erreur. Je ne me souviens pas de son contenu, et je n’ai pas prolongé l’interruption en m’arrêtant pour prendre une capture d’écran avant de détruire/démarrer, mais c’était juste du texte sur fond blanc et ce n’était pas la page de maintenance du système. J’ai vu cela seulement quelques fois auparavant, lorsque le bootstrap exécute db:migrate dans le cadre de la reconstruction asynchrone “sans interruption de service”, le vieux logiciel encore en cours d’exécution échoue en raison d’une incohérence de schéma.
Ce que j’ai vu, c’est ce qui se passe en cas d’incohérence de la base de données. C’est bien mieux que de continuer tranquillement, en cassant la base de données ! Lorsque j’ai posté, c’était pour avertir que c’était l’un de ces rares cas où l’application d’une mise à jour ponctuelle (ici de 3.1.0.beta1 à 3.1.0.beta2) créait une incompatibilité de schéma entre le code 3.1.0.beta1 et la base de données après l’exécution de db:migrate de 3.1.0.beta2, comme cela arrive rarement mais occasionnellement avec les mises à jour normales à faible interruption de service dans le déploiement multi-conteneurs.
Mon expérience est différente de l’erreur signalée avec Ruby dans le programme de mise à jour graphique. C’est un problème complètement indépendant. Je reconnais que mon message a été déplacé de l’annonce vers un fil général “problèmes avec”, mais je tiens à préciser que la raison pour laquelle je l’ai posté dans l’annonce était d’avertir d’autres auto-hébergeurs comme moi lorsqu’ils verraient l’annonce que cette mise à jour particulière pouvait avoir cet impact.
Mon message ne se plaignait pas d’un bug, ni même d’un problème. Il était uniquement destiné à signaler un cas normal mais peu fréquent associé à cette version particulière et non mentionné dans les notes de version.
Les plaintes concernant le gestionnaire docker ne reconnaissant pas qu’il ne peut pas se mettre à jour depuis l’intérieur de l’image sont complètement sans rapport avec ma tentative de fournir une notification utile aux autres administrateurs auto-hébergés.
Il serait très judicieux de séparer ces problèmes non liés en fils de discussion indépendants pour des problèmes indépendants. EDIT par @supermathie : Fait
Ce modèle est essentiel si vous effectuez par exemple un déploiement bleu/vert et que vous avez besoin que la version précédente continue de fonctionner.
Je pense que cela répond à la question. Le script launcher ne prend pas en charge SKIP_POST_DEPLOYMENT_MIGRATIONS.
Encore une fois, je ne signale pas de bug. J’essaie simplement d’avertir les autres qui utilisent l’installation standard multi-conteneurs en suivant le processus normal documenté pour utiliser launcher avec une installation multi-conteneurs que celle-ci diffère de leur expérience habituelle.
Vraiment, sincèrement, honnêtement, je le pense, ce n’est pas un rapport de bug !
Si je veux un déploiement bleu/vert avec launcher, je devrais fournir une PR pour que launcher l’implémente.
Je n’ai pas inventé le « problème » dans le titre du sujet ; cela a été fait lorsque mon commentaire a été déplacé hors du fil d’annonce. J’ai maintenant modifié le titre pour indiquer clairement, je l’espère, que je ne me plains pas d’un problème.
Je soupçonne qu’un très petit nombre d’utilisateurs effectuent du blue/green multi-conteneurs, mais nous serions ouverts aux suggestions sur la façon de le faire.
Et aussi, comment trouver le sujet que j’ai lié ; je soupçonne qu’il n’est pas facile à trouver si l’on ne sait pas déjà qu’il existe.
J’avais vu la documentation SKIP_POST_DEPLOYMENT_MIGRATIONS. Ce que j’avais vraiment manqué, c’est cette publication qui montre comment effectuer des déploiements sans interruption avec launcher :
J’ai eu beaucoup de mal à m’en préoccuper alors que je fournis quatre, parfois quatre et demie, neuf de disponibilité sur un service que j’exploite gratuitement pendant mon temps libre. C’est un témoignage de la qualité du développement de Discourse que je puisse le faire avec une politique de tests réussis, y compris des choses comme la minute supplémentaire d’indisponibilité que j’ai constatée cette fois-ci, et parfois le redémarrage de l’hôte pour les mises à jour de sécurité.
Le script Ansible que 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).
