I like to manage services maximally with systemd so it was a natural fit for me.
It did not seem difficult to set up web and database quadlets so they are properly networked.
I like to manage services maximally with systemd so it was a natural fit for me.
It did not seem difficult to set up web and database quadlets so they are properly networked.
I think the gap you have is in understanding that Podman Compose was meant to line up with the limitations of docker's compose, but technically is more capable.
Quadlet files let you do more complex workflows like deploying multiple copies of a service in your deployment that regular compose doesn't, while not running full kube.
The use I have is that I have something deployed in compose right now that I'd like to scale up on the box since i have the capacity for it, but dont want to deal with a full kube setup or the politic
Personally I've converted most of my single node k3s to using quadlet files instead as its less fragile. I absolutely deploy single containers in the quadlet. They show up in journalctl and the ergonomics are great.
How do you do inter-pod communication witg quadlet? I never figured that out with podman kube play and just moved back to staring conatiners and creating networks from a shell script
Thank you for those very convincing points. I think I'll give it a try at some point. It seems to me that what you're getting in return for writing quadlet configuration in addition to the kubernetes style pod/container config is that you don't need to maintain an independent kubernetes distro since podman and systemd take care of it and allow for system-native management. This makes a lot of sense.
It's a systemd-style way to manage podman containers that aims to be as easy to manage as compose/swarm. Not quite an integration, but operates similarly, and about as easy to read. Less heavy than managing a local micro-k8s cluster. That's about it.
Thank you, I think the "less heavy than managing a local micro-k8s cluster"-part was a great portion of what I was missing here.
Yup. I read it as "compose and manage containers with systemd."
Sure, there is a k8s layer abstracted into podman to do this, but you don't manage or interact with it. Everything is a systemd unit file, a simple text document with a well understood structure. Containers are started and logged like services.
Easy, direct, tidy.
Understood, thanks, but if I may ask, just to be sure: It seems to me that without interacting with the kubernetes layer, I'm not getting pods, only standalone containers, correct? (Not that I'm afraid of writing kube configuration, as others have inferred incorrectly. At this point, I'm mostly curious how this configuration would be looking, because I couldn't find any examples.)
I'm still new to this myself, but yes that's the gist of it. This isn't k8s or even k3s. It's an easy way to deploy a container via code on a single node system using the already present systemd for management. It let's you pretend that Linux handles containers natively like it does daemons.
This article from redhat has more information about the why and what.
From my understanding, I think you're right, it's some hybrid between single docker containers and just running k8s. If you're nearing the point where you need to start distributing your containers, personally you might as well just learn kubernetes. It's a massive learning curve, but frankly it's still the best option.
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!