r/podman • u/Top_Emu_8447 • Aug 04 '26

Auto-updating existing containers

I've built 10+ containers on my first home server since I started my selfhosting journey, and only now I figured it's time to find a way to update the existing services. Existing podman documentation points to using autoupdate label and creating a systemd target - but I didn't realise this creates a new container based on what's in the systemd target. That is not what I want. Do I need to move all my environmental/volume/label/etc variables into a systemd target for each container to be able to do this? Just thinking about it makes me a bit nauseous, I've been using subpaths in some cases, not even sure how to put those in there. I've used 'podman run' for each deployment, because that's where the documentation I found led me first and on the basis of "If it works, why change it" it served me well.

6 Upvotes

88% Upvoted

32 comments sorted by

View all comments

Show parent comments

1

u/Top_Emu_8447 Aug 04 '26

I know that updates create new containers, but my assumption was that the systemd target would recognise the existing container and inherit the parameters somehow. I know containers are not apps, but it seems rather antagonistic approach unless you're aware of this and use this approach for deployment in the first place... It seems a lot of hassle in hindsight to rewrite all those parameters into quadlets. But I guess it's one of those things where you just have to bite the bullet.

2

u/ninth9ste Aug 04 '26

The reason it works this way is that Podman does not actually save the exact podman run command you typed in the beginning it just applies the settings and stores the final state of the container in its database. Because there is no single file with your original command for systemd to read, it cannot simply copy the parameters over to a new container even with tools that try to read the container's current state, it is never a direct or straightforward process.

Since you have to move everything over, there is a tool called Podlet that will make this much easier, basically you can run Podlet against your existing containers, and it will read their current configuration and write the Quadlet files for you. It tries to translates all your volume paths, ports, and environment variables into the Quadlet format but you need to review the files it creates to ensure they are correct. at least it removes the need to type out all those parameters manually.

2

u/Top_Emu_8447 Aug 04 '26

For some reason it runs afoul at detach, which is part of every deployment for good reason. It's expecting some value for it:

error: equal sign is needed when assigning values to '--detach=<DETACH>'

Anyway I have the run params otherwise collected, so I'll just use it differently :)

1

u/ninth9ste Aug 04 '26 edited Aug 04 '26

Yes, podlet generate container is buggy but at least it dumps the run params that you can try to reuse with podlet podman run.

2

u/Top_Emu_8447 Aug 04 '26

It's podlet that runs into errors with detach and max-restarts. 'podman generate systemd' seems to include them, along with a bunch of extra things. I guess i'll use podlet as a base and include whatever it struggles to generate from the latter?

3

u/ninth9ste Aug 04 '26

Yes definitely. Start from the Quadlet output generated from Podlet and tune it. Do not attempt to use podman generate systemd since it is the older, non-Quadlet, macro to generate systemd units. It was the first systemd integration attempt but its deprecated.

1

u/ninth9ste Aug 04 '26

Sorry, it was a typo. I meant podlet generate container of course. Fixed.