Docker socket activation?

[altano]

I'm reading in the docs that docker.service does not start at boot, and docker.socket does socket activation for Docker: https://www.flatcar.org/docs/latest/container-runtimes/getting-started-with-docker/#permanently-running-a-container

How is this supposed to work? When my Flatcar VM boots up, ssh port 22 is open. So if I ssh in, docker.service starts up and ssh succeeds.

But if I have an http container, e.g. on port 9000, socket activation doesn't work. Port 9000 is filtered (presumably because docker.service is the thing that modifies the firewall to open that port for the container), so there is no socket activation and docker.service never starts. That means every time Flatcar reboots, I lose my containers.

I can follow the docs to disable socket activation (and always start docker.service on boot) but I'm wondering why this is the default in the first place. How is it supposed to work? Was I supposed to mirror all my open docker container ports and open them in the Flatcar firewall to allow socket activation to work?

[jepio]

How is this supposed to work? When my Flatcar VM boots up, ssh port 22 is open. So if I ssh in, docker.service starts up and ssh succeeds.

ssh'ing in is not going to start the docker.service. Running something that connects to the docker.socket will start it (like docker info). The idea is that if you don't need the docker.service, it won't start and won't run.

But if I have an http container, e.g. on port 9000, socket activation doesn't work. Port 9000 is filtered (presumably because docker.service is the thing that modifies the firewall to open that port for the container), so there is no socket activation and docker.service never starts. That means every time Flatcar reboots, I lose my containers.

socket activation is only about the docker daemon itself. What you describe above depends on how you want the docker container to start:

• docker daemon restarts the container. daemon must start on boot, disable socket activation
• container started through a systemd unit. you can make this work with socket activation, but if you know the container needs to start on boot, no reason to wait for socket activation of docker daemon, you can disable socket activation as well.

There is also a way to plumb things together to get socket activation for the containers, but i'm not sure it's worth the hassle: https://github.com/neppoliyant/lambda/blob/master/docker-socket-activation.md.

I can follow the docs to disable socket activation (and always start docker.service on boot) but I'm wondering why this is the default in the first place.

Docker daemon is not needed for every usecase when running containers. Kubelet only requires containerd to be running nowadays.

Was I supposed to mirror all my open docker container ports and open them in the Flatcar firewall to allow socket activation to work?

To summarize - we're only talking about socket activation of docker daemon. Socket activating containers would be a highly specialized and advanced usecase.

[altano]

ssh'ing in is not going to start the docker.service

Oh, interesting. It's possible that as soon as I ssh'd in I ran docker stats and it was that that started docker.

Docker daemon is not needed for every usecase when running containers. Kubelet only requires containerd to be running nowadays.

Aha, okay, so that answers the million dollar question of why a Container Linux wouldn't start my containers on startup by default: not every container needs docker. I get it now.

Thanks!