Chef – IndianGNU.org

DevOps – Comparison of different Configuration Management Software

By Arun Bagul | September 25, 2017 | Comments 0 Comment

Introduction-

I’m working as DevOps since 2010. Many colleagues, friends asked me about comparison of different Configuration Management Software like Chef, Puppet or Ansible/Salt etc.

It is very important and difficult task to choose right CM(configuration management) software for managing Infrastructure and Application deployments.

I’m attaching pdf file with comparison of different CM hope it will help you.

Document – Devops-Comparison-v3

NOTE: This comparison is purely based on my knowledge and experience. Please feel free to share your updates.

Thank You,

Arun Bagul

Top 5 configuration management software

By Arun Bagul | July 31, 2017 | Comments 1 comment

Why Configuration Management?

DevOps and CM(Configuration Management) are different. DevOps is about collaboration between people, while CM tools are just that: tools for automating the application of configuration states. Like any other tools, they are designed to solve certain problems in certain ways.
Using CM you can make changes very quickly, but needs to validate those changes. In considering which configuration management tool to select, you should also think about which complementary tool(s) you will use to avoid the costly effects of automating the deployment of bugs in your infrastructure-as-code.

The advantages of software configuration management (SCM) are:

   – It reduces redundant work
   – It effectively manages simultaneous updates
   – It avoids configuration related problems
   – It simplifies coordination between team members
   – It is helpful in tracking defects

Top five(5) tools for configuration management

1) Chef –

Like Puppet, Chef is also written in Ruby, and its uses a Ruby-based DSL. Chef utilizes a master-agent model, and in addition to a solo mode call chef-solo.
Chef is one of the most popular SCM tools. It is basically a framework for infrastructure development. It provides support and packages for framing ones infrastructure as code. It offers libraries for building up an infrastructure, which can be deployed easily. It produces consistent, shareable and reusable components, which are known as recipes and are used to automate infrastructure. It comprises the Chef server, workstation, repository and the Chef client.

2) Puppet –
Another SCM tool commonly used is Puppet. It was first introduced in 2005 as an open source configuration management tool. It is written in Ruby. This CM system allows defining the state of the IT infrastructure, and then automatically enforces the correct state. The user describes the systems resources and their state, either by using Puppets declarative language or a Ruby DSL. This information is stored in files known as Puppet manifests. It discovers system information through a utility called Facter and compiles it into a system-specific catalogue containing resources and their dependencies, which are applied against the target systems.

It is frequently stated that Puppet is a tool that was built with sysadmins in mind. The learning curve is less imposing due to Puppet being primarily model driven. Getting your head around JSON data structures in Puppet manifests is far less daunting to a sysadmin who has spent their life at the command line than Ruby syntax is.

3) Ansible –

A newer offering on the market, Ansible has nonetheless gained a solid footing in the industry.
Ansible is an open source platform for CM, orchestration and deployment of compute resources. It manages resources with the use of SSH (Paramiko, a Python SSH2 implementation, or standard SSH). Currently their solutions consists of two offerings: Ansible and Ansible Tower, the latter featuring the platform’s UI and dashboard. Despite being a relatively new player in the arena when compared to competitors like Chef or Puppet, it’s gained quite a favorable reputation amongst DevOps professionals for its straightforward operations and simple management capabilities.

4) SaltStack –

Salt is an open source multitasking CM and remote execution tool. It has a Python-based approach to represent infrastructure as a code philosophy. The remote execution engine is the heart of Salt. It creates a high speed and bi-directional communication network for a group of resources. A Salt state is a fast and flexible CM system on top of the communication system provided by the remote execution engine. It is a CLI-based tool.
It was also developed in response to dissatisfaction with the Puppet/ Chef hegemony, especially their slow speed of deployment and restricting users to Ruby. Salt is sort of halfway between Puppet and Ansible – it supports Python, but also forces users to write all CLI commands in either Python, or the custom DSL called PyDSL. It uses a master server and deployed agents called minions to control and communicate with the target servers, but this is implemented using the ZeroMq messaging lib at the transport layer, which makes it a few orders of magnitude faster than Puppet/ Chef.

5) Juju –

Juju is an open source configuration management and orchestration management tool. It enables applications to be deployed, integrated and scaled on various types of cloud platforms faster and more efficiently. It allows users to export and import application architectures and reproduce the same environment at different phases on cloud platforms such as Joyent, Amazon Web Services, Windows Azure, HP Cloud and IBM.

The main mechanism behind Juju is known as Charms that can be written in any programming language, whose execution is supported via the command line. They are a collection of YAML configuration files.
Clients are available for Ubuntu, Windows and Mac operating systems. Once you install the client, environments can be bootstrapped on various cloud platforms such as Windows Azure, HP Cloud, Joyent, Amazon Web Services and IBM.

Thank you,
Arun Bagul

Launching AWS instance using Chef server

By Arun Bagul | February 19, 2016 | Comments 1 comment

Overview:

Chef enables you to automate your infrastructure. It provides a command line tool called knife to help you manage your configurations. Using the knife EC2 plugin you can manage your Amazon EC2 instances with Chef. knife EC2 makes it possible to create and bootstrap Amazon EC2 instances in just one line – if you go through a few setup steps. Following are steps to setup your Chef installation and AWS configuration so that we can easily bootstrap new Amazon EC2 instances with Chef’s knife

Following are the steps need to launch AWS instance.

A. Installation and Configuration of Knife Ec2 instance

1. Instaiing knife-ec2 instance:

a. If you’re using ChefDK, simply install the Gem:
$ chef gem install knife-ec2

b. If you’re using bundler, simply add Chef and Knife EC2 to your Gemfile:
$ gem ‘knife-ec2’

c. If you are not using bundler, you can install the gem manually from Rubygems:
$ gem install knife-ec2

In my setup I used ChefDK.

2. Add ruby’s gem path to PATH variable to work knife-ec2 with AWS

$ export PATH=/root/.chefdk/gem/ruby/2.1.0/bin:$PATH

3. Add the AWS credentials of knife user to knife configuration file i.e ~/.chef/knife.rb.

——————————————————————————–

knife[:aws_access_key_id] = “user_key_ID”
knife[:aws_secret_access_key] = “User_secret_key”

———————————————————————————

B. Prepare SSH access to Amazon EC2 Instance.
1. Configure Amazon Security Group
As Amazon blocks all incoming traffic to EC2 instances by default. We’ll need to open the SSH(22) port for knife to access a newly created instance. Also HTTPS(443) port to communicate launched instance’s chef client with chefserver.Just login to the AWS management console and navigate to EC2 Services Compute Security Groups default group.Then add a rule for Type SSH and HTTPS with Source Anywhere and save the new inbound rule

2. Generate Key Pair in AWS Console
To enable SSH access to Amazon EC2 instances you need to create a key pair. Amazon will install the public key of that key pair on every EC2 instance. knife will use the private key of that key pair to connect to your Amazon EC2 instances. Store the downloaded private key knife.pem in “~/.ssh/knife.pem” of ec2-user.

3. Prepare SSH configuration to avoid host key mismatch errors:
Create “/home/ec2-user/.ssh/config and add below content:
_________________________________________________________
Host ec2*compute-1.amazonaws.com
StrictHostKeyChecking no
User ec2-user
IdentityFile /home/ec2-user/.ssh/knife.pem
_________________________________________________________

C. Choose an AMI for your Amazon EC2 instances
We need to choose the right AMI for region, architecture and root storage. Note down the AMI ID (ami-XXXXXXXX) to use it with knife.

D. Create an EC2 instance using Chef knife:
Now, it’s time to use knife to fire up and configure a new Amazon EC2 instance. Execute below command to create instance.
$sudo knife ec2 server create -r “recipe[dir]” -I ami-0396cd69 -f m3.large -S knife -i /home/ec2-user/.ssh/knife.pem –ssh-user ec2-user –region us-east-1 -Z us-east-1b

Options:
-r is the run_list I want to associate with the newly created node. You can put any roles and recipes you like here
-I is the AMI ID
-f is the Amazon EC2 instance type
-S is the name you gave to the SSH key pair generated in the AWS management console
-i points to the private key file of that SSH key pair as downloaded when the key pair was created in the AWS management console
–ssh-user the official EC2 AMIs use ec2-user as the default user
–region us-east-1 If you want your instances to be deployed in any specific Amazon AWS region, add this parameter and the desired region
-Z us-east-1b is the availability zone within your region

NOTE:
If you did not give the –r i.e run list with above mentioned command, then it throws the Exception below:

“EXCEPTIONS : NoMethodError Undefined method ‘empty?’ for nil:NilClass”

E. Terminate instance and delete the corresponding Chef node
$ knife ec2 server delete i-XXXXXXXX –region us-east-1
$ knife node delete i-XXXXXXXX

(i-XXXXXXXX is the ID of the instance as found in the AWS management console)