Je tente de configurer Discourse pour mon organisation sur Kubernetes. Cependant, je rencontre quelques problèmes.
Lorsque j’essaie de déployer l’image amorcée sur Kubernetes, il tente d’exécuter des commandes comme git pull pups et git pull discourse, ce qui ne fonctionne pas car je suis sur un réseau privé sans accès à Internet. Par conséquent, le conteneur ne démarre pas. Existe-t-il un moyen de passer ces étapes afin que je puisse déployer ?
Êtes-vous sûr de déployer une image déjà amorcée ? Il semble que vous ayez poussé la mauvaise image vers votre registre.
Ah bon, j’utilise l’image créée par ./launcher bootstrap app
Donc tu dis que l’image finale bootstrapée ne devrait avoir aucune de ces dépendances ?
Non, ce ne sera pas le cas. Après l’amorçage, il y aura une image local_discourse/app. C’est celle que vous devez pousser vers le registre et utiliser ailleurs.
Une dernière question : il semble que j’aie poussé la mauvaise image, ma faute. Donc, après avoir poussé la véritable image, je peux modifier les variables d’environnement lors du déploiement Kubernetes, n’est-ce pas ? Comme DISCOURSE_DB_HOST, etc. ? En effet, j’ai un cluster PostgreSQL séparé et un cluster Redis !
Je connais ce genre de situation. Pas de souci, c’est une erreur très courante. C’est pour cela que j’ai demandé 
Eh bien, c’est compliqué.
Bien que vous puissiez facilement remplacer ces variables en ajoutant les variables d’environnement nécessaires au lancement du conteneur, lors du bootstrap nous exécutons les migrations. Si vous essayez de pointer l’image vers une autre base de données après le bootstrap, le schéma de la base de données sera complètement incorrect. Cela vous placerait bien dans le territoire de l’#installation-non-soutenue.
J’ai déjà une instance de Discourse en fonctionnement, mais elle est déployée sur du matériel nu. Je souhaite la migrer vers Kubernetes et la connecter à la même base de données que celle utilisée par l’instance sur le matériel nu.
Ou, si possible, puis-je relancer le bootstrap avec DISCOURSE_DB_HOST et DISCOURSE_DB_NAME pointant vers la même base de données que celle utilisée par la machine physique ?
Cela devrait fonctionner !
Vous voudrez peut-être arrêter le conteneur Discourse actuel connecté à la base de données pendant cette opération, car les migrations pourraient le faire se comporter de manière erronée.
Si je crée une nouvelle base de données vide et que je l’initialise avec celle-ci, est-il alors possible de migrer les données via l’interface utilisateur (en utilisant l’interface de l’ancienne instance Discourse et celle de la nouvelle instance), par exemple via /admin/backups ? Je souhaite éviter de corrompre l’ancienne base de données, car elle est utilisée par de nombreux utilisateurs.
Vous ne pouvez pas migrer depuis l’interface utilisateur.
Voir Présentation de la migration post-déploiement. Cela vous permet de migrer la base de données afin qu’elle fonctionne à la fois pour l’ancien et le nouveau conteneur, puis d’effectuer les migrations finales après le déploiement.
Eh bien, j’ai essayé ce que vous avez dit (je poussé l’image amorcée), mais il semble que je rencontre toujours la même erreur.
fatal: impossible d'accéder à 'https://github.com/discourse/pups.git/' : Échec de la connexion à github.com port 443 : Délai d'attente de la connexion dépassé
Je suis sur un réseau privé et je ne peux donc pas accéder à github.com.
Cela signifie que vous avez de nouveau poussé la mauvaise image.
Je modifierais le fichier interne /etc/hosts pour imiter les ressources que vous souhaitez… puis j’ajouterais ce qui est nécessaire.
Encore plus simple… installez un modem/routeur avec une connexion 4G / SIM. Faites en sorte que le réseau reconnaisse cet appareil comme le routeur par défaut de votre réseau interne… connectez-vous… effectuez le travail… déconnectez-vous.
C’est assez simple.
Salutations
Keith John Hutchison - Ceiteach Seán Mac Úistin
Bringing Data to Life Pty. Ltd. (BD2L)
Cette fois, je suis assez certain 
Est-il possible qu’une erreur se produise lors de
./launcher bootstrap app
De plus, j’ai même essayé d’utiliser l’image actuelle de Discourse, qui s’exécute sur du bare metal et héberge notre site Discourse actuel, et je l’ai déployée sur Kubernetes, mais elle échoue également avec la même erreur que ci-dessus.
Même sur ma machine locale, lorsque j’exécute
docker run local_discourse/app
sans connexion Internet, je semble obtenir l’erreur ci-dessus.