Running Podman in production for years now, and I don't miss the Docker daemon one bit.

[larvitz@burningboard.net]

@andrew That blog article took me the longest of them all. A first draft had been lingering in my blog's git repo since November last year, and I went through numerous rewrites of various parts until I found them good enough. Today, I added the final paragraph about Ansible and decided to publish it before I end up waiting another 6 months

[db_geek@norden.social]

@Larvitz Maybe you could add the hint, that automatic starting of rootless quadlets needs an user, where lingering is enabled.
It can be found at the examples.
https://docs.podman.io/en/latest/markdown/podman-system-service.1.html
```
loginctl enable-linger <USER>
```

[woodsb02@fosstodon.org]

@Larvitz I love podman too, but recently I’ve been wondering about running rootless containers that aren’t tied to a specific host user. I’ve posted this as a discussion topic here - thoughts? https://github.com/containers/podman/discussions/28445

[patlikestechnology@infosec.exchange]

@Larvitz Thanks for the article.
I never went beyond podman compose because I couldn't really find beginner-friendly examples on how to use Quadlets in production, so this is a great reference on how to get started.

[ikket@mementomori.social]

@Larvitz very good starter pack for podman! I'd say all the normal operations described well and then some. Only thing more I use is exec for various debugging things or fixing something in storage. But if this is for docker users, there is no difference.

[rhempel@cosocial.ca]

@Larvitz Now I know what I'll be reading tomorrow!

I made the switch about two years ago and use Podman for embedded systems development. It's much easier than spinning up a VM and combined with VSCodium makes a nice IDE that allows remote debugging.

[art_codesmith@toot.cafe]

@Larvitz Interesting.
For me, the poor Compose support is one of the reasons I'm still sticking with Docker for development. Although, I think, the advantage of Compose files is simplicity (not having to commit to the whole systemd units system).

[art_codesmith@toot.cafe]

@Larvitz I might be wrong but, don't you lose basically all advantages of Podman by doing so? Having to give up daemonless and rootless.

[hanscees@ieji.de]

@Larvitz I have been planning tot migrate tot podman but life has many priorities
Will read

[art_codesmith@toot.cafe]

@Larvitz Thank you. I might have to dig a bit further into this.

[slash909uk@mastodon.me.uk]

@Larvitz nice!

I am halfway with podman; still have compose files launched from systemd units that I write myself - they are all basically identical except the home directory setting

I deliberately use compose start only, not run. I do not want restarts to be messing about pulling new images when I dont expect it!

Is there an equivalent to quadlets for alternative init tools? I would not want to lock myself into systemd right now seriousky looking at BSD.

[larvitz@burningboard.net]

@Slash909uk I doin't know of any alternatives. Quadlets are transniently transformed into systemd units by a generator. That's all very systemd specific.

FreeBSD's Podman port ships with rc.d service scripts already. You enable them with:

sysrc podman_enable=YES
service podman start
sysrc podman_service_enable=YES
service podman_service start

Then, containers started with --restart=always will be automatically restarted after a host reboot. Podman's internal restart logic handles this, with the podman service acting as the supervisor. This is the closest equivalent to what quadlets do on Linux.

[slash909uk@mastodon.me.uk]

@Larvitz thanks, good to know there is BSD support already

[arouene@mastodon.social]

@Larvitz Thanks for this great guide! I’m also a heavy user of
podman since years, and it's my number one solution for deploying services.

I had a question about the pod-in-pod deployment of forgejo / traefik,
giving access to the docker.socket allows thoses pods to create pods, but then
it can create privileged pods which mount the root volume of the host, right?
Even with the NoNewPrivileges arg?

Is there a way to control what a pod having access to the docker.socket can
create?

[larvitz@burningboard.net]

@Slash909uk

https://burningboard.net/@Larvitz/116357824557155636

[oliv@toot.iopush.net]

@Larvitz thanks. I never took the time to explore Podman, I think I will do it in close future thanks to your nice article

[svenhennessen@mastodon.social]

@Larvitz We are using podman for a year now as a local Docker replacement for developing distributed apps (.NET, Postgres, MSSQL, Kafka, etc.) on MacOS/Windows. The early quirks are gone, several months now without an issue.

[larvitz@burningboard.net]

@svenhennessen awesome! I use it to run production workloads on my linux server (forgejo, Nextcloud, Keycloak etc.). Worked for the last 4 years without any issue.

[bexelbie@toot.io]

@Larvitz I use podman for all my unorchestrated containers. Love it. How we I’ve stayed away from podman secrets as they used to be written to disk in plaintext. Did that get fixed?

[larvitz@burningboard.net]

@bexelbie The secrets (by default) are stored in json files under /var/lib/containers/storage/secrets .. Only protected by the file-system permissions. If you want them to be encrypted at rest, you could use something like OpenBao (OSS fork of Hashicorp Vault)