Pour être honnête, je dois commencer par préciser que je suis nouveau sur la plateforme et dans la base de code, et je n’ai donc aucune idée du fonctionnement actuel de rebuild en coulisses. Cependant, ma compréhension actuelle est que rebuild :
arrête le conteneur actuel
construit un nouveau conteneur avec les données de l’arbre source
attend que vous démarriez le nouveau conteneur
D’un point de vue DevOps, pourquoi ne pas pouvoir construire le nouveau conteneur (peut-être dans une autre branche ou un répertoire temporaire) pendant que l’ancien est toujours en cours d’exécution ? Cela semble rendre le remplacement du nouveau conteneur par l’ancien beaucoup plus rapide (du moins en termes de temps d’arrêt), peut-être de l’ordre de quelques secondes plutôt que de plusieurs minutes.
Si les conteneurs utilisent des volumes de stockage qui ne sont pas détruits lors de la reconstruction du conteneur, je ne suis même pas certain que les modifications de configuration ou de base de données (par exemple, de nouveaux messages) doivent être traitées spécifiquement pour ce cas d’usage, ce qui signifie que la construction du conteneur ne devrait pas être aussi étroitement couplée à son état.
Est-ce simplement une question sur laquelle personne n’a encore porté son attention, ou existe-t-il une décision architecturale existante qui impose l’arrêt d’un conteneur avant qu’un autre puisse être construit ?
Rebuild est une mise à jour polyvalente qui peut :
Mettre à jour le code source de Discourse
Mettre à jour les dépendances au niveau du système d’exploitation, comme la version majeure de Ruby
Passer à des versions plus récentes et incompatibles de PostgreSQL, en prenant en charge la mise à jour du format du disque de données pour la nouvelle version
Mettre à jour l’image Docker. Par exemple, plus tôt cette année, nous sommes passés d’Ubuntu 16.04 à la dernière version de Debian, et tout est transparent pour l’utilisateur : il suffit de taper ./launcher rebuild app.
Les rebuilds ne sont pas nécessaires en permanence ; ils ne sont obligatoires que quelques fois par an lors de mises à jour majeures de dépendances. Pour toutes les autres mises à jour, vous pouvez effectuer des mises à jour sans temps d’arrêt en cliquant sur le mise à jour web dans l’interface d’administration.
Pour plus de points liés au “devops”, vous pouvez consulter :
Je peux me tromper, mais je pense que la question de @CodeGnome concernant les reconstructions sans temps d’arrêt mérite encore d’être approfondie.
Si je comprends bien Docker, les aspects suivants de Discourse pourraient être reconstruits en arrière-plan dans un nouveau conteneur pendant que l’ancien continue de fonctionner :
Mise à jour du code source de Discourse
Mise à jour des dépendances au niveau du système d’exploitation, comme la version majeure de Ruby
Mise à jour de l’image Docker. Par exemple, plus tôt cette année, nous sommes passés d’Ubuntu 16.04 à la dernière version de Debian, et tout est transparent pour l’utilisateur : il suffit de taper ./launcher rebuild app.
En ce qui concerne les changements cassants au niveau de PostgreSQL, c’est plus délicat en raison du volume de données, qui, je suppose, est partagé entre l’ancien et le nouveau conteneur.
Peut-être que le site pourrait être mis en mode lecture seule au début de la reconstruction, l’ancien conteneur conservant son volume existant, tandis que la base de données en cours de construction fonctionnerait dans un nouveau volume Docker ?
Concernant la mise à jour de la source de Discourse, des dépendances au niveau du système d’exploitation, de l’image de base Docker, des gems Ruby et autres, il est possible de le faire en construisant en deux étapes et en exécutant les tâches susmentionnées lors de la première étape.
Cette première étape est agnostique à l’environnement et pourrait même être exécutée dans un environnement CI (vous pourriez ainsi utiliser une image presque identique dans les environnements de staging et de production, évitant ainsi les erreurs potentielles dues à une reconstruction à des dates différentes, sans parler de la réduction des temps d’arrêt).
Les tâches de migration de la base de données et de assets:precompile devraient toujours être exécutées sur la machine cible. La migration de la base de données est dans la plupart des cas rapide. En revanche, la tâche assets:precompile pose problème car c’est l’étape qui prend le plus de temps. Je pense que c’est parce que certains assets ont besoin de connaître des informations environnementales définies dans la base de données, comme certaines règles CSS, pour s’exécuter.
Ce serait extrêmement avantageux si cette tâche pouvait être divisée en deux : d’abord compiler tous les assets qui ne dépendent pas de l’environnement, ce qui pourrait être fait dans un environnement CI, puis, lors de la deuxième étape, compiler uniquement les assets qui dépendent de données dans la base de données, etc. Cela dit, je ne sais pas à quel point ce serait techniquement difficile à mettre en œuvre.
Je discute de l’amorçage du conteneur de l’application en deux étapes dans le sujet suivant :
Les modifications que j’ai apportées concernaient uniquement la division du modèle web de Discourse en trois fichiers, mais les tâches restent les mêmes. Cependant, il serait préférable que l’équipe de Discourse prenne en charge cette approche afin que je n’aie pas besoin de les mettre à jour en raison de futures modifications du modèle web.