As I sat down to write a blog about containers, various topics on the specific advantages or disadvantages associated with the aspects of container ecosystem crossed my mind. But, after going through various iterations, I decided to look back at my journey thus far into the container space — which started around two years ago — and try to address, through a series of blogs, the challenges that I faced in finding and getting simple answers to the questions I had during my learning phase. There is a lot more information, to the extent of being a deluge, on containers available on the internet now which further adds to the problem of finding simple answers to basic questions. Of course, I am adding a few drops to the deluge by starting this blog series but I hope that it will serve the purpose that it’s intended to.
So then, what are Containers? The concept of Operating System supported containers has existed for a while but companies like Docker have popularized the approach of Container Images – especially application container images. Simply put, a Container Image comprises one or a sequence of snapshots of an application and its dependencies — libraries, language runtime etc — on a particular OS. The creation of an image by carving out all that matters to and is required by the application significantly helps in a) moving the application seamlessly from one environment to another and getting the exact same runtime behavior — portability, and b) starting, stopping and moving applications across the underlying infrastructure very quickly — agility. These two benefits themselves have led to the tremendous adoption of containers.
Just like an application can be monolithic — everything contained in a single module that runs as a single process — or can be split into multiple modules and services that run in separate individual processes, same goes with the the containers. An application could spread across various container images, with their corresponding dependencies “contained” in them.
After getting an introductory understanding of what something is, the next question that usually pops up in one’s mind is that of its lifecycle — the various stages a container goes through in its life and the popular tools that are helpful in managing each phase. The following diagram shows the various states a container goes through in its lifecycle
Since a container image is made up of layers, one could choose to either create an image from scratch or from an existing image, or even from one of the layers of an existing image as a starting point.
Following are the links to the Docker and Rocket container ecosystem pages for creating images. Indeed, there are various other container ecosystems and the associated tools for operating in them but I have mentioned the the most popular ones.
Docker — https://docs.docker.com/engine/userguide/containers/dockerimages
Rocket — https://coreos.com/rkt/docs/latest/getting-started-guide.html
After a container image is created, one of the easiest ways to share that image is to post it on a Registry. A Registry is a storage repository for the images. Think of a container registry as a mobile App Store where, just like with apps, developers can publish their containers and others can download from there. Additionally, just like with the App Stores (though an enterprise feature), the image publisher can restrict its access to only specific groups of users. However, unlike in the case of App Stores, there are no predefined and preset stores (such as iTunes for iOS and Google Play for Android) only from where the users can download the apps and expect them to clean (free of any malicious code) — as they trust Apple and Google to perform a diligent job of evaluating and accepting only those apps that meet their stringent criteria. With container image registries, the onus is on the one downloading the image to ensure the source of the image is who it claims to be and that the image is free of any known vulnerabilities. I will cover the details on this particular topic in a future blog post.
Once a container image has been downloaded (the technical term is ‘Pulled’) from a registry, the next step is to plan the deployment and execution of that image. In the container ecosystem, the term used to refer such activities is ‘Orchestration’. As I explained above, some applications could comprise multiple container images and may require the modules and services to come up in a specific order. Many excellent tools are available for the purpose:
Google — http://kubernetes.io
Docker — https://www.docker.com/products/docker-compose and https://docs.docker.com/swarm
Apache Mesos — http://mesos.apache.org
The flip side to the ease in creating and launching containers is that it leads to a lot of images created without giving proper thought to security and how security related tasks would be performed on the images during their lifecycle. The approach of ‘Create, Publish and Forget’ is already leading to a container sprawl. The other disadvantage of all of an application’s dependencies being contained in the image is that each image for that application, every variation of it, that has a vulnerability has to be patched. Since there are no trustworthy and authoritative image repositories for containers, a la mobile App Stores, it’s safe to assume that most container images out there are vulnerable even to the mostly widely known vulnerabilities. For example, the CoreOS Clair team found that 80% of Docker images uploaded to their service were still vulnerable to the SSL Heartbleed attack (https://coreos.com/blog/vulnerability-analysis-for-containers).
Patching a container image for a vulnerability is similar to changing dressing for a wound — all the image layers above the layer in which the vulnerability is detected must be ripped off, the vulnerable layer is patched and a new baseline layer is created, and all the ripped off layers are applied on the patched layer one by one.
In order to patch an image hosted on a registry, the image must be downloaded (‘Pulled’) from there, patched and then published (‘Pushed’) back to the registry.
Unfortunately, none of the popular public container image registries mentioned above automatically scan the images for vulnerabilities and tag them accordingly.
End of Life:
As with most things in life, the containers also reach a stage when they outlive their purpose, are not relevant anymore or can’t be used (due to vulnerabilities or other issues, such as bugs) and hence must be End-of-Life’d lest they continue to add to the container sprawl and pose a risk to someone mistakenly downloading and using them.
I hope I have given a basic idea of the Container Lifecycle through my first blog. There’s so much to cover in this space but I intend to keep my commitment of keeping things simple yet useful while sharing the knowledge in a logical manner and building it in layers (definitely, pun intended :^))
CEO, Layered Insight