On the basic building blocks of containers (cgroups, namespaces and and CoW filesystems) check out containerz.info.
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?)
- 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:
- Kubernetes (orchestration)
- Marathon (orchestration)
- Nomad (orchestration)
- Swarm Kit (orchestration)
- Terraform (provisioning)
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-composeto move to Kubernetes; it takes a Docker compose file and translates it into Kubernetes resources.
Your container images need to be served from somewhere. That somewhere is called a container registry and here are some options:
- AWS EC2 Container Registry
- CoreOS Quay.io
- Docker Hub
- Google Cloud Container Registry
- JFrog Artifactory
- SUSE Portus
Of course, you can also run your own Docker registry.
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:
- Amazon EC2 Container Service (ECS) is a proprietary Container-as-a-Service offering
- Azure Container Service (ACS) comes in three flavours: DC/OS, Docker Swarm, or Kubernetes
- Google Container Engine (GKE) is a hosted Kubernetes offering
- Last.Backend, a Kubernetes-based CaaS/PaaS offering
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:
- AWS X-Ray
docker execor How to debug a Docker container
- artillery.io, a modern load-testing toolkit
- asobti/kube-monkey, an implementation of Netflix's Chaos Monkey for Kubernetes clusters
- dcos-labs/drax, DC/OS Resilience Automated Xenodiagnosis tool
- mhausenblas/cinf, a command line tool to view namespaces and cgroups
- Weave Scope