What is a Container?
Container-based virtualization is an alternative to hardware virtualization as in traditional virtual machines. Unlike containers, virtual machines have their own instances. They don’t share an operating system and do not run as resource-isolated processes. But, operating systems can be slow to boot and can be resource heavy. Cloud containers respond to these problems by using modern operating systems built-in capabilities to isolate environments from one another. In Linux and Windows, the memory address spaces of running processes have long been isolated from one another. And by processes, we simply mean running programs.
Popular implementations of software containers build on this isolation and they take advantage of additional operating system features. They give processors the capability to have their own namespaces. They also give a supervisor process the ability to limit other processes access to resources.
Containers start much faster than virtual machines and use fewer resources. This is because each container does not have its own instance and share an operating system. Instead, developers configure each container with a minimal set of software libraries to do the job. A lightweight container runtime does the plumbing jobs needed to allow that container to launch and run, calling into the kernel as necessary. The container runtime also determines the image format.
Kubernetes engine uses the docker container runtime. And docker containers are what we’ll focus on in this course. So, what does the container provide that a virtual machine does not? Containers package your application into minimally-sized components. So it’s easier to deploy them in a consistent way. Containers abstract away unimportant details of their environment. This loose coupling means that containers are easy to move around both among lifecycle phases and even between on premises in the Cloud.
The Cloud Container Package
Since deploying your application becomes cheaper and less error-prone, it’s easier to deploy soon, often, and continuously. These are the hallmarks of Agile Software Development.
The cloud container difference
The key differentiator with containers is the minimalist nature of their deployment. Unlike virtual machines, they don’t need a full OS to be installed within the container, and they don’t need a virtual copy of the host server’s hardware. Containers are able to operate with the minimum amount of resources to perform the task they were designed for. This can be just a few pieces of software, libraries and the basics of an OS. As a result, one can deploy two or three times as many containers on a server than virtual machines.
Cloud containers are also very portable. Once you create the container in your cloud, you can deploy it to different servers very easily. From a software lifecycle perspective, this is great, as containers can be copied to create development, test, integration and live environments very quickly, and do not require the usual configuration. From a software and security testing perspective, this has a large advantage. It ensures that the underlying OS is not causing a difference in the test results.
But, before you end up picking either one of them for virtualization, you should first evaluate them on the containers vs VMs grounds.
What are the disadvantages of a Container?
One downside of containers is the problem of splitting your virtualization into lots of smaller chunks. It is an advantage when there are a few containers involved because you know exactly what configuration you’re deploying and where. However, if you fully invest in containers it’s quite possible to soon have so many containers that it becomes difficult to manage. Do you have the ability to deploy patches to hundreds of different containers? If a specific library needs updating inside a container because of a security concern, do you have an easy way to do this? Problems of container management are a common complaint, even with container management systems such as Docker. Virtual machines are generally considered, easy to manage primarily because there are significantly fewer VMs compared to containers.
You can deploy cloud containers in one of two ways; either by creating an image to run in a container or by downloading a pre-created image, such as from Docker Hub. Although Docker is by far the largest and most popular container platform, with plenty of large companies using its solution. There are alternatives, such as LXD and Rocket (and the upcoming Microsoft products mentioned earlier). However, at this time, Docker has become synonymous with containerization. Originally built on a technology called LXC, Docker has become the predominant force in the world of containers. Though the library of pre-defined, pre-created images in Docker Hub is large, it doesn’t give developers the flexibility of mix-matching to meet their own standard requirements.
Cloud container security
Once cloud containers became popular, one of the biggest concerns was how to keep them secure. Until quite recently, Docker containers had to run as a privileged user on the underlying OS. Hence, if key parts of the container were compromised, one could potentially obtain the root or administrator access to the underlying OS and vice versa. Docker now supports what is called “user namespaces”. It allows you to run containers as specific users.
There is, of course, the issue of security of images downloaded from Docker Hub; by downloading an image (which other users have created), the security of the container could not necessarily be guaranteed. Docker has addressed this with a feature called Docker Content Trust (introduced in version 1.8), which verifies the publisher of the image. This is to scan images for vulnerabilities as well. This goes some way toward providing assurance, but their verification processes may not be thorough enough if you are using containers for particularly sensitive applications. In this case, it would be sensible to create the image yourself to ensure your security policies have been enforced.
And there is more to the security of cloud containers
That said, you should treat containers for sensitive production applications, the same way as any other deployment when it comes to security. Inside the container is software that may have vulnerabilities. Though this might not grant access to the underlying OS of the server, there still may be issues such as denial of service that could disable a MySQL container and therefore knock a website offline. It is also important not to forget the security of the server hosting the containers. Docker itself has some great advice on their website for securing containers. The important thing to remember is – containers are a newer type of technology. But, it doesn’t mean that you should not apply traditional security policies and procedures to them.
There aren’t many organizations that won’t benefit from introducing cloud containers to their infrastructure. Their portability, both internally and in the cloud, coupled with their low cost, makes them a great alternative to full-blown virtual machines. However, it will be the case that in most companies there is a case for both containers and virtual machines. Both have their strong points and their weaknesses and can complement each other rather than compete.