Tools for managing containers

Software application deployment has always been a headache for developers. Anybody old enough to remember coding back from the days of Windows COM might remember the “DLL Hell”, a real menace for developers and sysadmins alike. But even in later years, the breadth of technologies and the increasing rate at which they emerged in many cases created confusion and uncertainty.

In most, if not all, software development cases, the development environment differs a lot from the environment where the software actually runs when deployed. The fact that the two computers are differently configured is absolutely expected, but differences in application operation are unacceptable.

In that respect, containers were nothing short of a revolution when recent tech developments, such as Docker, boosted their popularity a few years ago. What containers do, is to make sure that when an application is deployed it is accompanied by all dependencies and configuration required for its proper function in a target environment. So a container packages as much as possible to make a “containerized” runtime environment “feel” as close as possible to the development environment but without emulating the OS layer.

This results in a very lightweight package, often only running a couple of application specific processes, which can be easily distributed, deployed and run across multiple instances. In short, containers are a promise that a software application will behave in the same way when moved to different computing environments.

In this article, we will attempt to do a brief introduction to some important container management tools that you should definitely investigate further if you find yourself ready to work with containers.

This is not meant to be a detailed review, not least a comparison or evaluation. You can think of it as a starting point in your investigation on tools for managing containers. The way we’ve cut and sliced the list should hopefully make it easier for you to pinpoint the tools you want to look into further.

Docker provides functionality for deploying and running applications in containers. Containers can be likened to virtual machines in concept, but implemented at a higher level than the OS and without quite as much isolation. Instead of packaging the whole OS and everything above it, containers package the application and its direct dependencies. Docker is an implementation of this.

The Docker format is almost like packaging an application, except it is self-contained and multiple copies can be run on a single host and across hosts. This makes the most out of resource utilization, can improve performance and reduce the application size. At the same time, Docker provides a degree of isolation to limit application issues to a single container rather than affect the entire machine.

Docker is great for running containers in one host, and provides all required functionality for that purpose. But in today’s distributed services environment, the real challenge is to manage resources and workloads across servers and complex infrastructures.

One such tool is Google’s Kubernetes, a strange-sounding Greek word that means “governor” or “commander”. As the word might suggest, Kubernetes undertakes the cumbersome task to orchestrate containers across many nodes, utilizing many useful features.

Service Discovery

The app container ecosystem has grown lately in part because of the Microservices Architecture pattern gaining ground. This paradigm revolves around heavy division of an application into small semi-autonomous services all interconnected with each other in a distributed system. As services grow in numbers in a such a system, it doesn’t make sense to manually assign and keep note of the ports that applications “listen on”. Rather, as a container is deployed, a port is assigned automatically to it. And although this solves the possibility of conflict among ports, it makes it impossible for us to locate our service and make it available to others.

The solution to this problem is service discovery. As services start up, they register in a distributed key/value pair registry with IP and port number so that other services can find and call them.

Scheduling

Another very important function that Kubernetes covers is scheduling. A scheduler undertakes the task to run the containerized apps while taking into account available resources, current tasks and requests. So among the scheduler’s jobs are scaling, reassigning tasks to different hosts and handling moving workloads in case of failures.

Boasting many useful features and a large community, Kubernetes is constantly growing in popularity.

CoreOS is an operating system based on Linux that comes bundled with features and functionality required to deploy and run containerized applications. With its relatively small footprint and workload distributing capabilities, CoreOS is suitable both for single server and clustered computing environments.

CoreOS poses as a serious competitor to other popular Linux OS, exactly because of its by-design ability to work with software application containers and its good fit for public cloud instances.

CoreOS started off by using Docker as an additional layer of abstraction and standardized format for containers, but later released its own container engine, Rocket (rkt – keep reading) and provides support for it as well.

Although open source, CoreOS is also available in a commercial version called Tectonic. Tectonic is “freemium” and its big advantage is that it comes packed with Kubernetes for container orchestration.

Etcd, developed by CoreOS, is a lightweight, distributed, open-source key/value store that provides applications with a reliable way to store data across a server cluster and allows them to respond to value changes accordingly. It is used by Kubernetes as a central spot where all cluster nodes can read/write configuration data, as well as for service discovery and leader election handling.

rkt is a container management platform for Linux clusters. Drawing from its OS design and Docker interfacing expertise, CoreOS developed a tool for discovery, verification, and running of application containers with isolation.

An alternative to Docker, rkt was released almost a year later and keeps growing in popularity. It could be argued that rkt is an improvement over Docker mainly for two reasons:

It is inherently secure, using signature verification and privilege separation by default

It ensures portability: on top of being able to run Docker images, rkt is designed to run App Container Images (ACI), the format specified by the open source App Container Specification (appc)

Apache Mesos is a distributed systems kernel built on the same principles as Linux kernel but with a different level of abstraction. Its main purpose is to abstract and consolidate computing resources across multiple physical or virtual machines and make them available to a central management service as if it were one large resource pool.

By placing an agent that can measure and report resource availability on each machine, Mesos is able to schedule and organize task execution, as well as check and make sure if jobs are complete. These tasks are seamlessly performed across multiple servers whose accumulated resources are treated as a single pool in what are called Mesos frameworks.

Consul is a distributed system that comprises of many operations, but among its most prominent roles are those of service discovery and key/value store.

As a service discovery tool, Consul allows applications to register as clients with it to provide a service, such as an API. Then, other systems can use Consul to discover the providers of a service. Combined with health checking functionality, the service discovery functionality is able to take action such as direct traffic away from unhealthy nodes.

As a key/value store, Consul is available to applications that need to save configuration data across nodes and respond to changes, much like etcd. Consul, however, provides native support for multiple datacenters, a more comprehensive health checking system based on a gossip pool, its very own service discovery pool, and a Web UI to monitor services.

Google Container Engine (GKE) is a cluster manager and orchestration system for Docker containers. Based on Kubernetes, Google’s open source container management system can be used to create, resize and debug container clusters, autoscale applications, create and manage container pods and other services.

Compared to Kubernetes, Google Container Engine serves as an extra level of managed services for developers and sysadmins, with services like Load Balancing, Metrics tracking and logging being taken care of for them by the system.

The Amazon Web Services equivalent of GKE is the EC2 Container Service (ECS). Like most such services ECS supports Docker and allows running containerized applications utilizing Amazon’s EC2 instances.

Like GKE, ECS is a highly managed service that provides many convenient features such as container deployment, scheduling, auto-scaling, load balancing, cluster-level resource monitoring, as well as seamless cooperation with the rest of the AWS cloud stack. Although ECS only works on VPC, it comes free, so you only pay for resource usage, as usual.