this post was submitted on 04 Mar 2025
14 points (93.8% liked)

Selfhosted

46671 readers
1372 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
14
Question about quadlets and kube play (sh.itjust.works)
submitted 4 months ago by sugar_in_your_tea@sh.itjust.works to c/selfhosted@lemmy.world
5 comments fedilink hide all child comments
 

Current setup:

  • one giant docker compose file
  • Caddy TLS trunking
  • only exposed port is Caddy

I've been trying out podman, and I got a new service running (seafile), and I did it via podman generate kube so I can run it w/ podman kube play. My understanding is that the "podman way" is to use quadlets, which means container, network, etc files managed by systemd, so I tried out podlet podman kube play to generate a systemd-compatible file, but it just spat out a .kube file.

Since I'm just starting out, it wouldn't be a ton of work to convert to separate unit files, or I can continue with the .kube file way. I'm just not sure which to do.

At the end of this process, here's what I'd like in the end:

  • Caddy is the only exposed port - could block w/ firewall, but it would be nice if they worked over a hidden network
  • each service works as its own unit, so I can reuse ports and whatnot - I may move services across devices eventually, and I'd rather not have to remember custom ports and instead use host names
  • automatically update images - shouldn't change the tag, just grab the latest from that tag

Is there a good reason to prefer .kube over .container et al or vice versa? Which is the "preferred" way to do this? Both are documented on the same "quadlet" doc page, which just describes the acceptable formats. I don't think I want kubernetes anytime soon, so the only reason I went that way is because it looked similar to compose.yml and I saw a guide for it, but I'm willing to put in some work to port from that if needed (and the docs for the kube yaml file kinda sucks). I just want a way to ship around a few files so moving a service to a new device is easy. I'll only really have like 3-4 devices (NAS, VPS, and maybe an RPi or two), and I currently only have one (NAS).

Also, is there a customary place to stick stuff like config files? I'm currently using my user's home directory, but that's not great long-term. I'll rarely need to touch these, so I guess I could stick them on my NAS mount (currently /srv/nas/) next to the data (/srv/nas//). But if there's a standard place to stick this, I'd prefer to do that.

Anyway, just looking for an opinionated workflow to follow here. I could keep going with the kube yaml file route, or I could switch to the .container route, I don't mind either way since I'm still early in the process. I'm currently thinking of porting to the .container method to try it out, but I don't know if that's the "right" way or if ".kube` with a yaml config is the "right" way.

top 5 comments
sorted by: hot top controversial new old
[–] poVoq@slrpnk.net 5 points 4 months ago (1 children)

Don't use the kube stuff. That's entirely seperate from Quadlets and some sort of Kubernetes compatibility.

[–] sugar_in_your_tea@sh.itjust.works 2 points 4 months ago (2 children)

Awesome, thanks!

In terms of architecture, which is preferred:

  • separate pod per "app" (e.g. NextCloud), but all one network
  • separate pod and network per app
  • everything in one pod

I'd like to have one gateway, Caddy, so my cert renewal and proxying are all in one place, and I'd like those proxy configs to look like http://<container>

I'd prefer my containers not be able to talk to each other unless I specifically allow it. The second option would get me that, but I think it would force me to expose ports for each app to the system.

TL; DR - Can I have a "Caddy" pod that can see exposed ports from other pods, but hide those ports from regular system users? If not, I'll probably do the first option. I also want to be able to expose ports to the host on a per app basis if needed.

[–] Asparagus0098@sh.itjust.works 5 points 4 months ago* (last edited 4 months ago) (1 children)

I ran a podman quadlet setup as a test some time ago. My setup was a little like this:

  • Create a pod if the app uses multiple containers
  • Create a seperate network for each app (an app is either a single container or multiple containers grouped in a pod)
  • Add the reverse proxy container to all networks
  • I don't expose any ports to the host unless necessary

If you create a new network in podman you can access other containers and pods in the same network with their name like so container_name:port or pod_name:port. This functionality is disabled in the default network by default. This works at least in the newer versions last I tried, so I have no idea about older podman versions.

For auto-updates just add this in your .container file under [Container] section:

[Container]
AutoUpdate=registry

Now there's two main ways you can choose to update:

  1. Enable podman-auto-update.timer to enable periodic updates similar to watchtower
  2. Run podman auto-update manually
# Check for updates
podman auto-update --dry-run

# Update containers
podman auto-update
[–] sugar_in_your_tea@sh.itjust.works 1 points 4 months ago

Awesome, that's exactly what I want! I guess I missed where pods could be part of multiple networks.

I'm on podman 4.x, but I'm planning to upgrade the OS anyway soon, so it probably won't be an issue.

Thanks, you're a stud!

[–] poVoq@slrpnk.net 2 points 4 months ago

I use one pod per app more or less. The reverse-proxy conf depends a bit on the specific app so that depends, but it will probably work for most by sharing a network and exposing the ports in the pods