Architecture of Docker

- Docker client

It is the external face of docker. User can communicate with docker through the docker client's command interface. Docker client can run in the same host as the docker daemon or it can run in a different host as well. Docker client can connect to a docker daemon through sockets or RESTful API.

- Docker daemon

Backbone of docker containers. It is responsible for building, running and distributing docker containers. User communicate with docker daemon through the client.

- Docker registry

Docker registry holds docker images which are basically a form of read-only template for containers. An Ubuntu operating system with Tomcat and your web application can make up the docker image. Registry can be public or private. Docker hub (https://hub.docker.com) is a public registry provided by Docker and enable people to share their images with others.

To understand how Docker works, one first needs to understand how does a docker image works... In a nutshell, a docker image consists of several layers. Union file systems enable layers to be combined into a single coherent image. As a result of the layering structure, docker images are lightweight and update to the image can easily be applied to a single layer of the image. Therefore, docker images can easily be pulled and pushed in contrast to virtual machines.

Every docker image starts with a base operating system image such as Ubuntu or Fedora. User provided "Dockerfile" includes instructions to specify what additional layers will be added. Each instruction can be an action either running a command, adding a file or directory, creating environment variables or specifying what process to launch when running the container. Each instructions add additional layer to the base image and after each instruction is completed, a final image is generated by Docker.

Docker images are read-only. Containers are built from docker images. When docker runs a container from an image, it adds an additional read-write layer on top of the image, then the application can run.

Docker takes advantage of several Linux kernel features to work seamlessly. "Namespaces" are used to create isolated workspace which docker calls as the container. Docker creates several namespaces including:

• 'pid: process isolation' 

• 'net: network isolation' 

• 'ipc: inter-process communication namespace' 

• 'mnt: mount points'

• 'uts: kernel and version identifiers isolation' namespace 

Control groups (cgroups) are used control the resource (max, min) that the container would use. Union file systems is utilized for combining multiple layers in a coherent way.

Docker combines all of these components into a wrapper called container format (libcontainer). Docker also supports Linux containers.

Docker provides couple of tools to optimize and ease the deployment of containers into clusters. These components are:

• Docker Machine: Create and manage machines running docker daemon.

• Docker Swarm: Native clustering capability by turning several Docker engines to a single virtual docker engine.

• Docker Compose: Provides capability to define multi-container applications in a single docker file.

• Docker Registry: Storage and distribution for docker images.

• Docker Engine: Builds and run docker containers.

• Docker Kitematic: UI for managing and docker engines, images and containers.

- Additional Notes

• Some good points in this article (although it's improved later on, so make sure to see second and third part of the article): https://opensource.com/business/14/7/docker-security-selinux

• Users are not namespaced in containers, means that if you run an application as root, then it has all the privileges on host, no isolation for users.

- Suggestions for how to run docker from the above article 

• running minimal images: that contains minimum number of services and applications to reduce the attach space.

• using read-only file system: so that no malicious scripts can be downloaded and written.

• limiting kernel calls: with SELinux.

• restricting networking: only linked container communication.

• limiting memory and CPU: with cgroups so as to prevent Denial of service attacks.

Is Container a new -aaS? Container Technology in a nutshell

Introduction

---

Three cloud computing models have been emerged so far: SaaS, PaaS and IaaS. For the sake of brevity, lets focus on the latter two. When cloud computing first emerged, Infrastructure as a Service (IaaS) was the main driver of cloud computing business. Amazon Web Services (AWS) started its business by selling virtual machines. The problem with IaaS is developers have to manage all the details including which operating system to install, keeping installed softwares up to date in addition to developing and deploying applications. Too much burden... As a res

ult Platform as a Service (PaaS) emerged. In PaaS, developers only need to care about developing their applications without worrying about infrastructure level issues such as the latest security patches for the operating system or figuring out the right firewall rules. The PaaS model has made all of these easier for developers. Cloud Foundry (CF) has emerged as one of the widest deployment of PaaS so far. IBM, HP, Pivotal and others has already embraced and been using cf in their offerings.

So far so good except that we have started to see a kind of new model in application development, i.e. containers. So the question arises, wasn't it everything great, what the hack containers are? Although there is no simple answer for the question, looks like, not everything was perfect, at least from the developers' perspective. So what's a container? Container technology basically an extension of linux containers which was first released in 2008 (https://en.wikipedia.org/wiki/LXC). Containers provide isolation in the operating system level. Probably at this moment, you are wondering what containers offer that PaaS or IaaS don't. There are several aspects which I will try to examine below:

Portability

---

I think Portability is the most compelling reason for the emergence of containers. Virtual machines typically is not considered to be portable considering the size and all the other burdens. Moreover, consider a typical application development in PaaS. Take cloud foundry as an example... You choose a runtime (Node.js) and couple of services (which runs independently outside or inside of the platform) and run your application. Now in future if you change your mind and try to move to IaaS, you will need to do a lot of tasks including installing your own Node.js runtime and database services etc. Moving into another PaaS solution is another headache with all the different capabilities and settings unless they are all compatible which sounds like a myth for me. On the other hand, containers promise portability, you package your application by telling which software to install and how to initiate/start them. Rest is taken care of the container engine (for docker it's docker engine) by running them as linux containers inside a linux machine. If you later decide to move from your original machine and go somewhere else, you will still be able to do it easily without worrying about the size and compatibility.

Microservice Model

---

In software development, especially in recent years, there is an obvious tendency to develop application as microservices instead of a monolithic model. Especially with multiple teams working on different parts of the application, microservices offer the right model to go for as development and deployment of each microservices will be independent from each other. As a result, there will be less risk of failures during the development and deployment. In microservice model, everyone is responsible for their own service. If you are an owner of the database service then you need to provide that database service as robust and solid as possible. As a result of reducing the dependency of teams, deployment will be faster, easier, less prone to errors.

Now lets think about the containers for a second. In a nutshell, if you develop your service as a container, your service will get the benefit of containers by providing an isolation of a service from the other services. Each service of the application will be deployed as an independent container and as a result each will be able to work independently and deploy independently. If you try to do the same in cloud foundry then you need to create a separate application for microservice that you want to develop (aside from the available services in the catalog that can be directly bound to the application). It does not sound like a good model both in terms portability and maintainability.

Flexibility

---

This might be a little biased and subjective perspective but if you ask me, developers love hacking things and then fixing them up. Like it or not, this is a given characteristic of today's developers. As a result quarantined infrastructure environments don't work for them. They want more power and flexibility in terms of controlling the environment and I believe that the PaaS models lack of this flexibility. Containers provide a tier above VMs and therefore give developers a feel of control without dealing with all the burdens of managing a VM.