Analysis of Docker in DevOps : Part I

In our previous series of article, we discussed about Basics of DevOps, Virtualization Requirements for DevOps and Docker Tutorial For Beginners. Analysis of Docker in DevOps is a Series of Articles to Discuss the Solving Problems Arising within DevOps and Possible Fields of Application. This articles highlights some of the problems which IT-companies face. Due to the increasing merger of formerly independent areas and the resulting conflicts of objectives, new requirements arise within the development and the organization or processes of processes. DevOps concentrate on the areas of software development and software operation. The resulting conflicts of these two directly cooperating areas must be addressed and solved by using different techniques. Basics of DevOps and Docker will be explained with some details in this series. Subsequently, the requirements are defined both within the development and during operation. Afterwards, Docker solution concepts will be compared with the requirements and in order to present a precise practical relevance, these concepts are applied within imaginary scenarios. Also, we will discusses the requirements of implementation and the connection of other possible services, installation and configuration of Docker with Docker Compose. Finally, the topic will summarized with an outlook for future development.

Software development within the company is constantly developing new features for the software used. It has to respond to change requests agile, face new challenges and develop quickly and reliably. Responsible for this increasing development of an agile department is the fact of the rapidly changing market and the ever-changing requirements of customers and technology. These clients take a quick implementation of the tasks set as positive. The operations pursue the overall goal of stability and consistency. By implementing software updates in existing production environments and providing a secure, fail-safe system, every change request poses a potential risk of failure, but it must be compatible with development requirements.
As these areas work together, there are concrete issues with platform development, new feature release, testing and implementation in production environments.

 

Analysis of Docker in DevOps : Basics

 

DevOps

By principle, DevOps describes the approach of merging two concepts or departments, which are increasingly merging within the increasing networking in process-driven companies. This consists of software development (development) and system administration (operations). The background is the increasing need to meet the ever shorter development cycles within the software development while maintaining the quality standard.

DevOps is often associated with agile software development that represents a shift in the way software development works. However, the term also describes changes within the corporate culture as well as the roles and deployment chains that result from this approach. Deployment chains describe a deployment cycle that includes all necessary steps from requirements definition to deployment in the production system. In summary, DevOps’ approach seeks to resolve emerging goal conflicts within the combination of development and administration (operations), providing input and tools for doing so. The goal of the software development is to ensure a high degree of agility, which makes it possible to make adjustments quickly and respond quickly and dynamically to new requirements. This, however, while maintaining a high quality standard.

The frequent deployment resulting from agility and rapid customization is one goal of automating recurring tasks such as testing, build processes, and co. This should minimize the complexity, increase the development speed and reduce the susceptibility to errors. In addition, there is the advantage that the training of new employees easier, since no introduction into manual deployment steps must be made. The conflict of objectives arises here when considering the goal of the administration, which pursues reliability as a major goal. Here each deployment increases the risk of default. The continuous delivery approach, which means the frequent delivery of high-quality software, is favored by the DevOps approach.

For the employees involved in the development, this means that the planning and implementation of projects takes place together with development and administration. The goal must be to work as close as possible to the later live system during the development. The use of virtualization technologies or tools such as Docker makes it possible to minimize fault tolerance even during development since environmental errors are already apparent in the development environment. On the one hand, this favors the administration’s goal of ensuring high reliability and, on the other, it meets the agility goal of development.

In summary, the objectives of DevOps are defined as follows:

1. More effective collaboration between development, operations and quality management
2. Increased software quality by using Dev-Ops tools such as Docker or Vagrant, or even automated tests (high security standards, functionality and usability)
3. Increase the speed within the development, favored by tools such as Docker, as well as automated build and deployment processes by e.g. Jenkins
4. Easy deployment of code in production
5. Minimize complexity within deployments and builds with pre-defined DevOps tools

Furthermore, unit tests have to be implemented. Automated build processes which support the continuous integration approach provide the foundation for deployment. Subsequent, automated testing in terms of functionality and usability completes this step. In an automated deployment process, the continuous integration approach is also supported and enables a clean deployment of the changes made. Finally, within the execution, a monitoring is recommended whose behavior demonstrates success and, in the event of an error, supports a quick fix.

Docker

Docker is for developing, shipping, and running applications. Docker was first published in March 2013 by dotCloud. Docker makes it possible to operate applications in containers and thus to encapsulate them. While this is basically possible with any virtualization technology (VMWare, KVM, Hyper-V), Docker brings decisive advantages. Virtualization in virtual machines (VMs) basically have the disadvantage that each VM also has it’s own guest operating system, which results in a large image in addition to increased CPU and memory consumption. It is not easy to share a VM with someone. Docker solves this problem by having all the containers share a kernel so that only the application is part of the container. Similar but primitive system provided by OpenVZ.

Docker makes it possible to separate the actual application from the infrastructure and treat it like a managed application. The actual DevOps goal of enabling faster development cycles is made possible by Docker. Deleting the code faster with it’s defined purpose enables faster, automated testing, faster deployment, and thus shortens the cycle between development and implementation in the production system. Another goal Docker achieves is creating a platform which allows to work in a unified development environment, regardless of the end system used. This reduces the environment-related error rate when deploying in productive systems, as well as the training time of new developers. This creates a unified environment for all those involved whose maintenance and development will be centralized.

Furthermore, the exchange between already completed sub-applications should be promoted. These finished containers can be shared via Docker Hub. For this purpose, an image is first generated, which in turn is provided for distribution. This makes it possible to reuse resources and to promote the exchange of once created containers.

Docker is operated using a client-server architecture. Here the Docker client addresses the so-called Docker Daemon. This takes over the task of the controller and is responsible for distributing the respective requests to the containers in a controlled manner, as well as ensuring the build and run process at the same time. Docker Client and Daemon can both run on the same system or be paired with an outsourced daemon. In any case, the daemon-client communication is either through sockets or the RESTful API.

The Dockefile indicates how an image can be built. The most important commands has been discussed in our tutorial on basics of Docker.

An image is the file system of a container. Each image consists of a large number of different layers, based on a file System. Docker uses the so-called copy-on-write approach, which ensures that a write action in the Dockerfile creating a new layer containing the change to the previous image. This approach has the advantage that a docker layer is always very small and can be easily replaced or updated. Docker images can be maintained publicly or privately in a registry. It is referred to as the Dockers distribution component because it is the exchange between finished Docker images. An example is Docker Hub. Images can be pushed to such a registry and can be cloned. By using the Docker client, available images can be loaded into the installed Docker and corresponding containers can be created. DockerHub provides freely available downloads within Public Storage. For private use with defined user groups, the use of private storage is provided, which ensures a corresponding access restriction. Containers can be started, stopped, moved or deleted. Each container is as if an isolated, secure application platform. Each container is formed from a Docker image and contains everything that a running application needs. This includes access to the shared kernel, added files, and stored metadata. Configuration data and execution routines within the boot process of such a container are recorded within the Docker image.
Other basic Docker-related terms are Docker Swarm and the Docker Machine. They are not directly related to the basic use Dockers, but represent in the daily business a good feasibility.

Docker Swarm is a docker native cluster solution that allows a pool of hosts to be represented as a virtual host visible to the outside as a unit. Any tool that already communicates with a Docker Damon will have Docker Swarm’s ability to transparently scale it. This is ensured by using the Docker standard API. Applications such as Jenkins, Dokku, cranes are supported. First of all, the Docker swarm image is loaded. After configuration of the Swarm Manager and the assigned nodes, it is already executable. For this purpose, we open the TCP port of each node for communication with the Swarm Manager, install Dockers on each node, install valid TLS certificates to ensure security. Docker Swarm also offers the option of installation via docker-machine. This automatically automates settings necessary for implementation. It is thus possible to implement a quick and uncomplicated implementation within cloud-based environments, in one’s own data center or even in virtual boxes.

The standard command CLI is extended with Docker syntax. Commands such as “docker run hello-world” are available regardless of the environment. Similarly, the installation manages the management of multiple Docker hosts. Each Docker instance is a combination of a Docker host and a configured client. Docker Engine is the component that provides the Docker Daemon and runs the containers at the end. Docker Machine, on the other hand, refers to a tool for managing Docker-based hosts. Machine makes it possible to install Dockers on one or more virtual machines – as well as remotely, as locally.

 

Conclusion on Basic Analysis of Docker in DevOps

 

In this part of the series of article, that basic terms and concepts around Docker and DevOps has been explained for revision. Dockers implementation will be discussed after discussing the specific requirements within software projects. In next part, requirements will be discussed.