Here I will be posting my notes as I learn Devops concepts.

Configuration Management

I am currently learning about DevOps and an important component that forms a part of DevOps is a topic called Configuration management. For an introduction to Configuration management, we should know why it’s needed. For instance, if you are a company developing a Java based application and would like to deploy your software in 100s of computers/servers/nodes, you would need a tool to ensure that the software is deployed in a machine which has the correct configuration. For running Java applications, Java Virtual Machine(JVM) is required to be installed on the host. This can either be done manually or automated with the help of a tool. For a simple setup configuration on a single machine it can be done manually. However, if you would like to do it across 1000s of machines with complex combinations, an automated tool can be of great use. This is where configuration management tools come into the picture. It helps when you want to deploy configurations across scale and also helps prevent human error. It also enforces standardisation across different configurations. CM tools can also be used to deploy source code across vast configurations and it also eliminates the need for documentation process for configuration changes. There exists three steps in the configuration management process, namely: configuration identification, configuration regulation, configuration and configuration compliance. In configuration identification, you identify the configuration that needs to be deployed. In configuration regulation, you deploy and regulate the configuration and in the compliance stage, you check whether the configuration that is deployed is successful and complies to the standards needed for your application.

There are two types of CM tools:

1. Pull-based: In this type, a client server architecture exists across node and server. The node has to have the specific CM tool installed and regularly polls and pulls in the configuration information(CI) from the server. Examples of this type of CM tool is Puppet and Chef. Both of them are based on Ruby. A slight difference between Puppet and Chef is that Chef contains an additional component(apart from Node, Server) called workstation, for creating the configuration information.
2. Push-Based: In this type, similar to the previous type, a client server architecture prevails. However, there is a slight difference. In this case, the server pushes the CI to the nodes periodically or when needed according to your setting. Examples of this type are Ansible, Saltstack. Both are push based and are written in Python. They use YAML files to describe CI.

The most preferred(personal opinion) among all these tools is Ansible. Ansible has simple architecture and has a low learning curve. However, it’s GUI is not as good compared to Chef and Puppet. It is also among the cheapest option(Cost of Ansible Tower for 100 nodes is around 3000 US dollars). Hence, I will be learning and practicing Ansible.

Docker Containerisation

Virtual machines enable emulation of software operating systems without the use of any hardware. An advantage of virtualisation is that you can test your software without the need for real hardware on different operating systems. However, virtualisation is quite expensive and this is where containerisation comes into picture.

In a container, you will setup an environment that is required for testing your application and can simulate a real OS. This process is called containerisation. Note that virtualization is not same as containerisation. They are two different concepts. Typically, a virtual machine is much more complex than a docker container. Similarly, the disk and memory usage is much more for a virtual machine than a docker container. One disadvantage of using containers is that it’s not meant for running desktop software(once that needs GUI).

Docker is an open-source software that enables microservices(short word for splitting pieces of functionality of a service and deploying them on different machines) and containerization of SW applications. It is independent of operating system and supports platforms based on both windows and unix environments. It is fast, reliable, light-weight/resource efficient and extremely scalable. Docker also helps reduce costs on infrastructure. It helps standardization of SW applications. It also is a good solution for CI/ CD implementation of SW applications. Docker has images which determine the operating system of the container. Multiple containers based on different images can be created on the same machine using docker. Docker hub is a repository for storing docker images. Images will be pulled from the repository and containers will be created.

There are three components involved with Docker Architecture: Docker Client, Docker Server and Docker Registry. Docker client is the command line interface which is called as Docker for naming purposes and is used for interaction by users. Docker Server is the service and will be running in the background, will be responsible for creating/managing the containers. Docker Registry is the repository which stores Docker images. Docker hub is the default registry for docker containers. Other registries can also be used.