Nous avons créé un dépôt appelé RPS Discourse Image Builder qui est utilisé pour créer une image Discourse OCI. Je pense que cela pourrait être utile à certaines personnes qui cherchent des solutions. Nous l’avons principalement fait pour ne plus avoir à attendre le déploiement de Discourse, qui est long, et pour pouvoir épingler les versions de Discourse de manière fiable.
Nous avons écrit un script qui utilise le dépôt discourse_docker pour construire l’image avec la version stable de la manière la plus générale possible.
Il existe également un fichier docker-compose qui met en place les bases de données nécessaires à la construction et l’image Discourse pour les tests, et qui l’exécute pour le développement local. Cela peut fonctionner sur un GitLab runner avec l’exécuteur shell, mais vous avez besoin d’un système avec une version de docker-compose qui prend en charge les profils.
Approche
Le script de construction doit être exécuté dans nos pipelines CI/CD afin que nous puissions facilement mettre à jour la version, de sorte que d’autres ajustements soient effectués dans différents dépôts avec des Dockerfiles basés sur l’image créée par ce dépôt.
Contexte
Discourse est un logiciel très agréable, mais il n’est pas très facile à déployer et à épingler en version. Ce dépôt est utilisé pour créer une image docker qui peut être utilisée pour déployer Discourse.
Le problème est que Discourse a une manière très unique de construire ses images docker. Les développeurs de Discourse s’attendent à ce que vous construisiez l’image sur la machine cible avec leur dépôt discourse_docker.
Il y a eu de longues discussions à ce sujet sur le forum, en résumé : les principaux développeurs de Discourse refusent de prendre en charge une image Docker publique qui peut être utilisée pour déployer Discourse. Ils veulent que le dépôt discourse_docker reste la seule méthode officielle pour déployer Discourse.
Les principaux inconvénients de cette approche sont :
Il n’est pas possible, d’après notre expérience, d’épingler Discourse de manière fiable.
La construction de l’image prend beaucoup de temps et, une fois l’image construite, le service n’est pas disponible. De plus, Discourse a le cycle d’itération DevOps le plus long de tous les services que nous prenons en charge.
Les bases de données sont gérées différemment que pour les projets classiques basés sur Docker.
La stratégie de déploiement officielle de Discourse est incompatible avec les flux de développement et de déploiement basés sur OCI, tels que Kubernetes ou même Docker-Compose.
Le lanceur discourse_docker fait de nombreuses suppositions sur l’environnement dans lequel il s’exécute. Par exemple, il refuse de s’exécuter sur Podman sans root avec une erreur concernant des volumes de stockage manquants, sans possibilité de contourner cela avec un argument ou une variable d’environnement.
C’est vrai, nous essayons de le rendre convivial pour les webmasters du type « faites glisser et déposez le contenu de ce fichier zip avec FileZilla via FTP », tout en garantissant que tout le monde exécute des versions récentes, prises en charge et corrigées de tous les logiciels de la pile, y compris leurs bases de données.
Oui, le flux basé sur le lanceur n’est pas compatible immédiatement avec l’orchestration de conteneurs. Cela dit, il peut être rendu compatible en exécutant ./launcher bootstrap app et en poussant l’image résultante vers un registre de conteneurs, puis en exécutant ladite image via l’orchestration.
Nous accueillons une pull request pour rendre cela possible, car cela semble utile en général. pr-welcome
C’est parce que Discourse 2.8 n’est plus pris en charge, ce qui signifie que nous n’avons pas rétroporté la dernière version de Ruby, et qu’elle s’exécute sur une version de Ruby qui est déjà en fin de vie (EOL). Personne ne devrait l’utiliser en production.
Même ainsi, ce n’est même pas techniquement possible (en changeant simplement le paramètre de version), nous ne pouvons donc plus reproduire les anciens environnements.
Vous référencez littéralement l’ancienne image de base (créée approximativement à la date de la version que vous ciblez - elle doit évidemment être plus récente)
Mais si vous essayez d’épingler à une version trop ancienne, elle pourrait ne pas fonctionner avec les versions mises à jour de l’image de base de Discourse. Je ne me souviens pas d’exemples précis, mais des choses comme une ancienne version de Discourse ne fonctionneront pas avec Ruby 3.2, vous devrez donc (parfois) également épingler discourse_docker si vous épinglez une ancienne version de Discourse.
La solution la plus sûre et, dans la plupart des cas, la moins coûteuse est de construire une image et de la pousser vers un dépôt plutôt que de construire une nouvelle image à chaque déploiement. Et si vous avez des plugins, vous devrez probablement également épingler chacun d’eux.
Je l’ai fait pour plusieurs clients pour ECS ainsi que pour k8s sur GCP et AWS.
Je suis à peu près sûr que vous le pouvez si vous épinglez également discourse_docker à l’ancienne version. Comme je l’ai mentionné ci-dessus, c’est plus compliqué avec les plugins, car vous devrez probablement les épingler également aux anciennes versions. Si vous voulez vraiment maintenir les anciennes versions, les construire exactement une fois et les pousser vers un dépôt est la meilleure solution. Je le fais avec un client pour tester les chemins de mise à niveau de la production actuelle vers la dernière version et cela fonctionne sans problème.
