Behold, Incus: Check out this fork of Canonical's LXD 'containervisor' SUSE developer Aleksa Sarai has created Incus, a fork of Canonical's LXD code, with the backing of the now-former lead developer of the container-manager-cum-hypervisor. A month ago, Canonical announced LXD would not be independent any more, and the Ubuntu maker was withdrawing it from the Linux Containers project and taking …
A quickly looked up answer to "Why use LXD instead of Docker?"
Multiple processes can run inside the same container. It can run a single process per container which means that if one wants to run a z number of processes, one needs a z number of containers to run that process. LXD is faster than Docker for executing applications while using multiple processors.
However, I don't believe that is true - any number of processes can run in a single container. However, it's typically cleaner to separate out.
Maybe somebody can explain why they use it?
[Author here]
> Ultimately it seems LXD lost the war.
There hasn't been a war.
Docker is slowly dying, replaced by K8s and purpose-built and most saliently daemonless lightweight container systems to run under K8s such as CRIO and Podman.
LXD is designed for running system containers: entire Linux distros in a container on top of a different distro.
So, for example, you can run much of RHEL in a container on Ubuntu and inside that run some RHEL-only (or SLE-only) app, or more likely teetering pile of interrelated apps, that only work on RHEL, just so long as they don't demand the RHEL kernel.
Not that anyone would admit to doing it, but you could run some SAP product that only supports SUSE, in a SLE container on an Ubuntu host. As far as the app's concerned it's inside SLE but you don't need to manage any SLE boxes.
The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google's experience running production workloads at scale with best-of-breed ideas and practices from the community.
> Docker is slowly dying, replaced by K8s and purpose-built and most saliently daemonless lightweight container systems to run under K8s such as CRIO and Podman.
What I mainly see in my very limited worldview is docker used for local development, The resulting images or dockerfiles end up being deployed/built on these alternatives (K8S under whatever container runtime) in the dev/test/prod environments and being "basically perfectly compatible". Not sure if that's standard, but it's very much alive in my circles - just not used for running in production, production-like, or shared environments (and even before those environments were docker under K8S in those environments)
Does that seem fair/accurate view of the state of things elsewhere or am I blinkered?
Neither here nor there, but in personal projects I still like to use docker compose and sometimes a subset I'll port to k8s as a final step if it's something I'd like to keep running long term. But compose is so quick/simple to get running in comparison and so much more enjoyable to use in my view.
[Author here]
> I've run multiple processes under docker.
Sure you can.
Ad-hoc informal definition:
- no init, runs 1 binary: app container.
- has a normal init, runs any number of binaries: system container.
More real-world comparison:
App containers are transient, never get updated, and store all data in other containers or on servers that they access over the network. Need a newer version of the binary? Kill the containers, spawn new ones.
System containers look like a VM and have local storage, get updated, and generally act like a Linux OS instance, but they all share the same kernel, the same pool of RAM on the server, the same pool of disk space, etc.
SUSE (via Rancher) and RH (esp. via OpenShift) focus on selling into those lucrative trendy microservices deals with uncountable numbers of app containers, created and destroyed on demand. The "cattle" type of containers.
Ubuntu is trying to sell people on long-lived, individually maintained and managed system containers. The "pet" type of container.
Docker is more intended for running other peoples pre-created containery nonsense, but if you instead want many lightweight jails for multi-tenancy of traditional services a-la OpenVZ without writing a whole bunch of scripts, then LXD is better designed for that specific task. With that said, systemd is an even better fit if you want to jail every daemon individually for better security.
Personally, I find LXD a lot less nebulous than Docker.
Docker is one of those tools that kinda annoys me...it doesn't remove any complexity, it just re-allocates it.
You can always spot a tool that failed in it's mission to "simplify things" because it spawns a whole bunch of other tools to "simplify" managing the tool that exists to "simplify" things.
My preferred way to "containerise" things these days is using the container feature on Proxmox (LXC), get the container setup just the way I like it, then create a container template from it...I can then copy off that template and use it anywhere that has LXC (usually other Proxmox boxes).
Dead simple. I don't have to fuck around with config files, ansible scripts etc etc...I just build a container then template it. Absolutely ideal. It all stays nicely out of the way.
I prefer this approach because as an engineer I am in the business of building solutions, I'm not in the business of creating more work.
The nuts and bolts of a container solution are (should be):
1. Simplified deployment.
2. Repeatable configs / templates.
Anything outside of that is bloat.
The nice thing about Proxmox containers is you get a nice simple tar.gz file at the end of it when you create a template. Zero bollocks. Nothing has to be downloaded when you deploy, there is no setup process...the tar is simply extracted and becomes a container.
Moving them around is simple...you can put the tar file on a thumb drive and carry it about. Most importantly, everything is already there...there is no "setup process" the tar file is literally everything you need. Whereas a docker is just a set of instructions to build a template...a tar file is *literally* the template...to a lot of businesses that is important because creating templates, whacking them on a drive and locking them in a fireproof safe is peace of mind because the non-techie CEO knows that he has complete copies of machines that can be spun up relatively quickly in the event of a disaster...whether he has an internet connection or not...he knows that his business can be back up and running relatively quickly...and that is all he needs to know...he can know that, because you can demonstrate it very easily.
You walk with him to the safe, get the drive, you take it to a computer, you deploy a container from the template on the drive, then restore the data from a backup (on a different drive that is updated once a week and thrown in the safe). He can see that happening and it will cement in his mind the process that will occur should the shit hit the fan.
Docker offers absolutely none of this...for us as techies, we know it's probably fine...but from the point of view of a non-technical person, Docker is abstract as fuck...and honestly, I'd rather deal with the tar files on a USB drive than a fucking Docker script if the shit has hit the fan...it's just easier.
I'm sure many techies here that have dealt with dead servers and disaster recovery will agree.
I export (save) docker containers as tars. It works exactly the same. Walk it over to the other machine without internet access on a USB and import it and run it without internet access.
The layers approach is most common and has advantages but you don't have to use it.
"docker save" will give you a standalone container you're asking for. People don't do it because it's inconvenient and a dockerfile is for most use cases better or a repository more convenient.
https://docs.docker.com/engine/reference/commandline/save/
Docker images can also be saved as an atomic unit for copying and downloading to run under docker elsewhere, so that's not really an issue.
For mass reproduction and use of own-proprietary containers, clone-ability is not the distinguishing factor.
However, a separate issue is open-clone containers, when downloading cloned containers from other than a very reliable source. I claim that is very risky. This is just another version of dependency security risks.
Rather than downloading the cloned container, recreating from scratch using a script, and manually confirming what OS (for LXD) and what packages (for either) are used is perhaps a safer alternative? The same principal as compiling software packages.
So a thoughtful contributor of open-source containers would supply legible scripts just for that purpose. Rarely done however.
[Author here]
> Maybe somebody can explain why they use it?
The previous article about LXD, which is linked in the first paragraph of this story, explains the difference and distinction between LXC and LXD, and of their intended use cases compared to Docker, CRIO, K8s etc.
Which is why I wrote it, and why I linked to it. Was that not enough? If not, what more do you need? Tell me and I will try to ensure future articles have that coverage.
https://www.theregister.com/2023/07/07/canonical_takes_lxd_inhouse/
... which is linked in the first paragraph of this story,... ...Was that not enough?
That, I can help you with. The first paragraph of this story, as presently published is: SUSE developer Aleksa Sarai has created Incus, a fork of Canonical's LXD code, with the backing of the now-former lead developer of the container-manager-cum-hypervisor..
No link there.
Maybe you meant the second paragraph?
That has a link to "Announced".
Is "Announced" a link to a story about LXD? Perhaps, but if so that's still a problem. "Canonical Announced" is not informative as a link to a story about LXD.
I
[Author here]
> The first paragraph of this story, as presently published
This is a distinction, but I concede, an internal one.
The first paragraph of the story contains the link.
Before that is the *intro,* which house style dictates should always be in present tense and contain no links.
According to zabbly dot com
What is it?
Zabbly is the business name used by Stéphane Graber for his various projects.
It's a sole proprietership registered in the province of Quebec, Canada.
What does it mean?
The name Zabbly doesn't mean anything, it's a completely randomly generated name which happens to be easily pronouncable, spellable and most importantly wasn't already used by anyone!
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
