201–210 of 212 posts
Earlier quoted context omitted.
This one: https://pypi.org/project/docker-compose/
That's v1, which is EOL. Docker compose v2, written in Go, was released in 2020.
I still see no reason to use it.
Earlier quoted context omitted.
Idk what python you're talking about with docker compose
For real. Maybe he should try docker compose v2
docker-compose offers an alternative. It doesn't offer any genuinely new functionality. It may work for you if you don't know how to use the other alternative, or the other alternative is inconvenient for you for some other reason, but if it's not, it's just an extra tool that you don't need.
Earlier quoted context omitted.
I agree, and I think the author was unfortunately using coreOS because it's uncommon for cloud providers to have coreOS images nowadays, and therefore a good opportunity for him to slip in a referral code for VULTR. Is coreOS even maintained any more? I wouldn't expect it to be very secure if the most recent VM images were built in ~2020. Would love another writeup just using Ubuntu or some other bog-standard Linux d…
CoreOS was acquired by Red Hat, and now "Fedora CoreOS".offers similar concepts. Conveniently, RH also invented both Podman and systemd.
Earlier quoted context omitted.
> Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation So not a drop-in replacement then...
4 points: 1. Most of the issues I had that forced me to adapt a docker-compose was because I was using podman rootless and most people build docker-compose file with docker running as root in mind. mostly to have access to privileged ports. I guess running podman under root would have solved this but one of the reason I switched to podman in the beginning was for the rootless capability. In a way this wasn't much dif…
...until the point when they resigned any notion of versioning. You can't have a breaking change if you don't promise a stable behavior, see? /s
Not many people noticed that the top-level
version "3.9"
Earlier quoted context omitted.
For anything other than a hello world type project a compose file will fall over kinda quick. I would much prefer to (ahem) compose smaller things together and systemd is great for that.
I've been kinda partial to helm charts (on a k8s cluster). Standing up services is not awful. Have you used helm or similar? What do you think of these kind of tools?
Earlier quoted context omitted.
It's not type safe.
So is JSON, and all mainstream config formats actually. However, that stopped being a problem with JSON schema, which, despite the name, works on yaml too.
> So is JSON
Blink. I beg your pardon, JSON is strongly typed per RFC 8259 standard:
> JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).
The type system does not align well with any other type system out there (float/int ambiguity, no timestamps, etc.) but it's still better than any coercion.
To me, this big problem with Docker is that it does a ton of changes to my system, even when I don't use it. It runs a daemon, it uses a bunch of IPs, it mounts a ton of stuff ... Is there a reason for all that noise and complexity? There can't be a reason until I run a container, right? And even then, it seems way too much. Is it different when using Quadlets?
Related to Docker, I finally bit down and tried to do a simple deployment stack myself using systemd and OS-level dependencies instead of containers. I'll never go back. The simplicity of the implementation (and maintenance of it) made Docker irrelevant—and something I look at as a liability—for me. There's something remarkably zen about being able to SSH into a box, patch any dependency issues, and whistle on down the road.
I started using quadlets for new system designs a month ago and I feel like I'm neck deep in it now. My conclusion is that there is absolutely no reason to stop using docker-compose if your developers are comfortable running one command, on one file, in one git root. Quadlets are basically docker compose, in systemd. They've finally done it, systemd has it all and now it even has docker compose. ;) That's really all…
I've got a home server that runs docker compose as a service in systemd at startup. I'm naive, whats the difference between doing that and using these "quadlets"?
Earlier quoted context omitted.
systemd is extremely intrusive. anything dependent on it is a failure.
By my calculations, considering much of the world runs on RH/Ubuntu/Debian, all of which use systemd, things depending on systemd are far from being a failure, cos they'll run on the majority of systems.
I started using quadlets for new system designs a month ago and I feel like I'm neck deep in it now. My conclusion is that there is absolutely no reason to stop using docker-compose if your developers are comfortable running one command, on one file, in one git root. Quadlets are basically docker compose, in systemd. They've finally done it, systemd has it all and now it even has docker compose. ;) That's really all…
I've got a home server that runs docker compose as a service in systemd at startup. I'm naive, whats the difference between doing that and using these "quadlets"?
The approach is quite different from docker-compose and not really a substitute. It makes your individual containers into systemd services in an easier way than creating a unit file that calls `docker run`. But you still have to manually define networks in .network files, and configure all your dependencies in unit file syntax.
If you're very familiar with writing in systemd unit files, or really really want to use systemd to manage all container-related objects individually instead of having your container daemon do most of the work and a single compose file per group of related objects, you should consider switching. But in my experience there's little to be gained, a LOT to be lowt, and a lot of work to do the switch.