Hacker News Reader

Comment by happymellon | Hacker News Reader

After reading this, I still don't know if there is actually any difference from an end user point of view compared to OCI images.

Yeah, if you run Docker then you should only run one service, but that's not a technical limitation. I have images that have the standalone application, but you can also get them with a bundled database in the image for simplicity.

I can create a basic Debian container, connect and apt install anything I want. I can also snapshot the image using command tools.

So other than emotional arguments that you should run single services in a container from the OCI side, is there actually any difference?

View on HN

Basically, they have different use cases. Docker is designed to run a single application with immutable volume, while LXD is designed to run a (mutable) OS, like a VM. Sure, you can use Docker run an OS, but it is not designed for that.

Imagine you need to install an application that will install/persist some files to /etc, some files to /var, some files to /bin... etc. In Docker, you will need to install that application during build time, specify volume path, specify the ENTRYPOINT to the application and use the resulting image to run it. In LXD, you can exec into the container and install it, setup systemd service to run it on startup - exactly like what you would do in a VM.

What about Docker's design is incompatible with running systemd? Because that seems to be mainly what LXD containers offer over typical docker containers.

Docker has whatever you run be pid1, which systemd doesn't like.

It's easily fixable but requires customisation as docker doesn't want to support it by default.

So nothing about OCI images is incompatible, but docker specifically yes.

Would love to know the answer as well.

People that work with LXD typically say that LXD is closer to VMs than OCI containers. You can use one image and create a VM as well as a container from it with LXD. This brings things like full-featured kernel load with your process.

If that's the main differentiating factor though, that's deeply unconvincing to me, personally.

The OCI runtime spec includes vm-related config, so you can create a runtime bundle that specifies that the container should boot with a specific kernel, for example.

https://github.com/opencontainers/runtime-spec/blob/main/con...

Off the top of my head:

- Binding a port to a running container

- systemd/init daemons inside a non-privileged container

There is a lot more I've run into over the years though, despite often being considered peers there's some fairly big architectural differences under the hood.

"I can create a basic Debian container, connect and apt install anything I want."

Stateless (Docker) vs Stateful (LXC).

That's 2 different purposes.

Reply on news.ycombinator.com