When starting docker a bridge network is automatically started, this network has its own ip and you have to check what is the ip of that network. If you are running it locally and used localhost, the bridge network's adress might be different from localhost and that might be why you weren't able to connect. However, using the containers' name is a much safer way to communicate between servers, docker will choose the correct address.
First of all, while there is more or less one stable option for Java, there exist many different libraries for JavaScript and some of them don't interact very well with Docker. As such, I recommend using the socket.io-client client library to implement the socket client.
Docker actually allows you to address your components via the names of their containers. So instead of using localhost or other IP addresses to connect to your container, you should specify the name of the container, for example use the address ws://socketserver:4001
if the name of the container that hosts the server is socketserver and it runs on port 4001. Furthermore, in your docker-compose file, you should make sure that there are no conflicts between exposed ports, and that the relevant port on the server is exposed. After that, your components should be able to interact with each other without any issues.
Installing the newest version of docker-compose should solve this issue.
Current docker-compose is probably installed via 'apt-get install'.
If the 'docker-compose -v' is not 1.27.4 (currently newest version)
Run following:
'sudo curl -L "https://github.com/docker/compose/releases/download//docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose'
Instead of VERSION you put 1.27.4 which is the currently newest version.
Afterwards apply executable permissions on the downloaded binary:
'sudo chmod +x /usr/local/bin/docker-compose'
Now after running 'docker-compose -v' you should have the '1.27.4' version and the Dockerfile should not throw an error.
For local development it is usually a practise to spawn test containers on a local machine and run them all the time during development.
Also embedded broker/server is also an option, but RabbitMQ and Postgres don’t offer embedded solutions out of the box and setting a custom one would take too much time.
So what you can easily do is spawn local short lived docker containers with these technologies.
A good and tested solution to this problem is using the Testcontainers test dependency. Test containers
So, with provided RabbitMQ and Postgres images, you just launch containers on Test Suite start and they get automatically destroyed on shutdown.