Definitely, one of the hottest topics in the world of cloud computing is cloud containers. This evolving technology is changing the way IT operations are conducted just as virtualization technology did a couple of years ago. However, the use of containers is not an entirely new concept. Like VM technology, containerization also originated on big […]
Definitely, one of the hottest topics in the world of cloud computing is cloud containers. This evolving technology is changing the way IT operations are conducted just as virtualization technology did a couple of years ago. However, the use of containers is not an entirely new concept. Like VM technology, containerization also originated on big iron systems. The ability to create running instances that abstracts an application from an underlying platform by providing it with an isolated environment has been around since the distributed object and container movement of the 90s with J2EE and Java. The first commercial implementation of containers was pioneered as a feature within the Sun (currently Oracle) Solaris 10 UNIX operating systems.
But the question still remains, what are containers and what role do they play in the cloud? Simply put, a container is an isolated, portable runtime environment where you can run an application along with all its dependencies, libraries and other binaries; it contains all the configuration files needed to run the application. By containerizing the application platform and its dependencies, differences in underlying infrastructure and OS distributions are abstracted away. This makes the application portable from platform to platform with ease.
Despite their subtle similarities, containers are different from VMs in multiple ways. The both offer a discrete, isolated and separate space for applications that creates the illusion of an individual system. However, unlike a VM, a container does not include a full image or instance of an operating system, with drivers, kernels and shared libraries. Instead, containers on the same host can share the same OS kernel, and keep runtimes and other services separated from each other using kernel features referred to as cgroups and namespaces. Containers use up less resources and are more lightweight compared to virtual machines. One server is capable of hosting more containers compared to virtual machines. While a virtual machine will take several minutes to boot up their operating systems and start running the hosted applications, containerized apps can be started almost instantly.
Containers mainly add value to the enterprise by bundling and running applications in a more portable way. They can be used to break down applications into isolate micro services, which facilitate enhanced security configurations, simplified management and more granular scaling. In essence, containers are positioned to solve a wealth of problems previously addressed with configuration management (CM) tools. However, they are not a direct replacement to CM or virtualization. Virtualization has played a crucial role in enabling workload consolidation in the cloud, subsequently ensuring that money spent on hardware is not wasted. Containerization simply takes it a step further.
The portable nature of containers means they can effectively run on any infrastructure or platform that runs the relevant OS. For developers, containers means saying goodbye to the burdensome processes, limited lifecycle automation, the same old problems with patches and absolutely no tooling integration. A developer can simply run a container on a workstation, create an application within the container, save it in a container image, and then deploy the application on any physical or virtual server running a similar operating system. The basic idea is to build it once and run it anywhere.
Containerization provides mechanisms to hold portions of an application inside, and then distribute them across public or private clouds, from the same vendor or from different vendors. Containers offer deterministic software packaging, this means that the network topology might be different, or the security policies and storage might be different but the application will still run on it.
Docker is responsible for popularizing the idea of the container image. The momentum behind it has made Docker synonymous with container technology, as it continues to drive more interest into the cloud. Cloud vendors have also showed interest in using Docker to provide infrastructures that support the container standard. Docker offers a way for developers to package an application and its dependencies in a container image based on Linux system images. All instances basally run on the host systems Kernel, but remain isolated within individual runtime environments, away from the host environment. Once a Docker container is created, it only remains active if active processes are running within the container.
The Docker Engine runs on all the major Linux distributions, including Arch, SuSE, Gentoo, Fedora, Ubuntu, Debian and Red Hat, and soon Windows – Microsoft announced that it will bring Docker container technology to Windows, and introduce Windows Server Containers which will run on Windows Server. Docker has been tested and hardened for enterprise production deployments, its containers are simple to deploy in a cloud. It has been built in a way that it can be incorporated into most DevOps apps, including Ansible, Vagrant, Chef, and Puppet, or it can be utilized on its own to manage development environments.
Docker also offers added tools for container deployments, such as Docker Swarm, Docker Compose, and Docker Machine. At the highest level, Compose facilitates the quick and easy deployment of complex distributed applications, Swarm provides native clustering for Docker, and Machine makes it easy to spin up Docker hosts. Docker has undoubtedly established a container standard with a solid design that works well out of the gate. However, Docker isn’t necessarily the right pick for all applications, it’s important to consider the right ones for its containers/platform.
Choosing a technology solely based on adoption rate can lead to long-term issues. Exploring all the available options is the best way to guarantee maximum performance and reliability during the lifecycle of your projects.
I. CoreOS Rocket
CoreOS includes an alternative choice to the Docker runtime called Rocket. Rocket has been built for server environments with the most resolved security, speed, composability and production requirements. While Docker has expanded the scope of the features it offers, CoreOS aims to provide a minimalist implementation of a container manager and builder. The Software is composed of two elements: Actool – administers the building of containers and handles container discovery and validation, and Rkt – takes care of the running and fetching of container images.
A major difference between Docker and Rocket is that the latter does not necessitate an exterior daemon, whenever the Rkt component is called forth to run a container, it does so without any delay within the range of its own process tree and cgroup. On the other hand, Docker runtime utilizes a daemon the needs root privileges, this opens up APIs to exploitations for malicious activities, such as running unauthorized containers. From an enterprise perspective, Rocket may seem like the better alternative due to its increased portability and customization options. Docker is more ideal for smaller teams because it offers more functionality out of the gate.
II. Kubernetes
Kubernetes was created by Google as a helper tool for managing containerized applications across private, public and hybrid cloud environments. It handles deployment, scheduling, maintenance, scaling and operation of nodes within a compute cluster. The load balancing, orchestration, and service discovery tools contained within Kubernetes can be used with Rocket and Docker containers. Simply put, while the container provides the lifecycle management, Kubernetes takes it to the next level by providing orchestration and managing the clusters of containers.
Kubernetes has the ability to launch containers in existing Virtual Machines or even provision new VMs. It does everything from booting containers to managing and monitoring them. System administrators can use Kubernetes to create pods –logical collections of containers that belong to an application. The Pods can then be provisioned within bare metal servers or VMs. Kubernetes can be used as an alternative to Docker Swarm, which provides native clustering capabilities.
Author: Gabriel Lando
