[dead]
My VM is lighter (and safer) than your container (2017)
21–30 of 184 posts
Re: My VM is lighter (and safer) than your container (2017)
#22Integrate that with kubernetes and I'm sold.
There are NVidia's Kata containers: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator... . I'm not sure you need the physical GPUs to run them though. Most likely not. I'm wondering though what value will Kubernetes add beside integrating with existing (presumably Kubernetes-based) infrastructure? At least, this is my understanding of the rationale for Kata containers. Other than that, it seems like it'd b…
I believe this work originated at Intel as "clear containers" (which I believe started life from an acquisition (but could be mixing this up...my memory isn't what it used to be). Either way it's great they are being used like this and at Nvidia (I know Alibaba cloud also use this tech)
Re: My VM is lighter (and safer) than your container (2017)
#23I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
But if you can get isolation, security AND reproducible environments using a VM, specially one that's nearly as fast as a OS process, the case for using containers instead pretty much disappears. I don't know this LiteVM thing but I will definitely investigate that, specially given that on my Mac I need to use a VM anyway to run containers!
I wouldn't discount the massive user base of containers among developers.
Re: My VM is lighter (and safer) than your container (2017)
#24I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?
Yes, indeed, and that is golang's main reason for existing.
Re: My VM is lighter (and safer) than your container (2017)
#25I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?
Because static libraries ain't a big thing anymore. Maybe they will become popular again. This would make it easier to have reproduceable build without a container. But I think containers are the new static libs now
Re: My VM is lighter (and safer) than your container (2017)
#26I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?
Programmers discover the benefits of static linking, and then programmers discover the benefits of dynamic linking, and then programmers discover the benefits of static linking, and then...
Anyway containers go quite a bit further than just static linking, most people aren't out there linking all the binaries that their shell script uses together?
Re: My VM is lighter (and safer) than your container (2017)
#27I think containers are often misunderstood: The main benefit is not isolation and security, it's defined and reproducible environments and builds. If there is some additional isolation required, just run the container in a VM.
But if you can get isolation, security AND reproducible environments using a VM, specially one that's nearly as fast as a OS process, the case for using containers instead pretty much disappears. I don't know this LiteVM thing but I will definitely investigate that, specially given that on my Mac I need to use a VM anyway to run containers!
i think at that point it's kind of just semantics
i don't think devs care if they use containers or VMs, as long as it's easy and they don't have to worry about which version of Python the host is running
Re: My VM is lighter (and safer) than your container (2017)
#28Earlier quoted context omitted.
I think it's from the AWS team, they made firecracker (micro VM) So it does exist. Funnily that's what fly does: take your container uncompress it to a full micro VM and run it on their infra
fly.io uses Firecracker. Firecracker is Open Sourced with an Apache 2 license. It's faster than LightVM mentioned in the post. Firecracker also has containerd support ( https://github.com/firecracker-microvm/firecracker-container... ). There are a few ways to run Kubernetes with Firecracker, including FireKube.
Is it really faster? I thought firecracker boot times were something like 100ms. LightVM claims 2.3ms?
Re: My VM is lighter (and safer) than your container (2017)
#29No mention of user namespaces whatsoever, which is the primary security isolation mechanism for containers on linux. This is what enables "rootless" mode. Of course, this is from 2017, but user namespaces were released with linux 3.8 in February 2013.
Docker particularly has always required extra work to run in rootless mode because it was released soon after in March 2013, and for whatever reason it hasn't been a priority to rework the codebase to make that the default. I switched to podman for exactly this reason as my go-to oci implementation and haven't looked back.
The linux kernel features that enable various forms of isolation all require root privileges (CAP_SYS_ADMIN). Once user namespaces were a thing, that allowed you to use user namespaces to get around the root requirements for all the other isolation namespaces.
All of the below still require CAP_SYS_ADMIN:
CLONE_NEWCGROUP: cgroup namespace, for resource control (mem/cpu/block io/devices/network bandwith)
CLONE_NEWIPC: ipc namespace for sysv ipc objects and message queues
CLONE_NEWNET: network namespace, for isolated virtual networking
CLONE_NEWNS: mount namespace, for isolated mounting (filesystems, etc.)
CLONE_NEWPID: pid namespace, for isolated view of running processes
CLONE_NEWUTS: unix timesharing system namespace, for isolation of hostname and domain name
Re: My VM is lighter (and safer) than your container (2017)
#30"VM" means it has its own kernel? Why have 2 kernels on the same machine? All processes in a proper OS are already isolated and there is no need for VM.
Isolated, but are they isolated enough? The article states that containers offer weaker isolation than VMs. (it doesn't quantify it though and I don't know this kind of thing offhand)
Processes run in a userspace and cannot do anything without OS approval.