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.
That's really hard to quantify, but yeah, innovation is probably happening faster today than it has in the past, which is likely due to:
People generally fear change, and change comes with work. Just because you were screwing on toothpaste caps in a factory yesterday doesn't mean that job will make sense forever. Nor should it. Jobs that don't need to be done by humans shouldn't, and people should instead take more useful and fulfilling jobs.
But sometimes people get caught in the crossfire, such as creative people having to compete with machines that can churn out decent, derivative works far more quickly. But that just means that the nature of work will change. If we use the printing press eliminating scribe jobs as an example, people have largely moved from reproducing text to designing new typefaces for branding purposes (or being commissioned for a calligraphy piece).
I think the same is happening w/ art right now. Traditional, 9-5 artists producing largely derivative work is going away, because most people don't need something truly original. So the number of artists will go down, but the truly great artists will still have a place in creating original works and innovating new types of art. We will still need people with an artistic eye to tune what the AI produces, so instead of manually creating the art, they'll guide the art w/ tools, much like how farmers don't hoe fields manually and instead use tractors (which will become increasing autonomous as time passes).
I've gotten into chess recently, and chess is a game that is largely "solved" by AI, meaning the best bot will beat or tie the best human player every time. There's still some competition between the best bots, but bot v human is pretty firmly in the bot camp and has been for years. However, chess is still a vibrant sport, and people still earn a living playing it (and perhaps more than ever!). It turns out we value the human aspect of chess, and I don't see that changing anytime soon. I think the same applies to art and other fields AI can "replace," because that human touch still very much has value.
If you fight technology, you will lose. So instead of that, fight for fairness and opportunity.
Well yeah, they're doing it because they think it'll make us more productive. For a business owner/exec, that means higher profits. For the rest of us, that usually means higher inflation-adjusted incomes (either through increased wages or reduces costs).