Estaba interesado en usar servicios ETL como Stitch Data o Skyvia para integrar diferentes fuentes de datos (incluida mi base de datos de Discourse), pero alguien de Skyvia me dijo que esto no es posible:
Skyvia puede conectarse a PostgreSQL a través de SSH; sin embargo, no es posible conectarse cuando está dentro de un contenedor Docker y el servidor SSH no está dentro del contenedor, sino frente a él.
Podrías habilitar SSH en el contenedor de Discourse (en un puerto no estándar) y luego permitirles conectarse allí. Creo que puede haber un ejemplo en el directorio de muestras de Discourse_docker.
Parece que me falta un concepto clave, ya que puedo conectarme mediante SSH con el puerto personalizado y luego ejecutar su postgres -c 'psql discourse' sin problemas. Todo funciona con este enfoque de dos pasos, pero creo que lo que necesito para conectarme directamente desde pgAdmin (por ejemplo) es algo ligeramente diferente.
Este es el comando que estoy usando para exponer un puerto personalizado:
Lo que me permite hacer esto más adelante directamente (sin ejecutar el contenedor Docker mediante launcher enter app):
ssh whatever@host -p 2222
su postgres -c 'psql discourse'
He probado varias cosas, pero sin éxito. Siento que debería haber una forma de ejecutar ssh whatever@host -p XXXX y conectarme directamente a la base de datos (que es probablemente lo que pgAdmin espera).
Necesitas exponer el puerto de PostgreSQL directamente para poder conectarte mediante pgAdmin.
En el archivo app.yml, cerca de la parte superior, verás que los puertos 80 y 443 están abiertos. Puedes agregar otra línea para el puerto 5432 de PostgreSQL.
Dicho esto, esto es casi con total seguridad una muy mala idea. La base de datos pasó de aceptar solo conexiones locales a estar expuesta a todo internet.
Si lo único que necesitas es generar informes ocasionales, descargar algunos archivos CSV desde el Explorador de Datos y cargarlos en tu herramienta preferida podría ser suficiente. También puedes descargar copias de seguridad de Discourse (sin archivos adjuntos), las cuales están en el formato estándar de volcado de PostgreSQL. Con eso en mano, podrás restaurarlas en una instancia local de PostgreSQL para realizar el análisis.
Si agregas 5432 al app.yml, queda expuesto directamente, sin necesidad del túnel SSH.
No puedo dar consejos sobre el túnel SSH de pgAdmin, ya que nunca lo he usado. Supongo que espera que el puerto escuche conexiones locales, por lo que no necesita estar expuesto a internet.
Pero no hay contraseña de PostgreSQL porque requiere ser superusuario: el archivo pg_hba.conf tiene los permisos de conexión “local” configurados en “peer”, por lo que depende del usuario UNIX, lo cual requiere iniciar sesión vía SSH, ¿verdad?
Esto no funciona: psql -h XX.XX.XX.XX -p 5432 -U postgres -d discourse
Correcto, no tengo ningún problema al conectarme desde el contenedor Docker de la aplicación. Mi problema es conectarme directamente a la base de datos PostgreSQL desde mi máquina local (para poder usar pgAdmin) o desde un procesador de datos en la nube como Stitch. Ambos esperan una dirección IP de host y credenciales SSH, pero no he logrado que funcionen (recibo el error que mostré anteriormente).
Lo único que he logrado hacer es usar docker-ssh para acceder directamente al contenedor Docker de la aplicación (mediante clave pública) desde mi computadora local (sin ejecutar launcher enter app), pero aún necesito ejecutar su postgres 'psql discourse' para acceder a la base de datos. Supongo que ese es el problema con pgAdmin/Stitch: ellos esperan una conexión directa.
El problema es que me aparece un prompt de contraseña. Como el usuario postgres no tiene una, intenté crear un usuario diferente y asignarle una contraseña:
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;
Añadí una línea para ese usuario con md5 en pg_hba.conf y reinicié PG con service postgresql restart
# Database administrative login by Unix domain socket
local all postgres peer
local all whatever_user md5
Sin embargo, cuando intento conectarme desde el servidor remoto, obtengo un fallo de autenticación:
# 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é me estoy perdiendo? Estoy intentando al menos poder conectarme a la BD desde el mismo servidor. El paso 2 sería hacer lo mismo usando un túnel SSH, pero supongo que primero debo resolver el paso 1. Agradezco cualquier ayuda.
por esto: - "127.0.0.1:5433:5432" porque recibí un error indicando que el puerto ya estaba en uso.
Reconstruí el contenedor y verifiqué que el puerto estuviera efectivamente abierto:
$ 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
Ahora puedo crear un túnel SSH y conectarme desde mi servidor remoto usando un usuario con contraseña:
# crear el túnel (también podrías usar ssh -f para ejecutarlo en segundo plano)
ssh -v -N -L 5433:localhost:5433 SERVER_IP_ADDRESS
# conectarse en otra pestaña e ingresar la contraseña
psql -h localhost -d discourse -U whatever_user -p 5433
Si alguien está intentando hacer esto y tiene algún problema, házmelo saber.