search

couchbase / docker

Dockerfiles and configuration scripts for the Docker Hub Official Couchbase images
143 stars 154 forks source link

Error in XDCR using Docker #150

Closed jimbolimbo3 closed 3 years ago

jimbolimbo3 commented 3 years ago

Hi, I'm running two instances of Couchbase 7.0.0 beta on Docker in two different servers.

Since I noticed that multiple ports are needed for connection, I added all of them in the docker run comand:

docker run -d --name db -p 9140:9140 -p 19130:19130 -p 21150:21150 -p 8091-8096:8091-8096 -p 11206-11211:11206-11211 -p 18091-18096:18091-18096 -p 21100:21100 -p 9119:9119 -p 9998-9999:9998-9999 -p 11213:11213 -p 21200:21200 -p 21300:21300 -p 21250:21250 -p 21350:21350 couchbase:7.0.0-beta

Evev I did that, I got these errors trying to use XDCR:

In one server (XDCR is bidirectional):

2021-04-06 10:12:23 172.17.0.3:genericPipeline.context.Start:Failed to start service CheckpointManager for bb121424227a24743e9fbc879d45ed2e/test/test. err=dial tcp 172.17.0.2:11210: connect: connection refused

In the other server:

2021-04-06 10:16:30 127.0.0.1:genericPipeline.context.Start:Failed to start service CheckpointManager for b07af2be29c3e94952a039c58aa12891/test/test. err=dial tcp 172.17.0.3:11210: connect: no route to host

Both server are Ubuntu server, updated and without any firewall on.

Is that a known issue? I had similar behaviour with stable release, by the way.

ceejatec commented 3 years ago

172.17.0.x are IPs that a single Docker host assigns to containers. They are strictly internal to that Docker host; they aren't routable from the outside world. You can't connect to those IPs from other servers, at least not without either doing iptables configuration on both hosts or by using some kind of Docker mesh network. This doesn't have anything to do with XDCR, or even with Server for that matter.

Since you are exposing the ports with "docker run -p", all those ports will be available on the public IPs of the two servers themselves. So you should be able to hook up XDCR between the two servers using those IPs rather than the internal 172.17.0.x IPs.