J’exécute Discourse sur AWS ECS. Lorsque j’essaie de lancer l’application, l’onglet de console du navigateur échoue avec les URL suivantes. Ai-je oublié une modification de configuration ?
J’ai spécifié ce point de terminaison dans le fichier database.yml.
J’ai déployé Discourse sur ECS en utilisant Docker. Lorsque j’essaie d’accéder à l’application, le navigateur récupère des ressources depuis les URL ci-dessous au lieu de https://discuss-stage.tllms.com/.
Je parie sur un CDN mal configuré.
Peux-tu partager ton config/discourse.conf ?
Et cherche c0fbtc dans les paramètres de ton site pour voir si tu obtiens des résultats.
Cela ne semble pas correct. À votre place, je vérifierais si ma base de données n’est pas en réalité locale et n’a pas un nom étrange.
Je pense que cela devrait ressembler à ceci :
# adresse de l'hôte pour le serveur de base de données
# Ceci est défini à vide afin qu'il tente d'utiliser les sockets en premier
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# nom de la base de données exécutant Discourse
db_name = default
(Je dois vous avertir : vous tentez de réinventer une roue qui fonctionne parfaitement. De plus, certaines personnes ici ne seront pas très enthousiastes à l’idée de vous soutenir, car cela ne profite pas à la communauté).
Quoi que vous fassiez, assurez-vous à terme que ces valeurs soient correctement intégrées dans votre fichier discourse.conf. Si vous l’avez édité manuellement, placez au moins le nom d’hôte AWS dans db_host et laissez db_name sur default.
Je fais partie de la même équipe que Vijay. Le cas d’usage spécifique que nous cherchons à résoudre ici consiste à forker Discourse et à l’intégrer dans le GitHub de notre entreprise. À partir de là, nous construirions et déploierions sur AWS. La raison pour laquelle nous souhaitons l’héberger sur notre GitHub est de conserver la flexibilité de procéder aux modifications nécessaires selon nos besoins. Nous aimerions également contribuer en retour chaque fois que cela est possible. Comme nous n’avons pas trouvé de Dockerfile dans le dépôt public de Discourse, nous avons fini par en créer un nous-mêmes pour construire l’image Docker. De plus, nous utilisons GitHub Actions pour déployer le conteneur Docker sur le service ECS d’AWS.
Compte tenu de notre besoin, pensez-vous que nous aurions pu adopter une autre approche ?
Oui. Je recommande d’utiliser les dépôts officiels Discourse et discourse_docker, et d’implémenter tous les changements sous forme de plugins.
L’utilisation du dépôt officiel discourse_docker vous évitera des problèmes comme celui évoqué dans ce sujet. De plus, ne pas forker Discourse mais garder toutes vos modifications dans des plugins séparés vous évite de vous éloigner de la branche principale et d’avoir à consacrer énormément d’efforts à porter toutes les modifications en amont vers votre fork.
La courbe d’apprentissage du développement de plugins sera rentabilisée par rapport à l’effort de fusion des mises à jour en amont en quelques semaines, et à partir de là, cela deviendra encore plus efficace.
Lorsque vous utilisez le dépôt officiel de Discourse, vous pouvez également envisager un hébergement géré. Les personnes seront alors plus enthousiastes (et/ou moins chères) lorsqu’elles devront vous aider.
Merci pour vos retours. J’ai quelques questions de suivi :
Avec l’approche par plug-in, existe-t-il un risque de rencontrer un goulot d’étranglement pour certaines exigences qui ne pourraient pas être gérées via des plug-ins ? Par exemple, la gestion des rôles utilisateurs de manière très personnalisée ?
À quoi ressemblerait la chaîne de traitement complète si nous utilisions le projet discourse_docker et le déployions dans notre compte AWS sur ECS ? Comme je l’ai mentionné, nous utilisons actuellement GitHub Actions pour déployer sur ECS dans notre compte AWS. Quelle stratégie de déploiement pouvons-nous adopter depuis le dépôt public tout en protégeant nos identifiants AWS ?
Commencez toujours par une copie du dépôt discourse_docker. Créez un fichier app.yml à l’intérieur.
Utilisez la sous-commande bootstrap du script launcher dans votre copie locale de discourse_docker pour créer une image Docker. Poussez l’image Docker vers un dépôt Docker. Déployez cette image Docker où vous le souhaitez.
Écrivez des plugins si nécessaire. Répertoriez vos plugins personnalisés dans le fichier app.yml, comme les autres plugins.
@ashish_rawat@Vijay_Vantipalli Comment avez-vous configuré Discourse Docker sur ECS ? Lorsque j’essaie sur un serveur EC2, Discourse se charge correctement. Mais lorsque je pousse l’image Docker de Discourse vers le registre ECR et que je crée une tâche à partir de cette image, le conteneur ne se lance pas — je reçois simplement le code de sortie 1. Je suis bloqué depuis plus d’une semaine maintenant. J’aimerais beaucoup entendre vos conseils. Merci !
J’ai créé une instance RDS distincte et un cluster ElastiCache pour Redis à cette fin.
Merci pour votre réponse rapide ! Je pense qu’il me manque simplement quelque chose d’évident. Je vais essayer de le faire.
Désolé si cela sort de votre champ d’expertise. J’ai essayé d’ajouter le « -e » que j’ai trouvé dans l’application start-cmd, mais il existe d’autres arguments comme ceux-ci :
+ /usr/bin/docker run --shm-size=512m -d --restart=always
-h <adresse IP du serveur>
-e DOCKER_HOST_IP=172.17.0.1
--name app -t -p 80:80
-v /var/discourse/shared/web-only:/shared
-v /var/discourse/shared/web-only/log/var-log:/var/log
--mac-address <adresse> local_discourse/app /sbin/boot
Oui, il s’agit de montages de volumes. Il est absolument nécessaire que Discourse dispose d’un espace de stockage disponible à l’adresse /shared à l’intérieur du conteneur.
