For a while now, there has been a lot of buzz in the I.T domain about a technology known as containers and I’m pretty sure a lot of us who have heard this must be wondering what it’s about and have probably done a couple of research to the point of testing the waters and got little or almost nothing to take home as knowledge for different reasons – if you’re anything like me too much of information was definitely a blocker to my container knowledge at first. Thus, the reason for coming up with a containerization series for you to begin.
Who is this for?
- Developers: who build applications (you don’t have to be an expert).
- DevOps (operations) engineers: those in charge of hosting, continuous integration and deployments.
- Anyone slightly in the I.T domain who knows what it’s like to build and/or host applications.
This is the first chapter of "The Containerization Series” written to give a stable head start and bring you up to speed with the fast-rising technology of containers. This series consists of 6 chapters spread out to take us from novice to a fundamental level of understanding about containers and their use through a hands-on approach. The entire series includes:
- Introduction to Containerization
- Working with Containers #1
- Working with Containers #2
- Deploying Containers
- Multiple apps container
- Container Orchestration
By the end of this chapter we’ll learn:
- The meaning of containerization and companies that enable this technology.
- The underlying mechanism behind containers and how they’re different from virtual machines.
- Uses of containers.
- Where to get started on containers.
- How to set up containers.
The entry point to greatness in your journey through I.T starts with your dirty hands… – Unknown.
What is containerization?
Containerization is coined from the term container which we can say is the running image of an application (regardless of its size and feature) built-in isolation with its dependencies needed to function in the desired manner regardless of the environment or system being served on, i.e. the application will act in the same way, give the same result as it would on my local environment as it would on yours, on my colleagues’, on the cloud and so on. Therefore, we may define containerization as the adoption of containers in building an application.
In the definition of containers above, we used the word image – this is known as the blueprint and the final product of a container. The image is a blueprint because it is mostly used as a base layer when creating a container (more on this in a later series). What I mean is we use an image (or images as the case may be) to create a container. An image is equally the final product because after our container is created, it is packaged into an image that can be pushed or sent to other environments to be run as the same container we created.
For example, let’s take a monolithic mini e-commerce store that has a frontend built with reactJS, a backend with nodeJS and a MySQL database. To containerize this application, we would use the image of a base Operating System (which can either be a Linux or Windows kernel, but for the sake of this we’ll use Ubuntu, a Linux kernel) because we need to install node and a MySQL image.
Many times the terms “docker container” and “docker image” are used interchangeably but now we know the difference from the definitions and table as seen below.
Table 1. Differences between Container & Image
This brings us to Docker. We are used to thinking containers and images must be used together with Docker when talking about containers but in reality, Docker is the company that developed the container technology and has been the most popular provider of this technology thereby making it a justifiable thought. This thought however calls out other companies like rkt, lxd, Linux Vserver, OpenVZ, OpenShift Mesos, Windows Server Containers, Kubernetes, etc., who are also in the container making business.
What is the ideology behind containers?
With the knowledge that container is the technology and Docker the company, we may now talk about the ideology behind containers. We see from the definition of a container, that it talks about “building an application with its dependencies in isolation”, bringing up the question – what actually is the application being isolated from? The short answer is other installed dependencies that are not needed by the application on the host environment which could be your development machine (PC) or server.
A longer answer starts from the need to provide our host environment with the needed dependencies which include storage memory, processing memory, libraries, runtimes, etc. when building an application. Sometimes we may not even need some of these dependencies for any other application asides from this application and other times in the future when we may need them, we use the dependencies already installed from the previous (where it applies) and then provide others that don’t already exist on the host. From this we can already predict a couple of challenges ranging from redundant storage space to conflicts in libraries which could arise from differences in versions, just to name a few. Now how do we overcome these challenges? Well, we need a way to label or isolate an application with its dependencies so that they do not conflict with that of any other application on the host and a temporary or compressed amount of memory per application. One way to go is the use of virtual machines.
For a very long time, virtual machines have been the way to go in tackling challenges of this kind but they come with even more challenges, like taking up more resources (thus, doesn’t solve the issue of storage) and virtual machines are not so cheap. Although they solve the challenge of conflicts by isolation as it is a case of dedicating an entire machine for just one application – this means that we may not use the host machine for another application if we’re using it for our mini e-commerce application already. Read more about virtual machines here.
The other option is the use of containers, in which an application with its dependencies is isolated and treated as just one process (on the CPU) of our machine taking up only a very little amount of resources, thus solving our predicted challenges. It is a case of dedicating a process for one application i.e. we may have many more processes (applications) running on our host machine alongside our mini e-commerce app.
Table 2 Difference between VMs and Containers
What is the need for containerization?
From the exhaustive discussions from the meaning to the underlying ideology of containers, we should have highlighted more than enough reasons as to why we may need to containerize. Nevertheless, here’s a few reasons to use containers for development:
- Exact replication of application and output regardless of the environment: this is very important for developers working in a team because it totally eradicates the situation of “it works fine on my own PC; I don’t know what’s happening on your PC”.
- Minimal use of resources on the host machine: as we have defined that containers are run as processes on our machines thereby only using most times megabyte worth of data as opposed to having a lot of resources running into hundreds of MB to GB in cases of running applications like databases, SDKs, to name just a couple.
- It is cost-effective when thinking of Microservices: when we need to deploy a microservice application, the thought of how much it will cost to host all services independently but however, we now have cloud hosting providers who have services dedicated to hosting containers specifically.
- Helps application-specific scaling/update or even patch: it is easier to scale containerized applications as we only need to focus on the part that needs to be dealt with without affecting any other container or applications.
- No environment compatibility issue: a container can run on any environment regardless of the operating system (OS).
How to set up a container (Docker)
Hopefully, by now we have a clear base on what containers are and why we need them or know better when to use them. If that’s the case, then we should talk about where to begin using containers. I recommend creating an account on Docker and download the OS-specific desktop application. Yes, Docker is for many reasons the recommended place to start. Now walk through the steps on Docker to set up Docker (based on your OS) on our local machine to begin our walk into the world of containerization.
What next?
Now we have set up Docker on our local machine, the next thing to do is to start working with images and containers from our machine and pushing them to our repositories.