Thank you for your reply, I am still struggling with this, so all effort to get a fix is much appreciated!
I have read your analysis and I agree 100%! It actually all comes down to what we specify as advertise_address.
If I set advertise_address=my_container_name_1 or advertise_address=my_container_name_1.external_network it will listen to the extenal network (the overlay network). If I do this, the cluster nodes can communicate and sync. However, the app container and the host fails to reach the yugabyte container, as specified before.
If I set advertise_address=my_container_name_1.internal_network, it will listen to the internal network. If I do this, the app container and the host can reach the yugabyte container, but the cluster nodes fails to reach each other.
And, just as you say, this has to do with the yugabyte container and that it can only listen to one network at a time.
I think we will have to support yugabyted to bind to both bridge and overlay network interfaces, currently yugabytedb supports listening only on one network, which is the overlay network.
Are you involved in the development of yugabyte or have some pull with the developers? Since I wrote my last reply in this thread, I have created another thread (with no replies) where I have boiled down the issue to an example that is easy to reproduce. You can find it here:
In addition to this (as it almost seems like a bug, or at least a limitation), I have also created an issue at the yugabyte github page:
I believe that many users may be interested in a solution to this issue.
We generally don’t test the docker swarm way of deploying the YugabyteDB database, as we consider docker deployments for development only.
Well, docker is well established in production environments, so I do not understand what would be different with yugabyte in the mix. In my case, I come from a docker production setup with postgres and am looking for a migration over to yugabyte to get its remote synchronization features. We do not see working outside docker containers as an alternative. Also, kubernetes is currently not an option either. Docker swarm seemed as the perfect solution.
I’ll try to get this in the backlog of the yugabyted work stream.
That would be great! If we only could get the yugabyted container to be able to listen to two networks at the same time, it would probably resolve the issue. For example, if we could specify two (or more) networks in the advertise_address property.