On the basic building blocks of containers (cgroups, namespaces and and CoW filesystems) check out containerz.info.

Runtimes

In order to run a container—which is essentially a process group on steroids—you need something that takes the container image and launches the process group in a well-defined (an contained) environment. Here are some popular options:

  • AppC/rkt, emerging standard driven by CoreOS
    • dgr a command line tool to build and configure App Containers Images (ACI) and pods based on convention over configuration.
  • Docker, The Hype (c) by the company with the same name
  • LXC, oldie but goldie, driven by Canonical
  • OCI runC, the new raising star, the gold standard (maybe in 2017?)
    • cri-o OCI-based implementation of Kubernetes Container Runtime Interface
    • containerd, Dockers OCI-compliant runtime
  • systemd-nspawn, more of historical interest but if you're a heavy systemd user, well, why not?

Provisioning and orchestration

Running multiple containers on multiple machines is a bit of an effort and when you go all in concerning microservices, this is what you'll likely end up with, either out of scalability or out of fault tolerance reasons, or both. There are a couple of tools that do the base provisioning (setting up a single machine with everything you need, such as Terraform) and then there are a number of so called container orchestrators, taking care of the entire life cycle of a container, from launching to health checks to scaling:

In this context you might also want to know what host operating system can be used with which container orchestration system as well as learn about The Container Landscape in end of 2016.

Some tools that assist you in converting stuff/migrating workloads:

  • container-transform converts Kubernetes pods, ECS task definitions, Docker compose configuration files, Marathon app specs, and Chronos task definitions to systemd unit files.
  • kompose helps users familiar with docker-compose to move to Kubernetes; it takes a Docker compose file and translates it into Kubernetes resources.

Registries

Your container images need to be served from somewhere. That somewhere is called a container registry and here are some options:

Of course, you can also run your own Docker registry.

Managed offerings

If you don't want to or can not set up stuff yourself using tools from the previous section then a managed offering might be the right thing for you:

Testing, debugging & introspection

Figuring out what's wrong with a container or service can be quite cumbersome but luckily there are tons of tools that can help you with it: