Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Quadlets might make me finally stop using docker-compose

major.io

Post reply on HN
Print view View original

61–70 of 212 posts

Re: Quadlets might make me finally stop using docker-compose

#61

Post by XorNot »

sofixa wrote: post #57
rewmie wrote: post #16

Earlier quoted context omitted.

INI files are not specified anywhere, so it ends up being a implementation-defined free-for-all. 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.

> I don't understand the hate that YAML gets 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.

This has literally never been a problem for me despite writing considerable amounts of YAML.

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.

Re: Quadlets might make me finally stop using docker-compose

#62

Post by voidnap »

hexo wrote: post #53
gigatexal wrote: post #35

Earlier quoted context omitted.

I mean the best part about open source and Linux is that you have choice. Do you want to run an OS devoid of SystemD? Fine. Will you be going against the tide and leaving a large part of the ecosystem behind? Yup. 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…

systemd is extremely intrusive. anything dependent on it is a failure.

This is such a bizarre comment. I run systemd a number of Linux machines currently but does that mean they are failing? Is taking advantage of systemd's features a failure? They run and do their function so in what sense are they failing or what does failure mean?

Re: Quadlets might make me finally stop using docker-compose

#63

Post by yrro »

v3ss0n wrote: post #46
TekMol wrote: post #29

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?

What worse is , it screws up the firewall rules. Podman avoid that so , quadlets should be fine? Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

Hmm, podman also creates rules in the nat table if that's what you're talking about--_if_ you tell it to publish ports.

Of course, if you run rootless then there's no possibility to do so. :)

Re: Quadlets might make me finally stop using docker-compose

#64

Post by worksonmine »

jve wrote: post #51
v3ss0n wrote: post #46

Earlier quoted context omitted.

What worse is , it screws up the firewall rules. Podman avoid that so , quadlets should be fine? Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

Yeah, I also tried ~months ago. To be fair, I'v only tested out dev containers with docker, so I'm too weak to debug things what went wrong. Any article out there on how to have windows + wsl2 + podman + vscode devcontainers working?

I suggest you start by just getting plain podman running the docker.io/hello-world container to reduce the complexity and simplify debugging if anything goes wrong. It's been about a decade since I last touched windows but if wsl2 is 1:1 with Linux the official podman guide should be straight forward.

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.

Re: Quadlets might make me finally stop using docker-compose

#65

Post by yrro »

jauntywundrkind wrote: post #4

Overall this looks really good but it also obfuscates whether how & where this really integrates with systemd. 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 mi…

The reason it works at all is because of systemd's extension mechanisms.

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
After a `systemctl daemon-reload` an `oxidized` service springs into being.

    [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
During the daemon-reload, systemd invoked /usr/lib/systemd/system-generators/podman-system-generator, which read the files in /etc/podman/systemd and synthesized a systemd service for each of then, which it dropped into /run/systemd/generator, which is one of the directories from which systemd loads unit files.

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
No deep magic, just the pleasant feeling you get when you see layered systems interacting together without cross-cutting.

You can learn more about the systemd generator extension mechanism at: https://www.freedesktop.org/software/systemd/man/systemd.gen...

Re: Quadlets might make me finally stop using docker-compose

#66

Post by jacooper »

worksonmine wrote: post #12
xgbi wrote: post #3

Say what you want about docker compose, but when I see the amount of scaffolding necessary for this, with so many catch words like butane or ignition, I’m happy with my good ol’ docker composé file where everything is neatly organized. In one glance I can see what is deployed, depends on what and what net / volume is used. For simple projects, it’s hard to beat

I also miss the simplicity of compose, but for me running rootless is worth the tradeoff. It also forced me to rethink how I used containers and I realized many times a simple podman_run.sh is enough. It also helped me understand containers better because there was less magic going on, sometimes limitations can be good.

Docker has native rootless support. But networking is a joke like podman.

Re: Quadlets might make me finally stop using docker-compose

#67

Post by hobo_mark »

nisa wrote: post #34
asabil wrote: post #28

It's quite unfortunate that this article mixes up what's necessary for podman quadlets with coreOS concepts. 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]. [1]: https://www.redhat.com/sysadmin/quadlet-podman

> 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`. 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 ro…

butwhat?

> Butane (formerly the Fedora CoreOS Config Transpiler, FCCT) translates human readable Butane Configs into machine readable Ignition Configs.

igwhat? Why, WHY?!

Re: Quadlets might make me finally stop using docker-compose

#68

Post by cyberax »

INTPenis wrote: post #54

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…

The next step: systemkubed.

Re: Quadlets might make me finally stop using docker-compose

#69

Post by goku12 »

politelemon wrote: post #10

> However, as with watchtower, that’s another external dependency. Docker compose is part of docker now, it's just another subcommand.

While you're technically correct, docker compose uses yet another process supervisor (the docker daemon) while systemd is already capable of doing that. This is probably what the author meant by 'external dependency' - not the need to install compose separately. Quadlet delegates the supervision to systemd daemon, eliminating this duplication of supervisor functionality.

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.

[1] https://aurae.io/

Re: Quadlets might make me finally stop using docker-compose

#70

Post by prmoustache »

v3ss0n wrote: post #46
TekMol wrote: post #29

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?

What worse is , it screws up the firewall rules. Podman avoid that so , quadlets should be fine? Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

> Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

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.

Post reply on HN