After reconfiguring the ports in kitematic the complete container is resetted
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.
~~Second this. Same here. Kitematic version is 0.17.7~~
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.
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.
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 policyoption 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