I have a postgresql server up and running under root. It's in a docker container and the exposed port is 5434. My API docker container is able to connect to this server, but I can't access it from my local machine, the connection is getting timed out.
Here's the output of the command ps -elf|grep root
4 S root 15264 5623 0 80 0 - 2128 - Jan25 ? 00:00:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 5434 -container-ip 172.18.0.5 -container-port 5432
Now that Postgres is running in a Docker container, your IP is not local anymore, so you need to update the pg_hba.conf for the server to allow connections from the network from which you are accessing Postgres.
Related
I'm initializing my studies with docker. When I creating the postgreSQL container with Docker, appear this error:
I've already reinstall docker and tried change the database port, but must be don't have success
The error indicates that the 5432 port is already in use, in the HOST. This means that this port is occupied by another application. This could be for example a Postgres instance that you have on your machine or maybe another container using up this port.
The port option is -p hostPort:ContainerPort, so to have access to the Postgres port of the container which is 5432 in the host at port 5000 try:
-p 5000:5432
All the questions on SO about this seem to refer to an opposite case of creating a postgres container and connecting it from Mac host. But I am trying to do the opposite, without success. I have localhost running on my Mac host machine, and despite setting port flags, I cannot get code inside my container to talk to my localhost postgres (talks to remote host postgres just fine).
docker run -it -p 5000:5000 -p 5432:5432 yard-stats
Then inside docker:
telnet 0.0.0.0 5432
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refused
or telnet 127.0.0.1 or localhost. Connection is refused.
Edit: I also tried with flag --network="host", which did not change anything except break inbound connections to the container on localhost:5000 as well.
If you are using docker for mac, you can use use host.docker.internal special DNS name which resolves to the internal IP address used by the host.
You can also use --network="host" with your docker run command to run the container in host network. Then the localhost interface inside the container will be same as localhost interface of the host machine when run in host network. So you should be able to use localhost:5432 to connect to postgresql. You can remove -p option as it has no effect when running with --network="host".
docker run -it --network=host yard-stats
I'm fairly new to docker and I'm trying to connect from my machine to a mongo server running on a docker-machine.
I started the docker image as it is documented in the official mongo repository:
docker run --name my-mongo -d mongo
Because I'm running on a docker-machine I'm using the machine ip (got it with docker-machine ip dev) and default mongo port and type:
mongo --host 192.168.99.100 --port 27017
And I'm getting this response:
2015-09-28T17:20:14.438+0300 warning: Failed to connect to 192.168.99.100:27017, reason: errno:61 Connection refused
2015-09-28T17:20:14.439+0300 Error: couldn't connect to server 192.168.99.100:27017 (192.168.99.100), connection attempt failed at src/mongo/shell/mongo.js:148
exception: connect failed
From the logs I can see that mongo started off just fine:
2015-09-28T14:12:47.550+0000 I STORAGE [FileAllocator] creating directory /data/db/_tmp
2015-09-28T14:12:47.551+0000 I STORAGE [FileAllocator] done allocating datafile /data/db/local.0, size: 64MB, took 0 secs
2015-09-28T14:12:47.554+0000 I NETWORK [initandlisten] waiting for connections on port 27017
What am I missing - is it my configuration or the way I'm trying to start the mongo shell (I also tried to connect with node application - no success either).
Check the IP could be ping from your system. if so
Have done port forwarding in Dockerfile
You have to map the docker port which runs the mongo DB to a system port and need to connect to that port if you are not connecting from the local system
I am trying to connect to Postgresql using the PGAdmin III client in Windows 8.1. Postgresql is installed in a local copy of Vagrant (Ubuntu 14.04) on my Windows machine. It's up and running on Vagrant:
LISTENING
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 814/postgres
VERIFIED USER/PASS/LOCAL CONNECTION
I can access Postgresql locally in Vagrant via SSH in Windows:
vagrant#precise32:/etc/postgresql/9.1/main$ psql -h localhost testdb myuser
Password for user myuser:
psql (9.1.15)
SSL connection (<removed)
Type "help" for help.
testdb=> \quit
PG_HBA.CONF
I added this to my pg_hba.conf file:
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all <my IP> md5
VAGRANT CONFIG
My Vagrant config is set to port forward to 5432:
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine. In the example below,
# accessing "localhost:8080" will access port 80 on the guest machine.
config.vm.network "forwarded_port", guest: 5432, host: 15432
POSTGRESQL.CONF
And my postgresql.conf file is set to listen on all IP's:
#listen_addresses = '*' # what IP address(es) to listen on;
PGADMIN ERROR
So, what am I missing here when I try to connect as a guest via PGAdmin to the host and I get the following message, which indicates it sees it but something is not letting me through?:
An error has occurred:
Error connecting to the server: server closed the connection unexpectedly
This probably means the server terminated abnormally before or while processing the request.
PGADMIN CONNECTION INFO
Host: localhost
Port: 15432
Service: <blank>
Maintenance DB: postgres
Username: Myuser (verified)
Password: ****** (verified)
Store password:
Colour: <blank>
Group: Servers
In your Vagrant config add a IP (if not set) eg:
config.vm.network :forwarded_port, host: 15432, guest: 5432
config.vm.network :private_network, ip: "192.168.111.222"
Now from PGAdmin in Windows connect to host 192.168.111.222, port 5432.
Worked for me although I'm not know why.. :P
I dont know what you mean with in pg_hba.conf but in vagrant enviroment you should use ip like 10.0.2.2/24 instead your machine network address.
I had the same problem in linux, and i think in windows this can happen too. In my postgresql.conf the port variable was defined in two places. First with 5432 value, and second with 5435 value.
Running telnet vm_ip 5435, i was able to connect to the server running in the vm.
In my case my vm was running with public_network option, so i have a external ip. In this case, you don't need to forward a port, once you will access the vm,for example, with 192.168.60.15:5435 address.
I have containerized a web application running on Tomcat and started the container using the command,
docker run -d -p 8080:8080 tveuser/tve-repository:tve-services
I am also running a PostgreSQL container on the same host using the following command:
docker run -d -p 80:80 -p 5432:5432 tveuser/tve-repository:tve-postgresql
i verified that the PostgreSQL is running by using phpPgAdmin but could not get tomcat to connect to it. 'docker ps' also tells me that both the containers are up and running.
I connect the web application with the database through tomcat context.xml which has an entry like
<Parameter name="abc.connection.url" value="jdbc:postgresql://1.2.3.4:5432/dbname" />
where 1.2.3.4 is the docker host Ip in which the container is running.But i get the following error when i run the tomcat container:
org.postgresql.util.PSQLException: The connection attempt failed.
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:225)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64)
at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:136)
...............
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
Any help appreciated.
TL;DR : check the firewall on your host
You need to connect to your host's IP address on the port that you've exposed for postgres on your postgres container, not to the IP address of the docker container.
E.g.,
<Parameter name="abc.connection.url" value="jdbc:postgresql://192.168.x.x:5432/dbname" />
You'll also need to configure postgres inside your postgres docker container to listen for connections from somewhere other than 127.0.0.1, which is the default.
E.g., in pg_hba.conf:
host all all 0.0.0.0/0 md5
This tells postgres to accept incoming connections from any IP address (you'll probably want to lock this down to something like 192.168.0.0/16.
You'll also need to change the value of listen_addresses in postgres.conf:
listen_addresses = '*' # what IP address(es) to listen on;
Once you've made these configuration changes, you can check to see if postgres is listening to all requests from all IPs inside your docker container:
netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 816/postgres
tcp6 0 0 :::5432 :::* LISTEN 816/postgres
And then from your host, make sure you can telnet into port 5432:
telnet 192.168.x.x 5432
Trying 192.168.x.x...
Connected to 192.168.x.x.
Escape character is '^]'.
As Chris McKinnel points out, forwarding ports to the host doesn't work like that. I wanted to give you a second solution as an alternative to his: Links.
https://docs.docker.com/userguide/dockerlinks/
So you could do something like:
docker run -d -P --name tomcat --link postgres:postgres apache/tomcat apachectl start
... which, assuming your PostgreSQL container was named "postgres", would allow you to connect directly from the Tomcat container.
Note that this only works if both containers are on the same machine, but it sounds like they are.