Live data from Hacker News

About Containers and VMs

linuxcontainers.org

51–60 of 63 posts

Re: About Containers and VMs

#51
post #19

Earlier quoted context omitted.

I think they linuxcontainers.org people would disagree. Like the table is trying to communicate, in contrast to eg Docker, this is not about application containerization.

The table is comparing all three types: VM, system containers, application containers. Incus supports application containers. Its a relatively recent addition. I can't find great docs for it, but its in the release notes last year: https://linuxcontainers.org/incus/news/2024_07_12_05_07.html

For those unfamiliar, Incus is 'replacement' for LXD. https://linuxcontainers.org/incus

Re: About Containers and VMs

#52

What is this? Docker containers can host more than one process/service/app. And why is some product called “Incus” using “linuxcontainers.org” as a domain name?

Are (self hosting) people putting multiple services like Django app, Postgres, Redis etc into a single container/lightweight VM instead of using Docker Compose with single-purpose containers?

You don’t have too, as you can create a single posgres instance for your services.

I prefer Incus, because you can’t do adhoc patching with docker. Instead you have to rebuild the images and that becomes a hassle quicky in a homelab settings. Incus have a VM feel while having docker management UX.

Re: About Containers and VMs

#53

What is this? Docker containers can host more than one process/service/app. And why is some product called “Incus” using “linuxcontainers.org” as a domain name?

Linux Containers, or LXC, came before Docker and OCI standardization. As the others have mentioned, Incus is the community fork led by former members of the LXD team.

Very early versions of Docker even used LXC before they replaced it with libcontainer.

Re: About Containers and VMs

#54
post #36

IMO it's not good that the kernel interferences keep on spawning endless userland "middleware" projects. I still want capsicum to give me sane defaults, so the incentive for sandbox security theater goes away.

Seems mostly off topic to the article. I think system containers should be implemented in user space. They are not about security theatre but about getting a sandboxed environment which feels like a real/virtual machine but is lighter weight. Very useful e.g. when I want to emulate a whole cluster of Linux machines. And for those needs security is nice but not key. It is application containers which maybe should be r…

So from the capsicum perspective, when you spawn a process, it should be maximally isolated by default. Any sharing of resources should be opt-in, not opt-out.

This is not a big change implementation-wise, but it completely changes the programming model. Instead of dreaming up endless new sandboxing strategies, we just give processes exactly what they need, no more, no less.

Re: About Containers and VMs

#55

Can someone explain how a system container is more secure than an application container, if that is indeed the case?

It mostly isn't. Almost all Linux container escapes only require the ability to make system calls to the shared kernel from processes inside the container. The system container doesn't really restrict this ability. It also increases surface area to compromise the container before attacking the host system, since there's now a bunch of extra software running inside the container. If privilege isolation is a priority b…

"Systems containers" are almost certainly isn't more secure since 'root' means things, even in a container.

Containers just leverage existing Linux namespace isolation techniques to isolate applications.

A good way to think about it is that they act like blinders on a horse. If applications can't "see stuff" or reference items outside of the container then they don't know it exists and don't know how to interact with it.

"application containers" can take advantage of more then just namespaces to isolate applications, such as running them as unprivileged users inside the container's context and thus limiting them from the sort of kernel features that get exposed inside the containers. Or cgroups to limit resource usage and other smaller things like that.

Regardless "Security" and "Containers" really shouldn't be written about in the same paragraph without MAC framework like SELinux in place or additional isolation techniques like VMs.

Although VMs are a lot more like containers then people realize.

Re: About Containers and VMs

#56
post #19
post #9

As I always say: a VM makes an OS believe that it has the machine to itself; a container makes a process believe that it has the OS to itself.

I think they linuxcontainers.org people would disagree. Like the table is trying to communicate, in contrast to eg Docker, this is not about application containerization.

I think that using the term 'application containers' to reference docker and 'system containers' to reference LXC is a bit of a meaningless distinction.

You can 100% host "systems containers" on Docker and you can host "applications" on LXC.

Like if I want a entire OS with it's own init system and users and so on and so forth I can do it it OCI images.

In fact I use it every single day with distrobox on top of Podman using OCI container images.

And it works a hell of a lot better then if I tried to do it on LXC.

Re: About Containers and VMs

#57

It's a bad sign that the first table on the page is full of errors. "Can only host Linux" -- Windows Containers are a thing too: https://learn.microsoft.com/en-us/virtualization/windowscont... "Can host a single app" -- not true either. It's just bad practice to host multiple apps in a single container, but it's definitely possible . IMHO it's not very nice to use the generic-sounding "linuxcontainers.org" domain exc…

linux containers, be it a lxd container, or a containerd/dockerd one, only run on linux hosts. windows containers, only run on windows hosts. when you run a linux container on a windows host, you're actually running a linux container inside of a linux vm on top of a windows host. containers share the host operating system's kernel. it is impossible for a linux container (which is just a linux process) to execute and…

Except if you have a kernel that has multiple personalities, so it can implement different OS interfaces like the NT kernel implementing both Win32 and Linux.

Re: About Containers and VMs

#58
post #19

Earlier quoted context omitted.

I think they linuxcontainers.org people would disagree. Like the table is trying to communicate, in contrast to eg Docker, this is not about application containerization.

I think that using the term 'application containers' to reference docker and 'system containers' to reference LXC is a bit of a meaningless distinction. You can 100% host "systems containers" on Docker and you can host "applications" on LXC. Like if I want a entire OS with it's own init system and users and so on and so forth I can do it it OCI images. In fact I use it every single day with distrobox on top of Podman…

yeah, the system/application distinction feels somewhat superficial. The “multiple user space” inside a container thing sounds interesting (not sure what that means exactly), but maybe more similar to a Kubernetes pod, except maybe instead of different rootfs there’s another isolation mechanism?

Re: About Containers and VMs

#59
post #48
post #42

Earlier quoted context omitted.

For that analogy to hold, Pepsi would have also invented sodas.

Like that matters to consumers? Regardless of who invented sodas, the market has changed and people connect more brands to the kind of drink now, so equating Pepsi to Soda is factually incorrect.

Oh God, you're really torturing the analogy now.

Re: About Containers and VMs

#60

Earlier quoted context omitted.

The table is comparing all three types: VM, system containers, application containers. Incus supports application containers. Its a relatively recent addition. I can't find great docs for it, but its in the release notes last year: https://linuxcontainers.org/incus/news/2024_07_12_05_07.html

For those unfamiliar, Incus is 'replacement' for LXD. https://linuxcontainers.org/incus

Not a replacement but a fork of lxd.
Post reply on HN