Containers change application development and deployment
Containers allow application developers to package up their application, along with all of their dependencies, into a portable unit called an image. These images are then stored in a remote repository where they can be pulled and run on any compliant container engine. Furthermore, the applications running on each container engine are isolated from each other and the host operating system:
- Illustrative scenario: Let's say I want to test out NGINX without installing anything (I already have Docker installed of course). I create a sample HTML page called index.html in my local directory and run the following:
docker run -p 8000:80 -v ${PWD}:/usr/share/nginx/html:ro -d nginx
- What is happening here?
- I'm telling Docker to run the official nginx image in the background on my local Docker Engine, forwarding my host adapter's port 8000 to the container's port 80 and mounting my local directory to share my HTML file with nginx as a read-only folder.
- Then, I point my local browser at http://localhost:8000 and I see my HTML page rendered. When I'm done, I ask Docker to remove the container. So, in the span of about a minute, I created a test web page, used NGINX to render it locally without installing anything locally, and ran it in complete isolation. The only possible collision with a host resource was around the host adapter's port 8000, which was arbitrary.
- This is cool, but don't VMs already do that for us?
- Conceptually there are some similarities, but container implementation is much more lightweight and efficient. The key implementation differences are:
- All containers share the host's kernel:
- Docker uses Linux container security futures to isolate containers from the host and other containers.
- Since the kernel is already running, startup time for containers is usually a second or two, versus waiting a minute or two for the guest OS to boot on a VM.
- Containers use a layered filesystem with caching:
- Docker images are composed of read-only layers that can be cached and shared across multiple containers.
- Major portions of Docker images can be shared across containers, meaning you don't have to pull the entire image every time. VMs on the other hand have a monolithic, opaque filesystem that's completely reloaded every time it's started. This leads to slow load times and inefficient image storage with VMs.
- All containers share the host's kernel:
- Conceptually there are some similarities, but container implementation is much more lightweight and efficient. The key implementation differences are:
In the following figure, you can see how the applications in the VMs (right side of the diagram) have a full copy of the OS and the supporting binaries in each virtual machine, whereas the containerized applications (left side of the diagram) all share the same Alpine binaries (no kernel necessary ~ 3 MB) and runtime binaries. There have been various reports on the financial impact of containers versus VMs, but the number I have seen ranges from a 15% to a 70% reduction in operational costs. As they say, your mileage may vary based on your OS, binaries, and whether or not you move to bare metal to eliminate hypervisor licensing costs:
