Containers 101

What is a container?

In its simplest form, a container is a unit of software designed to perform a task. That task might be simple (serve a static web page) or complex (machine learning) or somewhere in between. Containers run independently, but can communicate with other containers and non-container resources if required.

When we talk about containers, we're generally talking about the containerized format popularized by Docker, which has since become the industry standard used by a multitude of environments.

Think of an assembly line manufacturing cars. In this scenario, the container is an assembly robot responsible for one part of the car-assembly process, but it works with other robots (containers) to build the car.

A car being built by robots on an assembly line

Each robot in the assembly line has a set of instructions for the task it needs to perform. Robots might be physically identical but they perform different jobs based on the instructions they're given. When it comes to containers, those instructions take the form of a container image. It is the image that tells the container to be a web server, a database or something else.

Is a container like a virtual machine?

In some respects, containers and VMs have a lot in common. But they have one key difference: virtual machines virtualize the hardware of the underlying system, while containers virtualize the operating system.

Containers are designed to be idempotent. You should be able to destroy a container and create a replacement without any data loss. This is achieved by providing the basics of the configuration via the image, and any customizations through deployment options such as environment variables. If a container needs to store something persistently, for example a database, a volume should be attached to the container to provide this persistency without sacrificing the idempotency of the container itself.

Idempotency makes containers more flexible and portable than virtual machines. If we go back to the assembly line metaphor, imagine moving your robot to a new assembly line that builds a different model of car. The physical robot (container) can still do the job, but it will need a new set of instructions (container image). A virtual machine would need to destroy and rebuild the entire factory to change the model of car you're building.

For more on the differences between containers and virtual machines, take a look at this blog post.

Container technologies

The concept of containers in software has been around for a while. But containers as we know them really took off with the establishment of the Open Container Initiative (OCI). Based on Docker's container specification, this created an industry standard that has been adopted as 'the way to do containers' ever since. A number of platforms have sprung up as a result, including (but not limited to):

  • Docker
  • Docker Swarm
  • Kubernetes
  • Azure ACI

While these platforms adhere to the OCI in terms of their image and runtime specifications, each platform differs dramatically. This is why we created Portainer: to provide a user-friendly way to manage multiple container platforms without having to deep-dive into how each one works, while still providing the power and flexibility that those platforms offer.

Let's start
Copied Content