Docker
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.
Taggings:
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.
Taggings:
Websocket interactions in Docker
I am trying to get my Websocket server (Java) and client (JS) to interact with each other when they are both running in separate Docker containers. However, no matter what I do, I cannot get the client to even establish a connection to the server. What can be done here?
Taggings:
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.
Taggings:
docker-compose invalid type in volume
I am getting a following error when I run docker-compose up:
*volumes contains an invalid type, it should be a string*
my docker-compose file:
data-emitter:
build:
context: DataEmitter
dockerfile: ./Dockerfile
volumes:
- type: bind
source: ./DataEmitter/data/logs.txt
target: /data/logs.txt
read_only: true
Since there is a type: bind, what is the problem here?
Taggings:
How to properly back up Docker volumes?
My problem was to develop a backup strategy for a running Linux server with multiple docker containers which used docker volume to store data. The problem was that it’s not trivial to just tar an volume like an bind mount. The recommended way to achieve this is to first launch a new container and mount the volume from the running container. Then to mount an local host directory as e.g. “/backup” and finally to pass a command that tars the contents of the data volume to a backup.tar file inside our “/backup” directory.
Preparing the first time use of Docker (using Windows OS)
This problem occurred when using Docker for the first time.
Before a docker-compose.yml is created and the command docker-compose up can be used to actually run the containers/commands indicated in the file, some configuration has to be done when using Windows OS.
In this case, a Docker volume was used. So, the link to the volume had to be set in the sample form: C:\Users\Cordula\Docker\dockerVolume:/var/container_home.
The volume location has to be added to the docker-compose.yml.
Then adapt in Settings > Advanced the settings for CPUs, Memory, Swap and Disk Image Size because Docker containers might otherwise be stopped automatically due to excessively high load.
The resource usage of docker containers can be checked by the command docker stats at any time.
In Settings > Shared Drives the drive, on which Docker will be run, should be selected. When using it for the first time, there might occur access problems due to internet security/anti-virus programmes – so for the time of set-up these are recommended to be interrupted for a short time.
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.
Taggings:
Pages
