Linux Containers (LXC and LXD) and Docker containers are becoming a common application packaging and runtime format. Docker is significantly more popular so it makes sense to invest your practice time in becoming familiar and comfortable with common Docker tasks, tools, and workflows.
It’s easy to get lost in the technical details of containerization and the current iteration of tooling for them. But during your interview, don’t forget to mention that much of the benefit of containerization come from the workflows it enables.
One of the most important aspects of containers is that they are essentially a packaging format, much like a modern take on a .deb or .rpm file. Using a Dockerfile, applications or microservices can be deterministically built and tested without shipping large amounts of binary code or VM snapshots around.
And because containers give you a new standard format for dealing with applications and services, modern orchestration/scheduling software like kubernetes and nomad makes it easy (or at least possible) to use modern workflows for rolling out changes and running an application in production.
Common Docker Interview Questions
How are containers different from virtual machines (VMs)?
Containers share a kernel with their host environment (it’s the same underlying OS; containers are just segregated little environments — like a modern chroot jail).
Virtual Machines run on a physical machine, which runs a hypervisor OS, which in turn hosts one or more virtual machine operating systems. Your applications then run on those VMs.
What are some advantages and disadvantages of containers?
- Containers are lightweight. They are essentially just fancy processes and share resources with other processes, managed by the same kernel.
- They’re relatively minimal — technically you’re just talking about a cgroup, some user/group remapping, some iptables rules, and a subtree of the existing Linux filesystem tree that the process isn’t allowed to leave.
What are some advantages and disadvantages of virtual machines?
- Modern hypervisor software has some amazing features — live migration, snapshotting, and many others.
- A full guest OS running on the host — some classes of security issues are avoided in this way.
- Can be managed like a pizza-box-in-a-datacenter host, so traditional (old-school) automation, configuration management codebases, and workflows can still be used.
- Resources are much less flexibly divided among a fleet of virtual machines — some overprovisioning is possible (sparse VM disks, some memory overprovisioning) but you are still committing a chunk of resources that stays reserved for VM use. In a large fleet, this can lead to more unused resources.
- Some classes of security problems are an issue — attacks against virtual floppy disk controllers, for example (which is both hilarious and horrifying at the same time).
- There are two layers of operating systems now running on the underlying hardware — one hypervisor OS, and the full guest OS that you install on your VM. This is less of an issue with virtualization extensions supported on modern hardware, but certain things are still much slower when virtualized (implemented in software rather than hardware).
What is a docker container “made of” in the actual implementation? What are the general outlines of how it works?
- User namespacing
- Process namespacing
- iptables rules
- selinux/apparmor rules?