Je suis de nouveau là pour vous poser une question un peu particulière
Je continue d’étudier comment installer Discourse pour ma communauté interne. Auparavant, j’avais demandé comment installer Discourse avec un Redis externe et un PostgreSQL externe, ainsi que comment gérer le tout dans un cluster Kubernetes. Vous trouverez les détails ici.
Maintenant, j’ai un nouveau doute : on m’a dit que je devrais également créer ma propre image de conteneur à utiliser avec Helm pour le déploiement. Par conséquent, je ne pourrai pas effectuer l’installation en suivant la documentation officielle avec les scripts fournis dans le guide d’installation cloud.
J’ai essayé de construire ma propre image en utilisant la commande bootstrap, mais je n’arrive pas à lancer l’image Docker moi-même, car elle recherche les modèles Ruby et renvoie une erreur.
Est-il possible de lancer l’image de conteneur sans utiliser les scripts fournis ? Je pense avoir besoin d’un peu d’aide, car j’ai essayé d’examiner le script Bash, mais cela semble un peu trop avancé pour moi. J’espérais qu’une autre personne se soit trouvée dans une situation similaire et pourrait me donner quelques conseils.
Pour donner plus de contexte et plus de détails :
J’ai utilisé le script de lancement avec la commande bootstrap pour créer ma propre image avec mes configurations.
Ensuite, la documentation indique qu’il faut exécuter le lanceur avec la commande run pour créer le conteneur à partir de l’image.
En examinant le code du script, j’ai constaté que l’instruction Docker est la suivante :
Mais je n’arrive pas à traduire toutes les variables en une commande que je pourrais exécuter seul sans le script. Ou peut-être que toute cette approche est fausse dès le départ, mais je voulais essayer avant de demander, pour tester si je pouvais résoudre cela sans déranger qui que ce soit.
Lorsque j’essaie d’exécuter l’image Docker moi-même, le conteneur se termine et en examinant les journaux, je vois ceci :
Already up to date.
INFO -- : Loading --stdin
/pups/lib/pups/config.rb:23:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
from /pups/lib/pups/cli.rb:27:in `new'
from /pups/lib/pups/cli.rb:27:in `run'
from /pups/bin/pups:8:in `<main>'
Discourse dépend de PostgreSQL exécuté dans un volume partagé ; de nombreux autres fichiers importants se trouvent dans ce volume partagé (images, fichiers téléchargés, sauvegardes, journaux, etc.).
Si vous maintenez l’intégrité du système de fichiers du volume /shared selon les normes de configuration de Discourse, vous pouvez démarrer et arrêter une image Docker et une application conteneurisée Discourse avec facilité ; cependant, vous ne pouvez pas construire l’application (à ma connaissance) sans les scripts Discourse (sauf si vous effectuez un ingénierie inverse complète des scripts et écrivez votre propre script basé sur les scripts parfaitement fonctionnels et pris en charge), car les scripts sont responsables de la construction d’une SPA EmberJS sophistiquée (technologie côté client) au-dessus de Ruby on Rails (une technologie côté serveur), sans parler de la gestion de la configuration de l’application principale et de tous les plugins. C’est une application assez sophistiquée, pour être honnête.
Oui, vous pouvez démarrer un conteneur Discourse ou créer un conteneur Discourse à partir d’une image Discourse sans aucun script, si (et seulement si) vous avez déjà construit une image Docker Discourse parfaitement fonctionnelle conforme aux normes de configuration de Discourse, y compris les exigences de stockage persistant pour la base de données, les images et les téléchargements, les sauvegardes, les fichiers journaux, etc. Il y a beaucoup de fichiers importants requis pour Discourse dans le volume partagé ; vous ne pouvez donc pas simplement « prendre une image Docker Discourse standard » et la faire fonctionner sans toutes les prérequis mentionnés ci-dessus (et tout n’a pas été mentionné ci-dessus !)
Merci pour votre réponse, c’est très utile J’ai lu hier pourquoi les scripts sont nécessaires dans ce sujet et quelques autres.
Merci encore pour votre explication détaillée, toutes ces informations m’aident à comprendre comment créer mon propre flux de travail conforme aux normes requises
Cela peut être très déroutant pour quiconque n’est (1) pas développeur Ruby on Rails et (2) pas développeur EmberJS.
Fondamentalement, vous construisez une application Ruby on Rails en production et conteneurisée (la technologie côté serveur) qui sert de fondation à une application SPA EmberJS de classe mondiale (l’application principale pour l’utilisateur) ; et par-dessus tout cela, vous bénéficiez d’un système complet de gestion de configuration open source pour tout le code source, maintenu par une équipe très talentueuse et expérimentée de personnes maîtrisant le web, qui codent dans cet environnement depuis longtemps. De plus, vous pouvez également obtenir un hébergement professionnel et un développement personnalisé, le tout au sein de l’écosystème commercial Discourse.
Je viens de tomber là-dessus. Est-ce que vous dites que je ne peux pas exécuter l’application et la base de données sur des hôtes physiquement distincts sans partager absolument rien ?
J’ai lu hier pourquoi les scripts sont nécessaires dans ce