I created an image and then used the Docker Desktop interface to run it. That created a container that “didn’t work”. (I would know if it did work if I could connect to it via ssh)
I then deleted that container and created a new one via:
docker run --detach --name=soft-serve --volume /path/to/data:/soft-serve --publish 23231:23231/tcp charmcli/soft-serve
That did work. I can happily ssh to the app on port 23231. I can’t tell what is different. I ran: docker container inspect 48de24823cd5
and found the HostIp was different: “HostIp”: “127.0.0.1” vs “HostIp”: “0.0.0.0”
The broken container has 0.0.0.0 has the host ip. The broken one is the one I created with Docker Desktop. Not sure if that is relevant. Seems like it ought to be.
Anyway, the question is why doesn’t creating the container via the Docker Desktop interface result in an operational app, but creating it from the command line does?
Was your nonworking container running when you tried to connect to it?
If 127.0.0.1 works but 0.0.0.0 doesn’t then maybe the is port used by an other service on the host or somehow blocked and the container is not allowed to listen on every available interface.
Have you tried using an other host port just for testing if it works? You can also try to use your LAN IP address.
But the strange thing is that a don’t see any IP address defined in your cli command so it shouldn’t bind that port only to 127.0.0.1
The nonworking container was running when I tried to connect to it. I have tried another host port. I did notice that the log for the two containers is different. On startup, the working one logs: 2022/01/14 16:45:51 Starting SSH server on :23231
On the failed one, the log is empty. So I guess I can’t connect to the app because … it isn’t running? Why wouldn’t it be running if I create the container in the app, but does run when I use the command line? Seems like they should both do the same thing.
Okay, I have just realized you actually gave me the command to test your image…
I tested it and compared their metadata using docker container inspect. When you create your container using the GUI, TTY will be set to true. If you try this command from the terminal:
docker run --tty --detach --name=soft-serve --volume /path/to/data:/soft-serve --publish 23231:23231/tcp charmcli/soft-serve
it won’t work either. It looks like your app cannot listen if TTY is set to true.
Interesting. I didn’t notice that difference before. I don’t recall there being an option about ttys for the desktop app. Now I’ll have to look into that setting for a container. (just getting started with docker) The irony of it all is that the app only communicates via ssh (so a tty must be involved).
