I find it inconvenient that a number of container settings are immutable. Forget a volume? Forget a port mapping? Want to bring up a container, make a change, and then mark the root filesystem as read-only? Start with a read-only root, and then realize it should have been read-write after all?
Too bad. Go set up all of the other settings again, along with the desired change, and don’t miss
anything or get any settings wrong this time. If it’s “change something before going read-only,” it’s time
to create a Containerfile and build a new image, too. No matter what, don’t forget to delete the original
container first, to free its name for reuse.
There’s no way to create a container based on an existing container’s settings. There’s no direct option for it. There’s not even an indirect option to export the settings of a container, and then use them as a template during container creation later.
It’s worse in Podman Desktop, which has no memory. It doesn’t even have separate “last used directory” memory
for building from a Containerfile versus choosing a volume to mount. Why not make everyone go back and
forth through the filesystem every time?
At least in the CLI, the previous commands could be in the shell history. “Could be,” because I might have been distracted for two months, and the commands got pushed out of the history in the meantime. (Speaking of, “the container” has its Containerfile baked in, but doesn’t remember where on the filesystem that Containerfile came from. Not even locally. Maybe it’s just me, but it’s always a treasure hunt to resume a project.)
I can see the logic of “not allowing settings drift” in production container environments, but it seems like Podman Desktop should be optimized for the developer experience and experimentation instead.
