153
What's the deal with Docker?
(lemmy.zip)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Mar 2024
153 points (94.2% liked)
Selfhosted
40219 readers
459 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Docker containers aren't running in a virtual machine. They're running what amounts to a fancy chroot jail... It's just an isolated environment that takes advantage of several kernel security features to make software running inside the environment think everything is normal despite being locked down.
This is a very important distinction because it means that docker containers are very light weight compared to a VM. They use but a fraction of the resources a VM would and can be brought up and down in milliseconds since there's no hardware to emulate.
FYI docker engine can use different runtimes and there is are lightweight vm runtimes like kata or firecracker. I hope one day docker will default with that technology as it would be better for the overall security of containers.
~~To put it in simpler terms, I'd say that containers virtualise only the operating system rather than the whole underlying machine.~~
I guess not then.
It virtualises only parts of operating system (namely processes and network namespaces with ability to passthru devices and mount points). It is still using host kernel, for example.
I wouldn't say that namespaces are virtualization either. Container don't virtualize anything, namespaces are all inherited from the root namespaces and therefore completely visible from the host (with the right privileges). It's just a completely different technology.
The word you’re all looking for is sandboxing. That’s what containers are - sandboxes. And while they a different approach to VMs they do rely on some similar principals.
I never said that it is a virtualization. Yet for easy understanding I named created namespaces "virtualized". Here I mean "virtualized" = "isolated". Systemd able to do that with every process btw.
Also, some "smart individuals" called comtainerization as type 3 hypervisors, that makes me laugh so hard :)
The operating system is explicitly not virtualised with containers.
What you've described is closer to paravirtualisation where it's still a separate operating system in the guest but the hardware doesn't pretend to be physical anymore and is explicitly a software interface.
Not exactly IMO, as containers themselves can simultaneously access devices and filesystems from the host system natively (such as VAAPI devices used for hardware encoding & decoding) or even the docker socket to control the host system's Docker daemon.
They also can launch directly into a program you specify, bypassing any kind of init system requirement.
OC's suggestion of a chroot jail is the closest explanation I can think of too, if things were to be simplified