Incus – Next-generation system container, application container, and VM manager

by motorest • 1 year ago

142 89 1 year ago

manosyja• 1 year ago

What can this work with? It says „Containers and VMs“ - I guess that’s LXCs and QEMU VMs?

Yes, it uses QEMU under the hood for VMs and runs LXC containers. But also, since recently, you can run docker images in it. Very handy, especially since it has 1st class remote support, meaning you can install only the incus client and when doing `incus launch` or whatever, it will transparently start the container/vm on your remote host

Semaphor• 1 year ago

So it looks like a Proxmox alternative, this [0] goes into some reasons to switch. Main selling point seems to be fully OSS and no enterprise version.

[0] https://tadeubento.com/2024/replace-proxmox-with-incus-lxd/

hardwaresofton5• 1 year ago

It’s more like a Kubernetes alternative

loloquwowndueo4• 1 year ago

Not really, Kubernetes does a lot of different things that are out of scope for incus or lxd or docker compose for that matter or any hypervisor or …

moondev4• 1 year ago

Proxmox feels like a more apt comparison, as they both act like a controlplane for KVM virtual-machines and LXC containers across one or multiple hosts.

If you are interested in running kubernetes on top of incus, that is your kubernetes cluster nodes will be made up of KVM or LXC instances - I highly recommend the cluster-api provider incus https://github.com/lxc/cluster-api-provider-incus

This provider is really well done and maintained, including ClusterClass support and array of pre-built machine images for both KVM and LXC. It also supports pivoting the mgmt cluster on to a workload cluster, enabling the mgmt cluster to upgrade itself which is really cool.

I was surprised to come across this provider by chance as for some reason it's not listed on the CAPI documentation provider list https://cluster-api.sigs.k8s.io/reference/providers

snapplebobapple• 1 year ago

why would they think no enterprise version is a selling point? I can't learn stuff at work and apply it at home easily with this product. if anything proxmox needs a more enterprise option with faster support and it would be a better product for me. The caveat is there needs to be a credible way to keep the opensource open and available, which proxmox has done so far.

63stack4• 1 year ago

How do you handle updating the machine that Incus itself runs on? I imagine you have to be super careful not to introduce any breakage, because then all the VMs/containers go down.

What about kernel updates that require reboots? I have heard of ksplice/kexec, but I have never seen them used anywhere.

dsr_• 1 year ago

As with any such system, you need a spare box. Upgrade the spare, move the clients to it, upgrade the original.

loloquwowndueo4• 1 year ago

But then the clients have downtime while they’re being moved.

CoolCold5• 1 year ago

I'm not quite sure what's your question here? Very much similar to any other system which needs to reboot and you getting ready to these reboots in advance.

To some extent, of course things like vSphere/Virtuozzo and even LXD/Incus, and even simple Qemu/Virsh systems can do live migration of VMs, so you may care less on preparing things inside VMs to be fault taulerant, but to some extent.

I.e. if your team do run PostgreSQL, your run it in cluster with Patroni and VIPs and all that lovely industry standard magic and tell dev teams to use that VIP as entry point (in reality things bit more complicated with Haproxy/Pgbouncer on top, but enough to express the idea).

63stack4• 1 year ago

I missed the part that Incus supports clustering, for some reason I thought it's single node only.

rascul• 1 year ago

A little bit of context about where Incus came from:

https://lwn.net/Articles/940684/

Lightkey• 1 year ago

Not to be confused with the cirrus7 incus[0], which are fanless PC models based on the ASRock DeskMini series that I'm using right now.

[0] https://www.cirrus7.com/produkte/cirrus7-incus/

mrbluecoat• 1 year ago

or ear bone: https://en.m.wikipedia.org/wiki/Incus

burnt-resistor• 1 year ago

Nothing about resource (net, io, disk, cpu) isolation, limits, priorities, or guarantees. Not the same as a type 1 hypervisor. These qualities are needed to run things safely and predictably in the real world™, at scale. Also, accounting and multitenancy if it's going to be used as some sort VAR or VPS offering.

loloquwowndueo4• 1 year ago

Took a few seconds of googling to find this: https://linuxcontainers.org/incus/docs/main/reference/instan...

tok12• 1 year ago

Fun fact, Incus is being used as underlying infrastructure for the NorthSec CTF, i.e. in an "as hostile as it can get" environment. If you have close to a hundred teams of hackers on your systems trying to break stuff, I think it speaks for Incus and its capabilities regarding isolation and limits.

In case you are interested, Zabbly has some interesting behind-the-scenes on Youtube (not affiliated).

mdaniel8• 1 year ago

I would guess <https://www.youtube.com/watch?v=7A1yrLRNIp0> is a good starting point "Looking at the NorthSec infrastructure" from April, 2024

The YT description also points to https://github.com/zabbly/incus

maple3142• 1 year ago

If being used in a CTF counts, then running latest docker with no extra privilege and non-root user on a reasonably up-to-date kernel meets the definition of secure I think. At least for what I have seen, this kind of infrastructure is pretty common in CTF.

goku1210• 1 year ago

Incus supports Qemu/KVM VMs. And KVM is arguably a Type 1 hypervisor since it's part of the Linux kernel. So I guess it qualifies?

danofsteel32• 1 year ago

Incus is great when developing ansible playbooks. The main benefit for me over docker/podman is systemd works out of the box in incus containers.

mekster• 1 year ago

Not to mention the easy to use web UI.

anonfordays• 1 year ago

What makes it better than Vagrant for this use-case?

fuzzy2• 1 year ago

Doesn't Vagrant spin up full VMs? Incus/LXD/LXC is about system containers. So like Docker, but with a full distro including init system running inside the container. They are much faster to spin up and have the best resource sharing possible.

mdaniel8• 1 year ago

https://github.com/hashicorp/vagrant/blob/v2.4.7/LICENSE for one thing

goku1210• 1 year ago

Vagrant is not the right comparison against Incus for this use case. Vagrant is used to spin up VM or system container instances that are configured for software development and testing. But vagrant doesn't create those VMs or containers by itself. Instead, it depends on virtualization/container providers like VMware, Virtualbox, libvirt or lxc. In fact, you could create a provider plugin for vagrant to use Incus as its container/VM back end. (I couldn't find any, though.)

ssnepenthe• 1 year ago

I have never actually tested it, but my understanding is that systemd also works out of the box inside of podman containers: https://docs.podman.io/en/latest/markdown/podman-run.1.html#...

actinium226• 1 year ago

I went through the online tutorial, but I'm not really seeing how it's different from docker?

skydhash• 1 year ago

Instead of ephemeral containers, you have instances that are like VM (and incus can manage VM via qemu), so pretty much everything you would use a VM for, but if you do not need the kernel separation. It's more similar to FreeBSD jails than to docker.

Levitating5• 1 year ago

It's a difference between system containers and application containers.

LXC containers used in incus run their own init, they act more like a VM.

However incus can also execute actual VMs via libvirt and since recently even OCI containers like docker.

CoolCold5• 1 year ago

if your question is genuine, then the simple answer would be full system inside container of LXD/Incus (I prefer to use term VE for Virtual Environment to distinguish from barebone containers of Docker style).

The full system, means, all your standard stuff works in expected way - crons, systemd units, sshd, multiple users, your regular backup solutions and so on. As well, that "system" can be dumped/exported/backuped/snapshotted as a whole - very much similar like you do with your vSphere/Qemu or whatever you use in your datacenters as hypervisor.

Foreseeing the question - yep, you can run Docker inside LXD/Incus VEs. In practical terms, that makes much simple when you need to give some dev team (who are of course not anywhere known to do sane things) access to environment with Docker access (which in 99% cases means that host's root level access is exposed).

oulipo3• 1 year ago

Is there some kind of Terraform/Pulumi integration to make it easy to deploy stuff to some VM running Incus for my deployments? Or I'm missing the point of what Incus is for?

Levitating5• 1 year ago

You could use cloud-init

goku1210• 1 year ago

Incus is like a cloud management software - especially in cluster mode. It has management API like many cloud services. So, yes, there's a terraform provider for Incus, which can be used to configure and provision instances. Guest setup can be managed using cloud-init. Ansible is also an alternative option for this.

mdaniel8• 1 year ago

Or even one of each, since cloud-init has an ansible hook: https://cloudinit.readthedocs.io/en/latest/reference/modules... for something like ansible-pull behavior

oulipo3• 1 year ago

Very clear! And would it make sense to run it on a GCP VM, and use it as a "nicer docker-compose" ? Or that would entirely miss the point?

belthesar2• 1 year ago

There is a Terraform provider that is actively maintained, in addition to Ansible integration. https://linuxcontainers.org/incus/docs/main/third_party/

I'm a Pulumi user myself, and I haven't seen a Pulumi provider for Incus yet. Once I get further into my Incus experiments, if someone hasn't made an Incus provider yet, I'll probably go through the TF provider conversion process.

oulipo3• 1 year ago

That would be quite useful indeed!

joeduffy• 1 year ago

Note that you can now use TF providers "on the fly" from Pulumi: https://www.pulumi.com/blog/any-terraform-provider. No provider bridging/conversion necessary.

I just tried and it seems to have worked (though I haven't tested any specific resources yet):

$ pulumi package add terraform-provider lxc/incus

tcfhgj• 1 year ago

The only tool I found which allows to easily spin up pre-configured VMs without any gui hassle

pm2222• 1 year ago

Should lxc user migrate to incus?

Levitating5• 1 year ago

an lxd user should

jenders• 1 year ago

LXD is actually pronounced “lex-d” by the community and similarly, LXC is “lex-c”.

goku1210• 1 year ago

Short answer: No. Long answer: Depends upon what you use lxc for.

Incus is not a replacement for lxc. It's an alternative for LXD (LXD project is still active). Both Incus and LXD are built upon liblxc (the library version of lxc) and provide a higher level user interface than lxc (eg: projects, cloud-init support, etc). However, lxc gives you fine grained control over container options (this is sort of like flatpak and bubblewrap).

So, if you don't need the fine grained control of lxc, Incus may be a more ergonomic solution.

PS: Confusingly enough, LXD's CLI is also named lxc.

gavinray3• 1 year ago

Can someone explain the usecase for this?

Is this for people who want to run their own cloud provider, or that need to manage the infrastructure of org-owned VM's?

When would you use this over k8s or serverless container runtimes like Fargate/Cloudrun?

Levitating5• 1 year ago

There's no particular usecase, though I do know of a company whose entire infrastructure is maintained within incus.

I personally use it mostly for deploying a bunch of system containers and some OCI containers.

But anyone who uses LXC, LXD, docker, libvirt, qemu etc. could potentially be interested in Incus.

Incus is just an LXD fork btw, developed by Stephane Graber.

clvx• 1 year ago

Who also developed LXD and contributed to LXC. I wouldn’t say it’s just a fork but a continuation of the project without Canonical.

pxc2• 1 year ago

System container tech like Incus powers efficient Linux virtualization environments for developers, so that you can have only one VM but many "machines". OrbStack machines on macOS work like this, and the way WSL works is similar (one VM and one Linux kernel, many guests sharing that kernel via system containers).

gavinray3• 1 year ago

Thanks -- though I'm not sure I fully grok how this is different than something like Firecracker?

CoolCold5• 1 year ago

Just in case - I'm using LXD inside my WSL and it working great. BTRFS backed storage via loopfile, saves $$$.

For others, why it may be useful in regular sysadmin job:

* say doing Ansible scripting against LOCAL network is hell amount of time faster than against 300+ ms remote machines

  * note that because you can use VE snapshots, it's very easy to ensure your playbook works fine without guessing what have you modified when testing things - just do rollback to "clean" state and start over

* creating test MariaDB 3 nodes cluster - easy peasy

* multiple distros available - need to debug Haproxy from say Rocky 8 linux? Check!

goku1210• 1 year ago

Can someone explain the usecase for this?

Use cases are almost the same as Proxmox. You can orchestrate system containers or VMs. Proxmox runs lxc container images, while incus is built on top of lxc and has its own container images.

System vs Application containers: Both share virtualized kernels. Application containers usually run only a single application like web app (eg: OCI containers). System containers are more like VMs with systemd and multiple apps managed by it. Note: This differentiation is often ambiguous.

Is this for people who want to run their own cloud provider, or that need to manage the infrastructure of org-owned VM's?

Yes, you could build a private cloud with it.

When would you use this over k8s or serverless container runtimes like Fargate/Cloudrun?

You would use it when you need traditional application setups inside VMs or system containers, instead of containerized microservices.

I actually use Incus containers as host nodes for testing full fledged multinode K8s setups.

throwaway2056• 1 year ago

I know some webhosting provider that used one VM for every user. Now they moved to using this. Firstly low resource usage. If one uses ZFS or btrfs then one can save storage as in common bits are not duplicated across system containers. Note this is a system container - not traditional container. This one can be rebooted to get the previous state. It is not ephemeral.

sigmonsays• 1 year ago

the features worth mentioning imho are the different storage backends and their features. Using btrfs, lvm or zfs there is some level of support of thin copy provisioning and snapshotting. I believe btrfs/zfs have parity in terms of supported operations. Cheap snapshots and provisioning of both containers and VMs using the same tool is pretty awesome.

I personally use lxd for running my homelab VMs and containers

mdaniel8• 1 year ago

I first learned about this because colima supports it: https://github.com/abiosoft/colima#incus

mathfailure• 1 year ago

Their site doesn't open, that's a poor sign.

mdaniel8• 1 year ago

Only if they run their website on Incus

darqis• 1 year ago

tried it, was buggy, removed and never looked back.

Incus – Next-generation system container, application container, and VM manager

Related Stories