Docker compose is part of docker now, it's just another subcommand.
Kubelets in K8s also have similar duplication of supervisor functionality. Perhaps this is a good place to mention the Aurae runtime [1], which is designed to replace systemd, docker daemon, kubelet, etc on dedicated worker nodes. Sadly, its chief designer Kris Nova passed away recently in an accident. I wish the rest of the team the strength of carry her legacy forward.
However, I agree with your sentiment. It's basically a part of any modern Docker installation now. Calling it an external dependency "like watchtower" is not a fair comparison.
If you want to say that there are machines that don't have systemd which therefore cannot use quadlets, that's like arguing that something made for Linux is useless because "Linux is not present on most machines".
With quadlets, the only thing required is to drop a `.container` file in the right place and you end up with a container properly supervised by `systemd`. And this of course also supports per-user rootless containers as described in [1].
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 distro.
Conveniently, RH also invented both Podman and systemd.
Is it? He defines a .network file in that butane config without it won't work. Not really obvious. I'm sure this has a use-case and it's nice to have but personally I'm not convinced. You can switch on user-namespaces in docker-daemon or even run docker itself rootless - I guess if you are in Redhat land and use podman anyway it's an alternative but for instance where is this thing logging into? journalctl --user? Can I use a logshipper like loki with this? Is there something like docker compose config that shows the fully rendered configuration? I personally don't see the point and it feels like overly complicated.
> Currently, Promtail can tail logs from two sources: local log files and the systemd journal (on AMD64 machines only).
Whether it supports user services, I don't know.
[0] https://grafana.com/docs/loki/latest/send-data/promtail/
> Butane (formerly the Fedora CoreOS Config Transpiler, FCCT) translates human readable Butane Configs into machine readable Ignition Configs.
igwhat? Why, WHY?!
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 it is in practice. I'm going to continue using it because I'm a RHEL kinda guy, but don't make it up to be magic.
https://man.archlinux.org/man/quadlet.5.en#Kube_units_%5BKub...
I'm naive, whats the difference between doing that and using these "quadlets"?
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?
I also do not understand separation of services to different files. Is it supposed to be more convenient? With docker-compose, the whole application stack is described in one file, before your eyes, within single yaml hierarchy. With quadlets, it's not.
Lastly, I do not understand the author's emphasize on AutoUpdate option. Is software supposed to update without administrator supervision? I guess not. What are the rules for new version matching: update to semver minor, patch version, does it skip release candidates etc?
yes proper CI is a thing, and containers not being updated is actually quite a bit of an issue in the current software industry
especially if combined with custom registries auto update is quite a neet thing
oh also it's a SystemD feature to let SystemD manage your containers so why are you asking if it works without SystemD?
I guess given wordpress's security record taking breaking your site from time to time is preferable to your site being broken into from time to time.
As for the SystemD dependency, in this case the quadlets can not even be compared to docker-compose, nor be a replacement to it. Docker-compose always was independent of init system, where as quadlets are strictly tied to SystemD-based distros. E.g. users of Alpine, Gentoo won't be able to replace their compose stacks with quadlets.
Whereas with Docker it's one file, one command and you're done, you don't have to deal with anything else.
You use .container for a single container, .kube for all-in-one pods, .network for networks, and .volume for volumes. It has all the stuff it's just broken down in a more (imho) sysadmin friendly way where all the pieces are independent and can be independently deployed.
So I had to add --userns keep-id to my container unit what caused all sort of problem because of podman apparently.
So you always end up with the kind of investigation & fiddling that shouldn't be necessary after 10 years of docker & containers.
For images intended for rootless deployments e.g. podman, take a look at the onedr0p container images, https://github.com/onedr0p/containers
I have been trusting the plan but I notice that after 10 years of container industry standard etc. we have to search for podman friendly images to enjoy integration with the common Linux service manager...
Now if container-based Linux distributions are the future I'm starting to wonder if we are not gonna soon see RedHat & co. packaging docker images in RPMs to make sure guarantee things work together & people don't badly mess up the security...
Maybe everything is this easy & good. Maybe this is an /etc/systems/system/WordPress.quadlet file, part & parcel to everything else in the systemd-verse. But it doesn't say clearly whether it is or isn't. It's an acontextual example.
I think it's powerful tech either way, but so much of the explanation is missing here. It focuses on the strengths, on what is consistent, but isn't discussing the overall picture of how things slot together.
In many ways I think this is the most interesting frontier for systemd. It's supposedly not a monolith, supposedly modular, it so far that has largely meant that components are modular, optional. You don't need to run the pretty fine systemd-resolvd, for example. But what k8s has done is make handling resources modular, and that feels like the broad idea here. But it seems dubious that systemd really has that extensibility builtin; it seems likely that podman quadlet is a secondary entirely unrelated controller, ape-ing what systemd does without integrating at all. It seems likely that's not a podman-quadlet fault: it's likely a broad systemd inflexibility.
Could be wrong here. But the article seems to offer no support that there is any integration, no support that this systemd-alike integrates or extends at all. Quadlet seem to be a parallel and similar-looking tech, with deep parallel, but those parallels from what I read here are handcrafted. Jt's not quadlet that fails here to be great, ut systemd not offering actual deep integration options.
Either this must be some systemd weirdness that I thankfully haven't had to deal with until now, or I'm misunderstanding something.
Did I understand correctly you don't specify which services you need but rather which ones depend on your service? So if your service doesn't start you'll need to check the configuration files of all other services to figure out which dependency is preventing it from starting?
You can run your docker-compose file, then run "podman generate kube" and you will get a Kubernates yaml file.
Then you can run:
$ escaped=$(system-escape ~/guestbook.yaml)
$ systemctl --user start podman-kube@$escaped.service
And you can enable it to start on boot. It will read the yaml file and create the pod.
Nothing can kube better than the kubelet! The new sidecar support for init containers can be used today. Every other abstraction is playing catch up
But this only makes me like docker even more :)
I used a very similar approach in the (now EOL'ed, gonna be replaced by full K8s) infra at $DAYJOB. My main reason to stick with docker-compose is because developers are familiar with it and can then easily patch/modify the thing themselves. Replacing with something systemd will add a dependency over the people that know systemd (which are not usually application developers in your average HTTP API shop)
Classical definition: > A word consisting of four bytes
Quad implies 4 something or rather. What does it refer to here? 4 sections of configuration?
> The original Quadlet repository describes Quadlet this way:
>> What do you get if you squash a Kubernetes kubelet? A quadlet
> What do you get if you squash a Kubernetes kubelet?
> A quadlet
So it's based on reinterpreting the root "kuber-" which ultimately means something"to do with "turn", as "cube", and then metaphorically reducing a cube to a square.
- Node starts up with a container daemonized
- Automated updates of the registry image
- A nice single arg to pass to your cloud provider CLI userdata that launches the OS + container (vultr-cli in this case)
I guess you can do something similar with any linux userdata but the script wont be as clean. Has anyone built something lite to launch docker containers on boot in ubuntu (this is particularly helpful for cloud provider CLIs) without writing the whole script manually? Something nicer than `apt update && apt install -y docker && docker run --rm --restart-always ...` that includes the registry autoupdate.
Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run containers as systemd services (questionable choice, but probably there are people who want that)...
What am I missing?
The way I do it is by starting podman's systemd service which exposes a docker compatible API over a Unix socket.
Then export DOCKER_HOST pointing to the socket and you can run docker-compose with podman transparently.
there are also some issues with keys being all string by default making some things like linting harder and allowing more less standard ways to get something done, e.g. in json true is true in init files all of true, 1, yes, y and others might be true depending on the application (but then yaml no problem is worse)
also there is no clear single standard for init files
through this is where toml comes from it took the general layout ideas behind init files but give it a strict standard and strict string vs. bool vs. float types and a bit more nesting capabilities and fixes some string distance escape issues, etc
Also, YAML supports data structures that INI files don't.
I don't understand the hate that YAML gets. If you're not tasked with writing a parser, the data format just works as expected.
https://noyaml.com/ is a decent overview of exactly how shit it is.
But outside of that, using spaces for logic is extremely error prone if you go past 10-15 lines and 2-3 levels deep.
NI: Nicaragua
NL: Netherlands
NO: Norway
python: 3.2.3
numpy: 2.1
octal: 042
Container orchestration always seemed like a natural progression as systemd already manages cgroups for other services.
Unified plain text format.
For simple projects, it’s hard to beat
The basic usage of podman quadlets is putting an `app.container` in `/etc/containers/systemd/` containing something like the first snippet and then starting the unit. For someone familiar with systemd, this seems very very nice to work with.
The reliance on systemd is an issue on its own. Much has been said about its intrusion in all aspects of Linux, and I still prefer using distros without it. How can I use this on, say, Void Linux? Standalone Podman does work there, but I'm not familiar if there were some hacks needed to make it work with runit, and if more would be needed for this quadlet feature.
Just call things what they are.
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.
Systemd had dependencies between services and containers since forever.
The only difference here seems to be podman instead of systemd-nspawn.
I'm not familiar enough with the lower level details to know how it works, but it certainly feels less like you are making "a ton of changes to the system" compared to docker
I'd be curious what failed to build under podman. I have been using podman as a replacement for docker for the last 3 years and haven't found any blocker. Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation but if you know the difference between docker and podman you can build and run anything that also run on docker.
Of course, if you run rootless then there's no possibility to do so. :)
Yes! And it has a hard dependency on iptables, which I have removed from all my servers long ago in favor of nftables. Grrrrrr.
Any article out there on how to have windows + wsl2 + podman + vscode devcontainers working?
To make it simple at the point of use. If developers had to configure firewalls and bind mounts for Docker to work, it never would have taken off as much as it did.
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.
No. It's just Docker being shit.
This is at best hyperbole and at worst nonsense. Come on, at least put some effort into drawing the line of complexity a little clearer.
docker-compose -f /<dir>/docker-compose.yaml -d
[1] https://www.freedesktop.org/software/systemd/man/systemd.gen...
[2] https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-w...
Maybe this helps. Picking a random example container unit...
[root@xoanon ~]# cat /etc/containers/systemd/oxidized.container
[Unit]
Description=Oxidized
[Service]
ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid
[Container]
Exec=oxidized
Image=docker.io/oxidized/oxidized
User=972
Group=971
NoNewPrivileges=yes
ReadOnly=yes
RunInit=yes
VolatileTmp=yes
Volume=/var/local/oxidized:/var/local/oxidized:rw,Z
PodmanArgs=--cpus=1
PodmanArgs=--memory=256m
Label=io.containers.autoupdate=registry
Environment=OXIDIZED_HOME=/var/local/oxidized
[Service]
Restart=always
[Install]
WantedBy=multi-user.target
[root@xoanon ~]# systemctl status oxidized
● oxidized.service - Oxidized
Loaded: loaded (/etc/containers/systemd/oxidized.container; generated)
Active: active (running) since Sat 2023-09-23 09:53:11 UTC; 2 days ago
Process: 221712 ExecStopPost=/usr/bin/rm -f /run/oxidized.cid (code=exited, status=219/CGROUP)
Process: 221711 ExecStopPost=/usr/bin/podman rm -f -i --cidfile=/run/oxidized.cid (code=exited, status=219/CGROUP)
Process: 221713 ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid (code=exited, status=0/SUCCESS)
Main PID: 221799 (conmon)
Tasks: 8 (limit: 98641)
Memory: 169.0M
CGroup: /system.slice/oxidized.service
├─libpod-payload-b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390
│ ├─221801 /run/podman-init -- oxidized
│ └─221803 puma 3.11.4 (tcp://127.0.0.1:8888) [/]
└─runtime
└─221799 /usr/bin/conmon --api-version 1 -c b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390 -u b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390 -r /usr/bin/crun -b /var/lib/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata -p /run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/pidfile -n systemd-oxidized --exit-dir /run/libpod/exits --full-attach -l passthrough --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/oci-log --conmon-pidfile /run/containers/storage/overlay-containers/b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /run/containers/storage --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /run/libpod --exit-command-arg --network-config-dir --exit-command-arg --exit-command-arg --network-backend --exit-command-arg cni --exit-command-arg --volumepath --exit-command-arg /var/lib/containers/storage/volumes --exit-command-arg --transient-store=false --exit-command-arg --runtime --exit-command-arg /usr/bin/crun --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mountopt=nodev,metacopy=on --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg b78fd35eeb591012534d267c963cdbb78316fe498c9acf424ea443a7a6ac5390Learn more at:
Sep 26 00:03:05 xoanon oxidized[221803]: I, [2023-09-26T00:03:05.807594 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 01:03:15 xoanon oxidized[221803]: I, [2023-09-26T01:03:15.083603 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 02:03:24 xoanon oxidized[221803]: I, [2023-09-26T02:03:24.414821 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 03:03:33 xoanon oxidized[221803]: I, [2023-09-26T03:03:33.677828 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 04:03:42 xoanon oxidized[221803]: I, [2023-09-26T04:03:42.983589 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 05:03:52 xoanon oxidized[221803]: I, [2023-09-26T05:03:52.297830 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 06:04:01 xoanon oxidized[221803]: I, [2023-09-26T06:04:01.637348 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 07:04:10 xoanon oxidized[221803]: I, [2023-09-26T07:04:10.935352 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 08:04:20 xoanon oxidized[221803]: I, [2023-09-26T08:04:20.199651 #2] INFO -- : Configuration updated for /192.168.89.5
Sep 26 09:04:29 xoanon oxidized[221803]: I, [2023-09-26T09:04:29.553178 #2] INFO -- : Configuration updated for /192.168.89.5
Far from being a parallel service control mechanism (á la Docker), this is proper separation of concerns: the service is a first-class systemd service like any other; the payload of the service is the podman command that runs the container. We can introspect this a bit to examine the systemd unit that was generated:
[root@xoanon ~]# systemctl cat oxidized
# /run/systemd/generator/oxidized.service
# Automatically generated by /usr/lib/systemd/system-generators/podman-system-generator
#
[Unit]
Description=Oxidized
SourcePath=/etc/containers/systemd/oxidized.container
RequiresMountsFor=%t/containers
RequiresMountsFor=/var/local/oxidized
[Service]
ExecStartPre=/usr/bin/rm -f /var/local/oxidized/pid
Restart=always
Environment=PODMAN_SYSTEMD_UNIT=%n
KillMode=mixed
ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
ExecStopPost=-rm -f %t/%N.cid
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N
ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --log-driver passthrough --runtime /usr/bin/crun --cgroups=split --init --sdnotify=conmon -d --security-opt=no-new-privileges --read-only --user 972:971 -v /var/local/oxidized:/var/local/oxidized:rw,Z --env OXIDIZED_HOME=/var/local/oxidized --label io.containers.autoupdate=registry --cpus=1 --memory=256m docker.io/oxidized/oxidized oxidized
[X-Container]
Exec=oxidized
Image=docker.io/oxidized/oxidized
User=972
Group=971
NoNewPrivileges=yes
ReadOnly=yes
RunInit=yes
VolatileTmp=yes
Volume=/var/local/oxidized:/var/local/oxidized:rw,Z
PodmanArgs=--cpus=1
PodmanArgs=--memory=256m
Label=io.containers.autoupdate=registry
Environment=OXIDIZED_HOME=/var/local/oxidized
[Install]
WantedBy=multi-user.target
You can learn more about the systemd generator extension mechanism at: https://www.freedesktop.org/software/systemd/man/systemd.gen...
[Install]
WantedBy=multi-user.target
i.e., when you run 'systemctl enable whatever.service', it will be symlinked into '/etc/systemd/system/multi-user.target.wants'. And 'systemctl show multi-user.target' will show 'whatever.service' in its Wants property.
https://www.freedesktop.org/software/systemd/man/systemd.uni...
During bootup of a headless system, the 'default' target is usually multi-user.target, so what we've done here is ensure that whatever.service will be started before the machine finishes booting.
https://www.freedesktop.org/software/systemd/man/bootup.html
One of its main design goals is a fast system startup, to do that it does need know the dependency ordering of all services.
I don't know why it's being used in that way for these containers. It'd be easier to just add a Wants line on Caddy.
Using a recent HN submission to spin up a local vector stack for analyzing notes, https://github.com/memgraph/odin/blob/main/docker-compose.ym...
How would you suggest a bash script handle configuring all the different images, their ports, and ensuring services are spun up in the correct dependency graph (parallel where possible), and are exposed to each other as a reliable host name over a subnet without polluting the host network?
And then how is that bash script extendable so it's not a custom script every time?
So, how would I go about that in Shell? I don't see a problem. Can you point to a specific problem? All these settings in your example easily translate into docker commands.
Basically the appeal is "one command > everything running" when you have multiple services working together, which sure, you could do with imperative shellscripting, but for people who don't spend their daily time writing shellscripts, something declarative like YAML is usually easier to get started with, especially when you only revisit it sometimes.
Python people generally have either installed by default in their OS, or already using because of some other system. I wonder how many developers don't have Python at all on their systems already?
But I can accomplish this with Shell script... And no need to deal with Python, its broken dependency management, poor piping / I/O in general, bugs in the docker-compose itself... What do I win by having to suffer all these problems?
> who don't spend their daily time writing shellscripts,
Do you write docker-compose scripts daily? Seriously? Why? My impression was that you write that once and edit very infrequently (like maybe once a month or less). So, in terms of time investment it doesn't seem to make much of a difference. Also, I see no value in imperative vs declarative approaches here. It's actually hard to understand what is going to happen when you use declarative style because you need to rely on and have a very deep knowledge of the imperative aspect of the system interpreting your declarations to be confident of the end result.
> Python people generally have either installed by default in their OS,
Being one of "Python people" I have Python 3.7 thru 3.12 built from respective heads of cPython project installed on my work laptop. I would hate to have to add more to support a tool with dubious (or as is my case extraneous) functionality.
Also, being one of those "Python people" who deals with infra, I had to import docker-compose code into my code and deal with it as dependency, both with its CLI and its modules. And... it's not good code. Well, like the wast majority of Python is a piece of garbage. Particular feature of docker-compose that stands out is that it was written by "Go people" with poor command of Python, so it's "Go written in Python" kind of program.
Also, people who write docker-compose don't care about how it interacts with other packages, and this shows in how they define their dependencies (very selective versions of ubiquitous libraries, eg. requests) that will almost certainly not play well with other libraries you'd use in this context (eg. boto3). I had plenty of headache trying to use this tool and had so far sworn never to use it in my own infra projects because of its dependency issues. If I ever use it (as in to deal with someone else's problems) I install it in its own environment. Which is yet another problem with its use because then you'd have to switch environments just to call it, and then you forget to switch back and things start behaving weirdly.
Among other things.
To setup/tear down software dev environments deployed locally, the root/rootless discussion isn't really relevant. Ease of deployment and ease of use are critical though, and Docker is above all a development experience victory.
I'm really not sure.
I mean some of the critique is very reasonable like inline tables needing to be inline but inline arrays do not.
But then they present something as INI file which most INI parser will not parse and is directly against much of their previous critique.
and why do I have the feeling that the author is constantly screaming for help internally while writing this article?
I'm not sure this is the criticism you think it is. Wow, so you basically have to add quotes to get strings in some ambiguous situations?
Yeah sure you could probably improve YAML by getting rid of these weird pitfalls, but that is a minor improvement. The alternative isn't something like TOML, because YAML is optimized for hierarchical configuration. It's every vendor implementing a different syntax such as Hashicorp with their HCL [0].
If that site lists all the complains that nitpickers managed to put together, it sounds like YAML is virtually perfect.
Also, to underline how silly and futile these nitpicking complains are, some YAML parsers already explicitly address silly things like the Norway problem.
Frankly, this is a phantom benefit: the first thing people do in brackety-languages is define an indent standard. And it's not like a brackety language magically saves you from mis-nesting things if a bracket ends up misplaced.
> 2-3 levels deep.
Same to python, all non-trivial code is like 4 level+ depth, big deal!
I normally write javascript and I switch to python easily from time to time. I cannot understand people who complain about spaces.
It's always easier to start with the bare minimum and build from there, and you will get a better understanding of the tools you're using.
You can still use all sorts of dependencies in the [Unit] section: https://www.freedesktop.org/software/systemd/man/systemd.uni...
This hasn't been true for quite some time. Docker compose v2, written in Go, was released in 2020; v1 finally officially stopped receiving security updates this summer.
I feel like we are kind of in this weird limbo where I know I need to move to a podman focused stack, but the tooling just isn't there yet. I guess that is what makes Quadlets interesting, but idk if a single tool will really emerge. There is also podman-compose floating around. I still feel like I should hold of on some stuff until a winner emerges. So at home I'm still on docker with compose files. Although I will be moving to kubernetes for... reasons.
Many Docker images also provide "semantic version tags". Wordpress does too, so if you run the image "docker.io/wordpress:6.3", you will get the latest 6.3.x version.
It's up to you (and the image publisher) to decide when to auto-update, and when manual intervention is necessary.
Of course this requires trusting the publisher of that image. But even if you build your own images, you still trust the base image. It's turtles all the way down.
But it's basically similar to running a "update" of you distros package manager automatically on the fly. (okay it's better due it having a smaller surface and somewhat better per package update schema controls)
And some people argue that you must not do so as it might unexpected subtle break your system.
And other say you must because (especially security) updates must be done.
And the truth is probably in between. (Like auto updates with self test and rollback, which in complex systems isn't trivial at all.)
Anyway especially for using local user space toolings on my computer I 100% will enable it. I mean iff it stops working I can fix it but if not (the normal case) it's low maintenance. Perfect.
Which is a thing now. My openSUSE MicroOS/Aeon machines default to running transactional-update every day, and updates take effect on the next reboot. Given that MicroOS is allegedly to SUSE as CoreOS is to Red Hat, I suspect the latter has similar defaults.
> Running containerized workloads in systemd is a simple yet powerful means for reliable and rock-solid deployments.
They say its reliable and rock-solid. Isn't that enough for you? /s
---
Honestly, the amount of companies who: Don't understand the problems, forgot history, and think we're innovating into new territory because of hyped up branding is utterly baffling in the whole container space.
I'm not saying they're all bad, and better common tools are a good thing. But i see so many companies operating at [required complexity level] + 1 in the hopes to no longer be bothered by simpler problems.
Could it be done with systemd and dbus? Can dbus be distributed among several systems like mmc on Windows? I have no idea, just some questions that popped into my head lately.
I’ve chosen to embrace systemd and learn it as it is the defacto standard it seems rather than fight what I think is a futile war against it. That being said. I won’t force you to use it if you don’t. But I do not see quadlets using systemd as a failing.
So not a drop-in replacement then...
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 different than modifying a deployment to work with docker in rootless mode.
2. part of the appeal of using podman is its compatibility with kubernetes yaml file so you tend to quickly switch away from docker-compose anyway. Also for self hosting, the systemd approach was more elegant, even before the quadlets support.
3. One would argue that docker-compose != docker/moby engine.
4. docker-compose has introduced breaking changes in its history which meant adapting your compose file or add flags at runtime such as `docker-compose disable-v2`
EDIT: adding points
...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"
As far as I know, this was introduced with the new networking stack (netavark).
I'm also using nix flakes, to keep the setup reproducible.
If you want to get started, I can recommend the following:
1. Install nixos. That will only take a few minutes, and you end up with a system in which you have a "/etc/nixos/configuration.nix" file. Now you can edit the config file, run "nix-rebuild switch", and the changes have been applied. Every change results in a new entry in the bootloader menu, so you can always rollback.
2. Check out this great blog series: https://www.jjpdev.com/posts/home-router-nixos/ It helped me a lot.
3. Use https://search.nixos.org/options to search config options (the stuff in your config file).
Note: The blogpost still uses the classic way of managing network devices. I use Systemd, which I think is nicer and more flexible.
Podman-compose isn't as good as docker but it exists, and you can run docker-compose with podman as the runtime. I don't need it as my environments are simple and even wrapping the commands in shell scripts would be overkill. But the option is there.
It's worth pointing out that if you're running on Fedora/RHEL then containers are confined to the container_t domain, with a unit per-container MCS label. SELinux policy will prevent a process that has broken out of its namespaces from being able to read/write files from the host or from other containers, or being able to kill or read the memory of or (I'm assuming, haven't checked) ptrace processes from the host or other containers.
If you are concerned that your dev machine is vulnerable but for any reason you decided to not do anything about it, them you might be happy to learn that it's possible to configure Docker to not run as root.
Why would you assume I'm not doing anything about it? Podman is one piece in my hygiene, not allowing npm scripts is another. It does make some things harder and most devs I work with don't even know it's possible and should be done. Assuming you aren't vulnerable and waiting for a problem to appear before solving it is doing it backwards if you ask me. Your kind of self-confidence is what usually gets people.
I could also point docker-compose to the podman socket (it's the default for the podman compose command), if that was something I needed. Pods do it for me these days, which was my initial point. Even though compose is cool it's not really needed and wouldn't add that much for me these days. I've been using podman so long that I don't see the point in going back to docker, changing the default when what I'm using was built to fix that issue to begin with.
What point are you trying to make? I can live without docker.
I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.
INI isn't specified, thus you cannot claim that the INI format does something a certain way.
The best shot at a specified INI file format might be TOML, and even that format is subjected to the same type of criticism.
> 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.
mother_of_god.gif
If those 9 lines are identical you can probably simplify quite a bit with extension fields and yaml anchors. [0]
You would put
logging: *default-logging
[0] https://docs.docker.com/compose/compose-file/compose-file-v3...
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.
Homeserver: Ryzen 3950x, 64GB RAM, Ubuntu 22.04 DNS: 1 RPi 3B+ and 1 RPi 400 running pihole and Unbound Edge router/firewall: Palo Alto PA-440 Switch: Cisco 2960 24-port w/PoE AP: Aruba AP-345 in Instant mode
I still see no reason to use it.