Not able to connect to Postgres container from another container - postgresql

This question has been asked many times here, here and here but these solutions are not working for me.
I have created a Postgres and a AppServer container with this docker-compose.yml file
version: "3.7"
services:
db:
image: postgres:alpine
container_name: db
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
POSTGRES_DB: mydb
POSTGRES_INITDB_ARGS: '-A md5'
volumes:
- ./pgdata:/var/lib/postgressql/data
ports:
- "5432:5432"
api:
build: api
container_name: api
volumes:
- ./database/migrations:/migrations
ports:
- "8080:8080"
links:
- db
depends_on:
- db
After running this, I can successfully do
docker exec -it db psql -U user mydb
and I connect to Postgres successfully. I can also successfully login into terminals of both containers with
docker exec -it api bash
docker exec -it db bash
from inside of bash of api I can ping db without any problem
However from my api container, I cannot establish a JDBC connection to the Postgres database.
api | Flyway Community Edition 7.3.2 by Redgate
api | ERROR:
api | Unable to obtain connection from database (jdbc:postgresql://db:5432/mydb) for user 'user': Connection to db:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
api | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
api | SQL State : 08001
api | Error Code : 0
api | Message : Connection to db:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
api |
api | Caused by: org.postgresql.util.PSQLException: Connection to db:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
api | Caused by: java.net.ConnectException: Connection refused (Connection refused)
Why am I getting connection refused when I can connect via psql? This is my flyway conf
flyway.url=jdbc:postgresql://db:5432/mydb
flyway.user=user
flyway.password=password
flyway.locations=filesystem:/migrations
Edit:: So if I wait and then execute flyway migrate after some time from docker exec -it api bash everything works fine. I think what is happening above is that my flyway migrate command is running even before the database is ready.
Why is this happening? because I have specified dependency so my API container should start only when the database has fully started. but it seems that is not the case.

Specifying the database container as a dependency doesn't guarantee that it will be ready before your other services/containers. It only guarantees that it will start before your other services.
One way to get around this is to implement a retry attempt(s) in your API application when failing to connect to your database during startup.
Here is a link to an article that uses a shell script to wait for a service to be ready.
IMO your application should be smart enough to retry a few times when it cannot establish a database connection. It will make it more robust anyways.

Related

Can't connect to the Postgres Docker container using SqlAlchemy

I have a Postgres Docker Container running locally, and the docker compose code for it looks like this
version: '3.9'
services:
db:
image: "postgres"
container_name: db
ports:
- "5432:5432"
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=password
- POSTGRES_DB=dbname
The database is started using the docker compose run db command
I then find the IP address of the container once it's running, which is "192.168.240.2"
When I try to connect to the database with SqlAlchemy like the following in a python program (this is on the same computer but outside of the container)
import sqlalchemy
engine = sqlalchemy.create_engine('postgresql://postgres:password#192.168.240.2:5432/dbname')
engine.connect()
It shows me this error:
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "192.168.240.2", port 5432 failed: Operation timed out
Is the server running on that host and accepting TCP/IP connections?
Anyone knows what the problem is here? thanks!
Tried searching for the error message, but changing the input to the create_engine() function according to other posts various ways still result in the same problem. However, I still imagine something's off with the string?

Error: P1001: Can't reach database server at `localhost`:`5432`

I'm having a problem when running the npx prisma migrate dev command. Docker desktop tells me that the database is running correctly on port 5432 but I still can't see the problem.
I tried to put connect_timeout=300 to the connection string, tried many versions of postgres and docker, but I can't get it to work.
I leave you the link of the repo and photos so you can see the detail of the code.
I would greatly appreciate your help, since I have been lost for a long time with this.
Repo: https://github.com/gabrielmcreynolds/prisma-vs-typeorm/tree/master/prisma-project
Docker-compose.yml
version: "3.1"
services:
postgres:
image: postgres
container_name: postgresprisma
restart: always
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=santino2002
ports:
- "5432:5432"
volumes:
- postgres:/var/lib/postgresql/data
volumes:
postgres:
Error:
Error: P1001: Can't reach database server at localhost:5432
Please make sure your database server is running at localhost:5432.
Docker ps show this:
Looks like the application and the database are running on two separate containers. So, in this case, connecting to localhost:5432 from the application container will try to connect to 5432 port within that container and not in the docker host's localhost.
To connect to database from the application container, use postgres:5432 (If they are on the same network) or <dockerhost>:5432.
Your docker ps output is showing that your postgres container has no ports connected to your local network.
It should look something similiar to this on ports column.
0.0.0.0:5432->5432/tcp, :::5432->5432/tcp
But yours is just 5432/tcp
You need to open ports for your postgres container.
Your docker-compose.yml file you posted in the question is correct. Probably you started postgres container with no ports first, then changed your docker-compose.yml file to have ports. So you just need to restart it now.
Use docker compose down && docker compose up --build -d to do that.

flyway migrate fails with The connection attempt failed in docker-compose

I have these entries in my docker-compose.yml
flyway:
container_name: flyway
image: flyway/flyway
command: -url=jdbc:postgresql://postgresql:5432/db_name -schemas=public -user=username -password=password -connectRetries=60 migrate -X
volumes:
- ./config/src/main/sql:/flyway/sql
depends_on:
- postgresql
postgresql:
container_name: postgresql
image: postgres:10.1-alpine
command:
- postgres
- '-clog_connections=yes'
- '-clog_statement=all'
env_file:
- ./dev.env
networks:
- internal
ports:
- '5439:5432'
volumes:
- volume-postgres:/var/lib/postgresql/data
When I run docker-compose up --build flyway, I get this error
postgresql is up-to-date
Recreating flyway ... done
Attaching to flyway
flyway | WARNING: Connection error: The connection attempt failed.
flyway | (Caused by postgresql)
flyway | Retrying in 1 sec...
flyway | WARNING: Connection error: The connection attempt failed.
flyway | (Caused by postgresql)
flyway | Retrying in 2 sec...
flyway | WARNING: Connection error: The connection attempt failed.
flyway | (Caused by postgresql)
How can I debug it? In some answers I see DEBUG printed in the output.
What is wrong that it errors out?
1.
The debug logs should be produced since you have the -X flag in the flyway command. It looks like it might be attaching to the flyway container after the initial debug logs have already been logged. You should be able to see full logs for the flyway container by running:
docker-compose logs flyway
2.
Flyway can't connect to Postgres because they're on different networks. You've configured postgresql to be on the internal network, but flyway does not have a network configured so it will be on the default network.
There's a few way you could fix this:
Remove the network property from postgresql so both services are on the default network, but this isn't ideal if you're relying on other services being able to reach it on internal.
Add flyway to the internal network.
Since you've mapped port 5432 on postgresql to 5439 on the host network, you could add flyway to the host network (by giving it the property network_mode: "host") and then use the address localhost:5439 to access postgresql.

How to connect to a Postgres database running in local Docker container through locally-run psql command?

I'm running a docker container with the vanilla Postgres image on my local machine. I'd like to connect to the database from my local machine (i.e., not from "within the container". However, on trying to connect, I get an error.
Here's my docker-compose.yml file:
version: "3.8"
services:
db:
image: postgres
restart: always
ports:
- 5432:5432
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: mypassword
Here's how I start up:
docker-compose run db
Here's how I connect:
psql -h localhost -p 5432 -U postgres
This produces the error:
could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?
If I spin up the database without Docker Compose, the same connection command works as expected:
docker run --name mypg -p 5432:5432 -e POSTGRES_PASSWORD=password postgres
I could just go with the flow and use the command above. But this seems to be pointing to a flaw in how I think about Docker/Compose. For example, maybe Docker Compose's internal DNS resolver makes this approach fail.
Any ideas?
Version info:
psql --version
psql (PostgreSQL) 13.3
I have read through several SO posts, including these, but they don't address or fix the problem I'm seeing:
docker-compose: accessing postgres' shell (psql)
Can't connect to postgres when using docker-compose
Try docker-compose up db instead of run. Using run will run a one-off command against your container, whereas up will turn on the container and leave it running, so another application should be able to access it.
https://docs.docker.com/compose/faq/#whats-the-difference-between-up-run-and-start

Docker Compose Postgres always ended by timeout or connection refused

Got a small question here. I suppose I've done something wrong at a moment but i can't find where and it's been +2 hours I'm turning around.
So Basically, I've created a docker-compose with Postgis (Postgres). I wanted to connect on it through Tableplus.
However, I can't ...
2 kind of error keep appearing :
When I try to connect basically on 127.0.0.1, it's keep telling me connection refused
could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
When I try to use the docker IPAddress - 172.23.0.2 (docker inspect the image's ID to get the IP address of the image)
could not connect to server: Operation timed out
Is the server running on host "172.23.0.2" and accepting
TCP/IP connections on port 5432?
Here is my docker-compose.yml
version: '3.5'
services:
db:
image: kartoza/postgis:12.1
environment:
- POSTGRES_USER=user1
- POSTGRES_PASSWORD=password1
- POSTGRES_DB=database_db
volumes:
- data_db_volume:/var/lib/postgresql/12
ports:
- "5432:5432"
volumes:
data_db_volume:
At first, when I tried to connect, it was telling me: role user1 doesn't exist.
So to stop this I ran: brew services stop postgresql on my machine
I think a psql was running locally on the same port because with lsof -n -i:5432 | grep LISTEN i keep having information (it stop since I ran stop Postgresql)
Alright so after few days of research and trying on another computer, it seems it was coming from 2 points: the new docker software with a graphic interface that I didn't use before, once this running correctly and a prune done from this place everything started to work fine so I think something was causing error due to an outdated piece of software.
Thank's everyone