Containers

A container is a way to run an application in an isolated environment while sharing the host machine’s operating-system kernel. The container gets its own view of selected resources, such as its processes, filesystem, and network settings. The host still supplies the kernel underneath. That usually means less duplicated operating-system work and faster startup.

The difference matters for packaging and deployment. The university could use a single physical server, with a single operating system, to run both HopPress and CourseTracker in separate containers. The applications would be isolated from each other. The university could start and stop the applications quickly, and it could package them for deployment without worrying about the details of the host operating system.

Containers do not eliminate the need for a well-maintained host system. The university’s IT still needs to choose, patch, monitor, and secure the machine that runs the containers.

Containers became important because they offered a trade-off. They give a more focused boundary than a virtual machine, with less duplicated operating-system overhead. But that comes at the cost of less independence from the other applications running on the same host. If the host stops, all the containers running on it stop as well. If a bug in HopPress affects the host, it could affect CourseTracker as well.

Separately, configuring and running containers used to be harder than doing the same for virtual machines or bare-metal servers. The container ecosystem has improved over time. Docker is an important part of that improvement, which we will turn to next.