In explanation, there is no “production” image. That is my personal naming convention.
I download “latest” and rename that to “test”. Then I run this “test” image for a while until I am satisfied that everything is OK. Next, I rename my old image, the one I was running before the new “test” image, from “production” to “previous”. Finally, I rename the “test” image to “production”. So in the steady state condition, I can look at my image listing and see both a “production” image (the one currently running) and a “previous” image (the one I used to run before the current one).
The commands to do this renaming are thus:
# If needed, delete the old "test" image:
docker rmi uroni/urbackup-server:test
# Pull the latest image and rename it to "test":
docker image pull uroni/urbackup-server:latest
docker tag uroni/urbackup-server:latest uroni/urbackup-server:test
docker rmi uroni/urbackup-server:latest
# After verifying the newest image runs well, rename it from "test" to "production" after renaming the old "production" image to "previous":
docker tag uroni/urbackup-server:production uroni/urbackup-server:previous
docker rmi uroni/urbackup-server:production
docker tag uroni/urbackup-server:test uroni/urbackup-server:production
docker rmi uroni/urbackup-server:test
Yes, that is exactly what it is saying. And you will indeed get “Connection Refused” if you attempt to connect to a port with no listen’er on it. Now, the question is WHY is your container not listening? This is where it would be very helpful to get inside the container and snoop around with this command:
docker exec -it urbackup /bin/bash
But when I go inside my container using the above, I find that there is no “ps” or “netstat” command available inside the container, which would be very useful for debugging this. You could add these commands and rebuild the container, but you have to balance that with “how much do I want to manually modify this non-working image?”
I think what I would try, is a different networking model for the container. Currently you are using network_mode=host (which is what the image documentation says to use). But as my netstat command shows, the container is only listening on three ports. There could be other networking concerns that we haven’t captured yet, thus the following is only a test, but you could try replacing network_mode=host with:
ports:
- 55413:55413
- 55414:55414
- 55415:55415
… and see if you could connect. Note that urbackup may not work correctly configured like this, but hopefully you might at least be able to connect to the GUI interface as a test. Then, you would have to figure out why network_mode=host is not working … why you are not seeing any listen’ers running. If the logfiles in the container do not tell you why, then this might be difficult without “ps” and “netstat”.
No, the client is listening on them. Not the server. The server would connect outgoing from your docker container to these client ports. This is what triggers my uncertainty about you being able to run the urbackup server container in other than “host” networking mode. I am not that familiar with the Docker networking model. By not running the container in host networking mode, could you possibly impact these client connections? I wouldn’t think so, since containers can connect outgoing (in my experience) without being in host mode. But there could be some nuance in Docker that could screw things up for this container if it’s not in host mode. I would think the probability of that is low, but not zero. Also, we have not figured out why your current host mode use of the container is not working. Could there be something in your higher level/generic Docker setup that is nuking your host mode for containers? Not knowing Docker networking in great detail, I can’t answer that.
