@pfaffman Si vous jetez un œil aux modifications que j’ai apportées, je n’ai pas changé les instructions du modèle web dans discourse_docker, je les ai simplement séparées en 3 fichiers, et c’est en fait la seule chose que j’ai demandée : l’un d’eux exécute des instructions indépendantes de l’environnement, comme l’installation des gems Ruby, des dépôts de Discourse et des plugins, etc., un autre effectue certaines validations et le troisième gère des éléments spécifiques à l’environnement, comme la migration de la base de données et la précompilation des assets.
La complexité que cela ajoute, selon moi, c’est que lorsqu’un élément est ajouté dans ces fichiers, l’équipe de Discourse doit déterminer s’ils sont ou non spécifiques à l’environnement (par exemple, s’ils dépendent de données dans la base de données), et, sur cette base, définir dans quel fichier ils doivent être inclus.
L’installation officielle fonctionnerait exactement comme aujourd’hui, sauf qu’elle inclurait les 3 modèles dans le fichier app.yml (ou ferait en sorte que le fichier templates/web.template.yml inclue ces 3 modèles, si cela est possible, et dans ce cas, du point de vue de l’utilisateur, rien ne changerait), au lieu de procéder en plusieurs étapes (elle n’aurait pas les avantages de l’installation en deux étapes, mais fonctionnerait exactement comme actuellement, donc aucune rupture de compatibilité).
Je sais que les tâches d’administration système peuvent être très complexes, mais j’ai essayé de les rendre aussi simples que possible, en tenant compte de la méthode actuelle, pour éviter d’ajouter trop de complexité (c’est pourquoi je n’ai pas parlé de Kubernetes, de séparation des services dans un fichier docker-compose, ou de choses similaires, car cela nécessiterait de grands changements, et je me suis plutôt basé sur la façon dont c’est fait dans l’installation officielle).