L’application serait en dehors du conteneur Docker de Discourse, mais sur le même serveur. Si c’est le cas, quelqu’un pourrait-il partager quelques détails sur la manière de procéder ou m’orienter vers un guide ou des instructions, s’il vous plaît ?
Y aurait-il également des inconvénients à faire cela plutôt que d’utiliser le plugin ou l’API DE ?
Les inconvénients concernent principalement le fait qu’une telle connexion pourrait être utilisée pour un accès en écriture. Est-ce une exigence ?
Si votre intégration nécessite un accès en écriture à la base de données, envisagez de créer un plugin qui expose uniquement les opérations dont vous avez besoin.
Ce n’est pas une obligation, mais je suis d’accord pour l’accepter comme inconvénient 
J’ai commencé à utiliser votre plugin DE, mais malheureusement, je pense que mon cas d’usage nécessitera une connexion directe, car j’envoie trop de requêtes via l’API pour certaines de mes pages (et cela même avec seulement moi sur le site). Il s’agit principalement de requêtes personnalisées, donc je ne suis pas certain que cela ait un impact. J’adore toujours le plugin DE, par contre !
Auriez-vous une idée de la meilleure façon de se connecter directement à la base de données Postgres en dehors du conteneur ? Le forum et le site sont tous deux sur le même serveur, au cas où cela aiderait.
Édition : Je pense que je suis bloqué par une limite de taux avec le plugin DE, mais je suis certain d’avoir vu Sam dire que si les requêtes proviennent du même serveur, aucune limite de taux ne s’applique — est-ce toujours le cas ?
Bien que possible, l’autre application peut acquérir des verrous sur les tables et empêcher Discourse de fonctionner normalement.
Soit optez pour un nouveau plugin qui ajoute les points de terminaison API nécessaires dont vous avez besoin, soit allez jusqu’au bout en créant une autre instance PostgreSQL qui réplique votre Discourse et où vous pouvez intégrer votre application.
Merci pour ces informations, Rafael. Je vais utiliser exclusivement des instructions SELECT et, à ma connaissance, celles-ci ne verrouillent pas, donc je devrais uniquement me soucier des modifications de table côté Discourse (c’est-à-dire lors des mises à niveau) et pouvoir désactiver temporairement l’autre application. Cela suffirait-il à éliminer les préoccupations liées aux verrous ?
En ce qui concerne la réplication de la base de données, cela semble être une option intéressante. Peut-elle être effectuée en temps réel, de sorte que les données ne soient en retard que de quelques minutes ? (Je dois récupérer les derniers sujets fréquemment : presque chaque page du site les contient, bien que je mette en cache pendant deux minutes, mais cela varie selon la page/critère et il y aura des centaines de pages de ce type). De plus, cette option pourrait devenir impossible à mesure que la base de données grandit ? (Sur un autre forum Discourse, ma base de données fait déjà quelques gigaoctets.)
(Je ne pense pas qu’il soit possible de créer un plugin ici, car je ne vois pas comment cela pourrait être meilleur que le plugin Data Explorer. En fait, le plugin DE est presque parfait, à part ce problème.)
Quelqu’un a-t-il des idées sur la raison pour laquelle cela ne fonctionne pas, s’il vous plaît ?
J’ai suivi certains des posts de @pfaffman et @Nacho_Caballero dans ce sujet : How to make the database (or part of it) accessible to a cloud data processor? et le post de @mpalmer dans celui-ci : Accessing to the database from outside the container - #4 by mpalmer.
D’abord, j’ai édité app.yml avec :
expose:
- "127.0.0.2:5432:5432"
J’ai reconstruit le conteneur. Dans le conteneur, j’ai défini un mot de passe pour l’utilisateur postgres, et je peux ensuite me connecter avec la commande suivante depuis l’intérieur du conteneur :
psql -h localhost -d discourse -U postgres
Cependant, lorsque je quitte le conteneur et que j’essaie de me connecter, j’obtiens :
# psql -h 127.0.0.2 -p 5432 -d discourse -U postgres
psql: le serveur a fermé la connexion de manière inattendue
Cela signifie probablement que le serveur s'est terminé de manière anormale
avant ou pendant le traitement de la requête.
J’ai également essayé de changer le port pour un autre, mais j’obtiens la même chose. J’ai obtenu l’IP 127 de docker ps et en inspectant sous Paramètres réseau (j’ai trois instances Discourse autonomes en cours d’exécution).
Si je change l’IP (pour celle de l’un des autres forums Discourse), j’obtiens une réponse/message (plus immédiate et) différente, donc ce qui précède semble être partiellement correct :
# psql -h 127.0.0.3 -p 5432 -d discourse -U postgres
psql: impossible de se connecter au serveur : Connexion refusée
Le serveur est-il en cours d'exécution sur l'hôte "127.0.0.3" et accepte-t-il
les connexions TCP/IP sur le port 5432 ?
Des idées sur ce que je fais mal ? Chercher psql: le serveur a fermé la connexion de manière inattendue sur Google semble suggérer un problème de réseau — dois-je donc modifier autre chose à l’intérieur du conteneur ?
La méthode qui a fonctionné pour moi (depuis l’extérieur du conteneur) consiste à utiliser un tunnel SSH. J’ai en fait créé un nouvel utilisateur au lieu d’utiliser postgres et j’ai des ports personnalisés pour SSH et postgres, mais cela devrait fonctionner pour votre configuration :
ssh -L 5432:localhost:5432 EXTERNAL_VPS_IP "psql -U postgres -d discourse -h localhost"
EXTERNAL_VPS_IP est l’adresse IP que vous utilisez pour vous connecter à votre serveur distant.
Si cela ne fonctionne toujours pas, vous pourriez essayer de modifier l’IP exposée dans app.yml pour utiliser l’IP du pont Docker au lieu de l’IP interne du conteneur obtenue avec docker ps. Je ne suis pas sûr que cela soit nécessaire, mais c’est ainsi que je l’ai configuré :
expose:
- "127.0.0.1:5432:5432"
# ou si vous utilisez un port personnalisé : - "127.0.0.1:PORT_PERSONNALISE:5432"
N’oubliez pas de reconstruire le conteneur par la suite.
Faites-moi savoir comment cela se passe. Cela m’a pris BEAUCOUP de temps pour que tout fonctionne (et c’était si simple en y repensant), donc je suis ravi de pouvoir aider.
Merci pour l’info @Nacho_Caballero… surtout le lien concernant docker !
Il semble que les conseils dans votre fil (et dans les autres) étaient corrects : il faut :
expose:
- "127.17.0.1:5432:5432"
…comme indiqué dans ce lien, Docker transmettra automatiquement au bon IP pour votre conteneur (ce qui est logique étant donné que ces IP sont dynamiques — quelque chose que je m’étais demandé). Je pense que c’est tout ce dont la plupart des configurations ont besoin.
J’avais déjà essayé cela, alors vous vous demandez peut-être quel était mon problème. Mon pare-feu ! (Je pensais reconnaître l’erreur psql: server closed the connection unexpectedly !)
Tout est réglé maintenant — merci à tous 
Bon à savoir ! Je suis ravi que vous ayez trouvé la solution. Votre pare-feu est-il iptables ? Comment avez-vous ouvert le port ?
J’utilise firewalld, mais pour iptables, quelque chose comme ceci devrait fonctionner :
iptables -A INPUT -p tcp --dport xxxx -j ACCEPT
iptables -A OUTPUT -p tcp --dport xxxx -j ACCEPT