LXD: Containers for Human Beings | Hacker News Reader

LXD: Containers for Human Beings

secluded.site

41 pointstodsacerdoti18 comments

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?

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.

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.

LXD != LXC

This does a pretty good job at explaining how containers work, but the author seems to equate LXC with LXD, and doesn't even mention LXC once. If I remember correctly the actual container part of Linux containers (doing cgroups/namespaces) is LXC, then LXD is a management daemon frontend on top of that? I think a lot of people do use LXD as their frontend rather than interacting with LXC directly (especially Ubuntu users, since they seem to steer you that way), but if you're going to do a deep dive into containers like this it's a pretty huge omission not to explain the difference. Another really cool security feature of LXC they also could've mentioned was unprivileged/rootless containers.

Personally I had a very hard time with Linux Containers when using LXD and prefer using LXC directly. I can see why it's supposed to be user-friendly but it always reeked of Ubuntu bloat to me.

> If I remember correctly the actual container part of Linux containers (doing cgroups/namespaces) is LXC, then LXD is a management daemon frontend on top of that?

This is correct. LXD is a set of abstractions on top of LXC intended to make some aspects of working with LXC, like networking, a bit easier.

I did gloss over LXC vs LXD and I agree that it would be good to explain the difference between them. I'll make the edit and mention unprivileged containers when I get back to my PC this evening :)

> Canonical has decided to pull LXD out from under the Linux Containers entity and instead continue development under the Canonical brand. The majority of the LXD creators and developers have congregated around a fork called Incus.

Another solid move from Canonical. I guess I'll check out Incus then

There is more explanation regarding the fork in the readme

https://github.com/lxc/incus

The title makes it sound like The Matrix.

LXD may be "designed for humans", but Docker is designed for humans who just want to get shit done (e.g. regular people) rather than dick around with an OS. I used to be one of those nerds whose hobby was playing with distros. I lost patience for it. Docker lets me just get things done and get on with life.

> [application containers provide] reproducible builds

If only distros provided more package versions than just the tip. I don't mind if they get withdrawn due to massive security issues but if your image requires an installation of a library, you can't pin a version because most distros will remove it after releasing an update.

"This process can be trivially automated with shell scripts" [Author when speaking about LXD] --> I personally have the reverse experience after using Docker vs VM + pure bash scripts or Ansible.

Dockerfile/Docker-compose deployments fit in a couple of lines, where an Ansible deployments can spread easily across multiple playbooks.

Dockerfile is quite declarative (WORKDIR, USER, COPY, etc). It's easier to predict what it will do than when using a pure bash script or ansible playbook.

And even RUN, by leverage the cache layers, it gives you a bit of immutability + and increased provisioning speed.

Love LXD, however I've only had the opportunity to use it at home.

At work, I used it to build dev environment for several developers giving them isolated OS inside a single machine (host OS being the jump host for SSH and host OS Caddy reverse proxying web sites toward the guests), which was easy to do with LXD.

Reply on news.ycombinator.com