1

LXD 4.20 released

 2 years ago
source link: https://lwn.net/Articles/875447/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

LXD 4.20 released

[Posted November 8, 2021 by ris]
The LXD team has announced the release of version 4.20 of the LXD system container and virtual machine manager.

This is one very busy release with a lot of new features.

VM users will be happy to see the initial implementation of live migration and core scheduling support. Container users are getting new configuration keys to set sysctls.

Then the bulk of the new features are all network related with peer network relationships, network zones for auto-generated DNS and SR-IOV accelerated OVN networks.

And lastly, on the clustering front, it’s now possible to better control what servers will be receiving new workloads.

(Log in to post comments)

LXD 4.20 released

Posted Nov 8, 2021 21:05 UTC (Mon) by ncm (subscriber, #165) [Link]

Is this a thing I might use in place of Docker, if I am using Docker now? If so, what about Docker or LXD might lead me to want to switch over? (I looked around and found something labeled an FAQ, but it had no information at all.)

(On a side note, why do projects in this space use YAML config files? It is such a nightmarish format.)

LXD 4.20 released

Posted Nov 8, 2021 21:34 UTC (Mon) by VayuDev (subscriber, #140813) [Link]

From my experience with proxmox, the biggest difference between docker and LXC (LXD) is that with LXC, your container is a whole simulated OS with it's own init system (systemd). You pick a Debian container, enter it, install your software, create a service file and enable it. With docker, you usually create Dockerfile which contains the commands to build an image for your application from another template image; you usually only run your own application within the container, not systemd.

In practice, LXC is much more similar to a VM than docker is, though I'm sure you could use both systems to do each other's job and behave like one another. That said, all that stems from my experience with proxmox, and I think LXC is pretty flexible (and complicated), so take all I said with a grain of salt.

LXD 4.20 released

Posted Nov 9, 2021 9:45 UTC (Tue) by bjartur (guest, #67801) [Link]

Applications that fork but don't reap zombies should be run under init. In Docker, that means PID 1 under Docker being a reaper (an init). Java Jenkins, applications, for example, should be run under an init. Otherwise zombies can accumulate. Unless, of course, your containers are short-lived.

LXD 4.20 released

Posted Nov 9, 2021 10:56 UTC (Tue) by smcv (subscriber, #53363) [Link]

init (pid 1) traditionally does two things: it's a subprocess reaper, and it's a service starter or service manager. The subprocess reaper role is extremely simple and uncontroversial: you can write one in a few lines of code, some shells like bash have this functionality built-in, and Docker provides a simple statically-linked subprocess reaper implementation at /dev/init in case the application doesn't. It's difficult to have an opinion about the subprocess reaper, because either it's implemented correctly or it isn't, and there's not much nuance beyond that.

The service starter or service manager role is the one that has caused endless debate about the relative merits of sysv-rc, Upstart, systemd, OpenRC, runit and others: a service manager has more complicated requirements and has had some design put into it, so it's reasonable to have opinions about it. Many service managers are integrated with the subprocess reaper because keeping track of child processes is something they would need to be doing anyway.

When using an application container (like the way Docker is generally used), something needs to take the init role for reaping subprocesses, but a service manager isn't needed: the init system just needs to start the top-level process of the single application in the container. Conversely, a full-system container (like lxc and systemd-nspawn) *does* have a service manager, so that it can start more than one service that will work together.

LXD 4.20 released

Posted Nov 8, 2021 21:51 UTC (Mon) by cjwatson (subscriber, #7322) [Link]

https://linuxcontainers.org/lxd/introduction/ seems like it might be a useful place to start, based on your question.

LXD 4.20 released

Posted Nov 8, 2021 23:08 UTC (Mon) by dowdle (subscriber, #659) [Link]

LXC provides system containers. Docker is application containers. Podman is both application and system containers although most users use application containers.

System containers actually predate Docker by about 12 years (commercial Virtuozzo [2001]) or 8 years (OpenVZ / Linux VServer [2005]).

LXD is a management layer on top which now includes management of KVM VMs and LXC system containers.

LXD 4.20 released

Posted Nov 9, 2021 0:36 UTC (Tue) by ctalledo (subscriber, #80668) [Link]

Agree with this.

But just FYI, one alternative that bridges the gap between Docker and LXD is Sysbox. It's a new "runc" that works under Docker or Kubernetes, and enables rootless containers to run most workloads that run in VMs (e.g., systemd, Docker itself, even Kubernetes itself).


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK