Containers, Containers, Containers the new buzz word, containers are going to significantly impact the DevOps. If you are new to container technology I would definitely recommend you start digging into them because they are here to stay.
In modest words containerization is a virtualization technology within a Single Machine (only Linux as of today). For Example: Azure provides virtualization using Microsoft Data Centers, we can build and deploy applications across any data center. Azure handles allocation of resources, creation of machines, deployment the packages and managing the machines (PAAS World). Similarly Docker uses Linux OS features (LXC, CGroups and Namespaces) to provide virtualization within the OS to host multiple containers\application instances each having their own view of the operating system.
Docker uses Linux kernel specifically Namespaces and CGroups to run multiple isolated containers (for example: instance of an application) on a single OS, each container is a unit of deployment having their own view\share of the OS Resources like CPU, Memory, File System, Network I/O etc.
Note: Although each container runs in an isolated environment on a single Linux OS, there also ways to link the containers and share the context as well. I will publish a separate blog just focusing on this so stay tuned!!
Let us understand containers better with a simple example:
Let us take a simple online discussion forum ASP.NET application which does all the foreground work (login, registration, threads, discussions etc.) with some background jobs like sending emails, resizing images etc. One way I would execute this on Azure would be to create a Cloud Service with one web role and one worker role one for each job.
The biggest question with this approach is why spin off 4 virtual machines? Even though the platform is managed by Azure there are few things which you may not like as a devops guy, for example: How much time does it take to deploy a new patch? Not less than 3-5 minutes some times more because Azure is spinning off a brand new instance once again, what about the CPU utilization for the worker roles? A whole machine just to run a simple job? All my job needs is some share in CPU and memory.
Let us consider another deployment model, why not like this?
This time I have used the IAAS model, I used one Azure VM and deployed my Web Application and Jobs inside the machine, fairly simple isn’t it? I’m just paying for one machine. But this means that we are entirely managing the Virtual Machine which is an overkill, how do I scale the application instances independently? How do I set up my release cycle? How do I maintain different environments Staging, QA, UAT, Prod etc.
Containers comes to rescue here, it helps you to deploy apps within containers inside a machine. Each container will run under an isolated context. You can create multiple containers (multiple instances of single application) using Images, so you can technically scale up/down when required. All of this can be managed from outside the machine through TCP/REST. With Azure or any cloud platform it is virtualization within virtualization.
The model looks like the one below, as of today this is possible only on Linux machines, until Microsoft ships one for Windows.
Docker is one famous container based technology build using open container standards which uses Linux Namespaces and CGroups to deploy applications/services in isolated environments. Docker team provides all the toolkits necessary for you to build, ship and run containers on Linux machines. As of today Docker also ships Windows based clients (boot2docker), Azure allows you to create Linux equipped with Docker Engine from VM Gallery and Marketplace as well. Docker also provides public and private repository for hosting your images/templates.
For more information: https://www.docker.com/
How does it work?
Technically Docker = Docker Engine + Docker Hub (repository for Images, both public and private).
1. First you need a machine with Docker Engine installed (which is what Azure provides today from Marketplace, you can also deploy from VS 2015). Docker engine running inside a Virtual Machine (could be Physical Machine as well) is exposed using TCP/REST API
2. Build your application as you do locally
3. Connect to Docker Engine using Windows/Linux Clients for Docker (for windows : Boot2Docker or Docker CLI which ships with VS 2015)
4. Push the binaries to Docker engine: At this point the binaries are not deployed, Docker creates a reusable image. These images can be public, private – you can build your own Docker Hub. Docker Hub (https://hub.docker.com) is an online repository which Docker provides for all users and any image you put here is public by default. There are a lot of images available here which you can hook into any time or refer in your own images.
· Run an Image, in other words create a container – this is when an instance of your application is deployed.
Happy Coding
In the next part of this series we will see how to get started developing (.NET) applications using docker and deploy them to Docker Machines.
Embracing change !! 