I never understood how to use Docker, what makes it so special? I would really like to use it on my Rapsberry Pi 3 Model B+ to ease the setup process of selfhosting different things.
I’m currently running these things without Docker:
- Mumble server with a Discord bridge and a music bot
- Maubot, a plugin-based Matrix bot
- FTP server
- Two Discord Music bots
All of these things are running as systemd services in the background. Should I change this? A lot of the things I’m hosting offer Docker images.
It would also be great if someone could give me a quick-start guide for Docker. Thanks in advance!
IMHO with docker and containerization in general you are trading drive space for consistency and relative simplicity.
a hypothetical:
You set up your mumble server and it requires the leftpad 3.7 package to run. you install it and everything is fine.
Now you install your ftp server but it needs leftpad 5.5. what do you do? hope the function that mumble uses in 3.7 still exists in 5.5? run each app in its own venv?
Docker and containerization resolve this by running each app in its own mini virtual machine. A container running mumble and leftpad 3.7 can coexist on host that also has a container running a ftp server with leftpad 5.5.
Here is a good video on what hole docker and containerization looks to fill
https://www.youtube.com/watch?v=Nm1tfmZDqo8
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
I would also add security, or at least accessible security. Containers provide a number of isolation features out-of-the-box or extremely easy to configure which other systems require way more effort to achieve, or can’t achieve.
Ironically, after some conversation on the topic here on Lemmy I compiled a blog post about it.
Tbf, systemd also makes it relatively easy to sandbox processes. But it’s opt-in, while for containers it’s opt-out.
Yeah, and it also requires quite many options, some with harder-to-predict outcomes. For example RootDirectory can be used to effectively chroot the process, but that carries implications such as the application not having access to CA certificates anymore, which in general in containers is a solved problem.
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=Nm1tfmZDqo8
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
While what you’ve written is technically wrong, I get why you did the comparison that way. Now there are tons of other containerization solutions that can exactly what you’re describing without the dark side of Docker.
Doesn’t that mean that docker containers use up much more resources since you’re installing numerous instances & versions of each program like mumble and leftpad?
Kinda, but it depends on the size of the dependencies, with drive space bing so cheap these days do you really worry about 50Mb of storage being wasted on 4 different versions of glib or leftpad