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.
The modularization was a security nightmare. These plugins needed elevated privileges, a d they all needed to handle security themselves, and as I hope you are aware, Flash was atrocious with security.
Having a single "plugin" system means you only need to keep that one system secure. That's hard enough as it is, but it's at least tractible. And modern browsers have done a pretty good job securing the javascript sandbox.
I don't think that's true. I think there just weren't as many attacks because there weren't as many internet users. Yet I also remember getting viruses all the time (at least once/year) because of some vulnerability or another, and that's with being careful.
You should take off those rose colored glasses.
I appreciate that people not knowing as much about security is problematic, but that's because the average person is far more secure than they were even 10 years ago. Getting a virus is pretty rare these days, Microsoft has really stepped up their game with Wndows and browsers have as well. I haven't worried about getting a virus for many years now, and that's thanks to the proactive security work in sandboxing and whatnot that limits exploits.
A lot of the scams and whatnot these days either attack outdated systems (esp. insecure routers running default creds) or merely use social engineering because you can't simply use an off-the-shelf flash exploit or something to get privilege escalation to install your malware. Attacks certainly exist, but they're far less common than they were 10-20 years ago as people started being online constantly.
Yes, I am annoyed at JavaScript being enabled constantly and not having fine-grained control over specific permissions (mostly just location, mic, camera, and storage).
Unfortunately, that ship has sailed. But I still very much prefer the modern "everything uses JavaScript" to the old insecure Flash and Java applets.