kitematic icon indicating copy to clipboard operation
kitematic copied to clipboard

After reconfiguring the ports in kitematic the complete container is resetted

Open AlBundy33 opened this issue 7 years ago • 4 comments

create a new container from hello-world-nginx current container-id: 9b941114c2c6a14cd0fcb6766cc662026e0bc35a9403002a73fec62ad13e31eb stop and restart the container --> ID does not change

Now open the settings of this container, switch to "Hostname / Ports" and add a new entry (e.g. from 1234 to 1234). and save this configuration. Result: new container-id b0e111c3eb506c07d38737f8e920d4be4ea674ff7261dcbee47520c3930a8b25

And of course all changes inside the container are lost.

The expected behavior is that the container is not changed - if this is a limitation of docker it would be nice I the user gets a warning.

AlBundy33 avatar Aug 22 '18 09:08 AlBundy33

~~Second this. Same here. Kitematic version is 0.17.7~~

MonkeyTonk avatar Mar 07 '19 18:03 MonkeyTonk

As mentioned in #1991 (or more specifically in comment https://github.com/docker/kitematic/issues/1991#issuecomment-247480423) this is due to the fact that docker (at the moment) cannot change portmappings of a configured container. It is a bit disguised by kitematic because what kitematic does it removes the current container, creates and starts a new container based on the same image. That's why the ID is also changing.

As a solution kitematic could add a commit to this chain and remove the "temporary" created image (created through the commit).

Other workarounds can be found on stackoverflow or in a blog post.

Yes, it would be nice if docker had some "native" way of doing this but otherwise.. docker is not meant that way. BUT I think @AlBundy33 has a point in

if this is a limitation of docker it would be nice I[f] the user gets a warning.

Sorry for the inconvenience.

MonkeyTonk avatar Mar 08 '19 15:03 MonkeyTonk

I just lost a lot of configuration data in a container (that I hadn't got around to setting up with persistent volumes) because of this issue. I just wanted my container to restart automatically, so ticked the Enable 'always' restart policy option in Advanced Options and saved... boom, container reset.

I am relatively new to the Docker container management world, but come on... it would have been pretty simple to have a warning label or confirmation dialog saying that the container was going to go away! I've just learned a very important lesson about how containers are managed. Please add some sort of warning so that others don't have to experience this.

mpresling avatar May 13 '19 22:05 mpresling

I just lost a lot of configuration data in a container (that I hadn't got around to setting up with persistent volumes) because of this issue. I just wanted my container to restart automatically, so ticked the Enable 'always' restart policy option in Advanced Options and saved... boom, container reset.

I am relatively new to the Docker container management world, but come on... it would have been pretty simple to have a warning label or confirmation dialog saying that the container was going to go away! I've just learned a very important lesson about how containers are managed. Please add some sort of warning so that others don't have to experience this.

The exact same happened to me today, I lost the Keycloak configuration I had, thankfully I have most of what I did documented, but still it's going to shave off a while from my day, I should have enabled the restart policy via CLI

speedhog avatar Mar 30 '21 17:03 speedhog