Support modifying published ports after container start

[deliciouslytyped]

Feature request description

There does not seem to be any way to change published ports after starting a container.

See also:

• https://stackoverflow.com/questions/63641299/podman-pod-change-port-mapping

• https://stackoverflow.com/questions/59920413/podman-add-ports-to-expose-to-running-pod
  which cites https://developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods#

  Most of the attributes that make up the Pod are actually assigned to the "infra" container. 
  Port bindings, cgroup-parent values, and kernel namespaces are all assigned to the “infra” container.
  This is critical to understand, because once the pod is created these attributes are assigned to the
  "infra" container and cannot be changed. For example, if you create a pod and then later decide you
  want to add a container that binds new ports, Podman will not be able to do this.  You would need
  to recreate the pod with the additional port bindings before adding the new container.
  

I'm new and only now learning containers/podman, so I don't understand any nuances that may make this a deliberate design decision.
Is this a deliberate design decision or just not implemented yet?

I would also like this for network settings in general.

Suggest potential solution

I would like a podman subcommand for modifying port / network settings.

Have you considered any alternatives?

No response

Additional context

No response

[deliciouslytyped]

I just realized I was still on 3.4 . Podman 4.1 appears to have a podman network update command, so I imagine that would be a good extension point.
Edit: Actually this is probably not what I think it is.

These two may also be relevant?:

• Support modifying container configuration #376
• RFE: podman container clone command #9540 (xref from the previous)

[Luap99]

We really try to avoid changes after the original container creation as much as possible. It is extremely difficult to support that. There are just to many corner cases. I also cannot stress enough that port forwarding in its current form is already extremely hard to maintain for me as there are so many ways to do it.

On a stopped container this may be easy enough to support as we only would need to update the config in the db but for running containers it is just way to difficult.

[Arcitec]

@Luap99 Being unable to edit port and folder mappings on a stopped container is the only thing holding me back from loving Podman. If a container is stopped, it should be safe to edit these things?

[Luap99]

Yes on a stopped container it is safe (just some db edit to change the mapping there), however exposing such functionality is still code we have to support. And at the point you stopped the container you could just create a new one anyway? Containers should really be treated as immutable for the most part.

[deliciouslytyped]

Not recommended obviously, but if you really need to do it, I have indeed just edited the config stored in the db.
I haven't been able to find much in terms of BoltDB cli tools, but https://github.com/br0xen/boltbrowser is one, though it's missing some functionality to really make this not a huge pain. However, IIUC there is now an experimental (?) sqlite based backend for podman which should be a lot nicer to do this with.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

We do not plan on implementing this feature, since you can just use --replace.

[PoneyClairDeLune]

We do not plan on implementing this feature, since you can just use --replace.

Is there a way to modify published ports when the container is stopped?

[rhatdan]

Sorry no, not in a supported fashion.

[PoneyClairDeLune]

Sorry no, not in a supported fashion.

Could this be ever implemented? It's possible in Docker, but since Podman uses a database file, it's next to impossible to do so manually.

[Luap99]

There is no plan to ever implement this. The supported way is to recreate the container.

[PoneyClairDeLune]

There is no plan to ever implement this. The supported way is to recreate the container.

So how to recreate the container while retaining all data present in the previous container?

[Luap99]

Use podman commit to commit the container to an image, then you can run a new container based on the created image.
But in general it is best to just keep your data on volumes and not in the image.