Are Docker Containers a Good Idea for Laptops?
DOCKER CONTAINERS are great for a ton of reasons. They allow for temporary or permanent environments for applications to run in pseudoisolation from the host system. But don’t get it twisted: Running an app in a Docker container isn’t necessarily safer than running it on the host OS. Docker containers are cool. If you haven’t yet played with Docker, you’re missing a large world of easily deployed applications. For example, I can deploy NodeRed, Plex, Jupyter Lab, and Nextcloud servers, and run them behind a Traefik reverse proxy with a single command and a YAML text file. If you’re running an HTPC, NAS, or home Linux server, Docker lets you do just about anything.
Containers (like Docker containers) emulate a filesystem, networking, and other OS components in order to allow applications to isolate themselves from the host OS. Containers generally don’t require dedicated resources, so they’re often preferred to virtual machines for single applications.
Installing web apps such as Plex or Nextcloud directly on to your OS can be a pain, depending on the application stack. Windows-esque “DLL Hell” has its evil brother on Linux in the form of broken dependencies. If one program requires a different version of a library from another program, updating or installing those two programs together can be tricky, if not impossible. Containers fix this by packing up all the dependencies for a container’s image (like a package) and running them in an isolated environment. If a web app requires a particular version of Python, using a Docker container prevents it from conflicting with the OS’s version. Flatpak and Snap packages are containers in many ways, but the formats are largely geared toward desktop use. The Docker image paradigm is king when it comes to web and applications.
There is one glaring problem. The Docker daemon must run as root. So, anyone who can talk to Docker has root privileges. As a result, any container running on the system can potentially obtain root privileges on the host. The other problem is that Docker’s networking stack can play hell with the Uncomplicated Firewall (ufw), a common default firewall for many Linux distros. Because the Docker daemon has root access, IPTables can happily overwrite ufw’s rules without letting you know.
There is a better way if you’re not looking to deploy a web service on a network. Podman aims to be close to a drop-in replacement for common Docker tasks. It can grab Docker images from online repos and deploy them with the same commands you’d use with Docker (but using “podman” instead of “docker”). Its sister app Buildah builds container images from Docker files, too.
Podman doesn’t run as a daemon, so doesn’t require root. This also means that containers started by non-root users can’t get root privileges either. However, without the Docker daemon, there’s no process to watch after Podman containers. This requires the user to run some other service (such as Systemd) to start and stop container instances. Podman refers to “pods” in the Kubernetes (“k8s”) sense. A Kubernetes pod is made of one or more containers that are created and destroyed as one. (A “node” is a single virtual machine that hosts pods.) Podman is an alternative interface for launching pods on a Kubernetes cluster. The Kubernetes supervisor orchestrates node and pod deployment, so the Docker daemon isn’t necessarily needed.
Feeling adventurous? Try the k3s project, which removes some overhead from Kubernetes. K3s is designed to run on embedded systems, but is a great way to learn Kubernetes on a local system, with no hefty setup or VM overhead.