Je souhaitais utiliser des services ETL comme Stitch Data ou Skyvia pour intégrer différentes sources de données (y compris ma base de données Discourse), mais une personne de Skyvia m’a indiqué que cela n’était pas possible :
Skyvia peut se connecter à PostgreSQL via SSH, mais il n’est pas possible de s’y connecter lorsqu’il est contenu dans un conteneur Docker alors que le serveur SSH n’est pas dans le conteneur mais devant celui-ci.
Vous pourriez activer SSH dans le conteneur Discourse (sur un port non standard) et permettre ainsi aux utilisateurs de s’y connecter. Je pense qu’il existe peut-être un exemple dans le répertoire d’exemples de Discourse_docker.
Il semble que je manque d’un concept clé, car je parviens à me connecter via SSH avec le port personnalisé, puis à exécuter su postgres -c 'psql discourse' sans problème. Tout fonctionne avec cette approche en deux étapes, mais je pense que ce dont j’ai besoin pour me connecter directement via pgAdmin (par exemple) est légèrement différent.
Voici la commande que j’utilise pour exposer un port personnalisé :
Ce qui me permet ensuite de faire cela directement (sans lancer le conteneur Docker via launcher enter app) :
ssh whatever@host -p 2222
su postgres -c 'psql discourse'
J’ai essayé plusieurs choses, mais sans succès. J’ai l’impression qu’il devrait y avoir un moyen d’exécuter ssh whatever@host -p XXXX et de me connecter directement à la base de données (ce qui est probablement ce que pgAdmin attend).
Vous devez exposer directement le port PostgreSQL pour pouvoir vous connecter via pgAdmin.
Dans le fichier app.yml, près du début, vous voyez que les ports 80 et 443 sont ouverts. Vous pouvez ajouter une autre ligne pour le port 5432 de PostgreSQL.
Cela dit, c’est presque certainement une très mauvaise idée. La base de données est passée de l’acceptation de connexions uniquement locales à une exposition complète sur Internet.
Si tout ce dont vous avez besoin est quelques rapports occasionnels, télécharger certains fichiers CSV depuis l’Explorateur de données et les charger dans votre outil préféré peut suffire. Vous pouvez également télécharger des sauvegardes de Discourse (sans les fichiers joints), qui sont au format standard de dump PostgreSQL. Avec cela en main, vous pouvez les restaurer sur une instance PostgreSQL locale pour analyse.
Si vous ajoutez 5432 dans app.yml, il est exposé directement, sans avoir besoin du tunnel SSH.
Je ne peux pas donner de conseils concernant le tunnel SSH de pgAdmin, car je ne l’ai jamais utilisé. Je suppose qu’il attend que le port écoute les connexions locales, de sorte qu’il n’a pas besoin d’être exposé à Internet.
Mais il n’y a pas de mot de passe PostgreSQL car cela nécessite d’être superutilisateur : le fichier pg_hba.conf a les permissions de connexion “local” définies sur “peer”, ce qui dépend de l’utilisateur UNIX, ce qui nécessite une connexion via SSH, n’est-ce pas ?
Cela ne fonctionne pas : psql -h XX.XX.XX.XX -p 5432 -U postgres -d discourse
Bon, je n’ai aucun problème pour me connecter depuis le conteneur Docker de l’application. Mon problème est de me connecter directement à la base de données PostgreSQL depuis ma machine locale (pour pouvoir utiliser pgAdmin) ou depuis un processeur de données cloud comme Stitch. Ces deux solutions attendent une adresse IP d’hôte et des identifiants SSH, mais je n’ai pas réussi à les faire fonctionner (j’obtiens l’erreur que j’ai montrée plus haut).
La seule chose que j’ai pu faire est d’utiliser docker-ssh pour accéder directement au conteneur Docker de l’application (via une clé publique) depuis mon ordinateur local (sans faire launcher enter app), mais je dois toujours exécuter su postgres 'psql discourse' pour accéder à la base de données. Je suppose que c’est le problème avec pgAdmin/Stitch : ils attendent une connexion directe.
Si je sors du conteneur et que je suis sur mon serveur distant (pas encore sur mon ordinateur local), ne devrais-je pas pouvoir me connecter en utilisant ceci ?
Le problème est que je reçois une invite de mot de passe. Comme l’utilisateur postgres n’en a pas, j’ai essayé de créer un autre utilisateur et de lui attribuer un mot de passe :
CREATE USER whatever_user WITH ENCRYPTED PASSWORD '<whatever password>';
GRANT CONNECT ON DATABASE discourse TO whatever_user;
GRANT USAGE ON SCHEMA public TO whatever_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO whatever_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO whatever_user;
J’ai ajouté une ligne pour cet utilisateur avec md5 dans pg_hba.conf et redémarré PG avec service postgresql restart
# Database administrative login by Unix domain socket
local all postgres peer
local all whatever_user md5
Cependant, lorsque j’essaie de me connecter depuis le serveur distant, je reçois un échec d’authentification :
# psql -h localhost -d discourse -U whatever_user
Password for user whatever_user:
psql: FATAL: password authentication failed for user "whatever_user"
FATAL: password authentication failed for user "whatever_user"
Qu’est-ce que je rate ? J’essaie au moins de pouvoir me connecter à la base de données depuis le même serveur. L’étape 2 consisterait à faire la même chose en utilisant un tunnel SSH, mais je suppose que je dois d’abord régler l’étape 1. Toute aide est appréciée.
par ceci - "127.0.0.1:5433:5432" car j’avais une erreur indiquant que le port était déjà utilisé.
J’ai reconstruit le conteneur et vérifié que le port était bien ouvert :
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
whatever_id local_discourse/app "/sbin/boot" 20 minutes ago Up 20 minutes 127.0.0.1:5433->5432/tcp app
Je peux maintenant créer un tunnel SSH et me connecter depuis mon serveur distant en utilisant un utilisateur avec mot de passe :
# créer le tunnel (vous pouvez aussi utiliser ssh -f pour l'exécuter en arrière-plan)
ssh -v -N -L 5433:localhost:5433 ADRESSE_IP_SERVEUR
# se connecter dans un autre onglet et entrer le mot de passe
psql -h localhost -d discourse -U whatever_user -p 5433
Si quelqu’un essaie de faire cela et rencontre des problèmes, faites-le-moi savoir.
