What is DevOps and Configuration Management

DevOps

First of all I want to address the biggest confusion here i.e. DevOps is not any tool, or technology, or some product one can use to make and do things better. DevOps is an idea, a management and operations approach – emphasizing on cohesiveness between development and operations teams. In simplest words, it’s about gluing the development and the IT operation hence the name DevOps:
  • Dev – comes from development (developer/software engineers), people who make the system/software, and update it during it’s lifetime.
  • Ops – from IT operations (sysadmins), who take care of the system once it’s developed, i.e. in production.

As per Wikipedia:
A software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.
The motive behind DevOps is keeping the communication gap between the developers and the sysadmins to minimum – to improve, standardize, and automate deployments and infrastructure orchestrations, for consistency between development and production environments, better QA, efficient operations, accelerated time to market, and many more.
Implementing DevOps is only possible using various tools and technologies:
  • Automated build tools – jenkins, travisci, etc.
  • Provisioning and Configuration Management, like Puppet, Chef, Ansible.
  • Orchestration i.e. Zookeeper, Apache Mesos.
  • Monitoring & Alerts e.g. Amazon CloudWatch, ELK stack, graphite, etc.
  • VMs and Containers for development and production environment consistency e.g. vagrant, docker.

Configurations Management

As said DevOps is just an operational approach, so let’s move to the clarification of the second buzzword i.e. ‘configuration management’ – in simplest words, configuration management tools make it possible to implement or practice DevOps.
Loosely speaking configuration management is about installing and updating system packages, setting network configurations – in short, making machine/server ready for deployment once it comes live, or even later.
Before DevOps and the availability of mature configuration management tools, sysadmins were required to perform these provisioning on each machine/server, which was operational inefficiency, laborious and carried a very high chance of introducing configuration inconsistency across the servers i.e. most common example is, configuration inconsistency between development and production environments, which has high consequences.
“Configuration management is the process of standardizing resource configurations and enforcing their state across IT infrastructure in an automated yet agile manner.” [Puppet]

“The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items” [SEI 2000a].

“Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.” – Wikipedia 
In the present and technical sense, configuration management (CM) tools enable Ops (i.e. sysadmins) to define their infrastructure in code i.e. all the available CM tools (Puppet, Ansible, Chef, etc), offer you to declare the required system state or provisioning (package installation, updates, configuration settings, etc) in form of code or a declaration – the type and form (syntax) of this declaration is what varies between theses CM tools, otherwise they are one the same thing.
With these CM tools, all what is required from you is the configuration or provisioning declaration file. You can specify the packages to install and configure, stop or start a service, etc. This system state declaration in form of code/file also brings other benefits i.e. by making the file part of the project/repository you can have system configuration history in form file versioning, the system configuration will available for Dev and Ops, the provisioning will be consistent across the servers.

Puppet Example

To dig it further, I am sharing a Puppet example here (to feed your curoisty – Getting Started with Puppet) – the declared configurations are called Puppet manifests, and the convention here is to create a /manifests directory at project root, and place all the manifests inside it i.e. your_project/manifests/default.pp – default.pp is the manifest file, all the Puppet manifests have .pp extension. The system resources and their state can be described, either using Puppet’s declarative language or a Ruby DSL (domain-specific language).
Example – a simple use-case, install Apache web-server on CentOS and Ubuntu machines. The same package is Apache2 in Ubuntu, while for CentOS it’s available as httpd.
  • Get the type of operating system,
  • Install apache and start the service
case $operatingsystem{
centos:{
$apache = 'httpd'}
ubuntu:{
$apache = 'apache2'}
}package { "apache":
name    => $apache,
ensure  => present,
}service { "apache":
name    => $apache,
ensure  => running,
enable  => true,
require => Package["apache"],
}

Leave a Reply

Your email address will not be published. Required fields are marked *