Automation orchestration / Configuration Management Tool comparison

Note:

This comparison is used to recommend our State Government Client with the requirements they have, This comparison or conclusions may change depends on client requirements and needs

 

Cloud Plotform: Microsoft Azure

Continuous Integration and Continuous Delivery: Microsoft Azure DevOps

Automation tools considered for the review: : Chef, Puppet, Ansible, and Saltstack

Chef, Puppet, Ansible, and Saltstack are industry-wide used DevOps tools, included in DevOps Certification They are all “configuration management” tools, which means they are designed to deploy, configure and manage servers. This Document Details the pros and cons of each of these Following tools.
Quick Look at the overview of metrics on which we will be comparing the tools.

 

Metrics	Chef	Puppet	Ansible	Saltstack
Open Source	✔	✔	✔	✔
Ease of Setup	Not very easy	Not very easy	Easy	Easy
Tool Management	Not very easy	Not very easy	Easy	Not very easy
Scalability	Highly Scalable	Highly Scalable	Highly Scalable	Highly Scalable
Language	DSL( Ruby )	YAML,DSL(PuppetDSL)	YAML (Python)	YAML (Python)
Agent / Agent Less	Agent	Agent	Agent Less	Both Agent and Agent Less

 

Chef Architecture 

 

Chef Has very well scalable and high available  and secured Architecture. Chef Infra is a powerful automation platform that transforms infrastructure into code. Whether you’re operating in the cloud, on-premises, or in a hybrid environment, Chef Infra automates how infrastructure is configured, deployed, and managed across your network, no matter its size.

 

Component of Chef

Work station: One (or more) workstations are configured to allow users to author, test, and maintain cookbooks. Cookbooks are uploaded to the Chef Infra Server from the workstation. Some cookbooks are custom to the organization and others are based on community cookbooks available from the Chef Supermarket.

Cook Books: Ruby is the programming language that is the authoring syntax for cookbooks. Most recipes are simple patterns (blocks that define properties and values that map to specific configuration items like packages, files, services, templates, and users). The full power of Ruby is available for when you need a programming language.

Node: A node is any machine—physical, virtual, cloud, network device, etc.—that is under management by Chef.

Chef Client: A Chef Infra Client is installed on each node that is under management by Chef. The Chef Infra Client performs all of the configuration tasks that are specified by the run-list and will pull down any required configuration data from the Chef Infra Server as it is needed during a Chef Infra Client run.

Chef Server: The Chef Infra Server acts as a hub of information. Cookbooks and policy settings are uploaded to the Chef Infra Server by users from workstations. (Policy settings may also be maintained from the Chef Infra Server itself, via the Chef management console web user interface.)

Chef Super Market: Chef Supermarket is the location in which community cookbooks are shared and managed. Cookbooks that are part of the Chef Supermarket may be used by any Chef user. How community cookbooks are used varies from organization to organization.

 

 

Puppet Architecture

 

Puppet is also very Scalable and highly available with redundancy in every component.Puppet provides the ability to define which software and configuration a system requires and then maintain a specified state after an initial setup.

 

 

 

Component of Chef

 

• Puppet master – Puppet master runs on the server and manages all the nodes.
• Puppet Agent – Puppet agent runs on the client. they are the target machines here.
• Config repository – This is where all the server related configurations and nodes are stored.
• Facts – They are global variables obtaining important machine level information.
• Catalog – All configurations that are written in puppet are converted to a compiled format called catalog.
• Manifests – these are files that need to be checked and changed.
• Class – Like other programming languages, even puppet has classes to organize its code better.
• Resources – In puppet codes, the coding block that is defined by declaring resources where resources may represent packages, files, users, commands.
• Nodes – All servers or clients that need to be managed are called nodes.​​
• CA – Certificate Authority Client server Certification for communication between client and server,
• Puppet DB – Puppet Database for all client and Puppet master info and configuration

 

Ansible Architecture

 

Ansible is an open source automation platform. It is very, Very simple to install and configure and yet powerful. Ansible can help you with configuration management, application deployment, task automation. It can also do IT orchestration over cloud.

 

 

 

 

Ansible Components

 

• Ansible Management Server: Node which has access to all the server in your infrastructure which can ssh to your server and do the configuration management or execute a task/job.
• Server/Receiving server: Server that receive updates from management server ( basically the work load servers – DB’s, App server etc )
• Play Books: Logic or code to apply configuration or do orchestration 
  • Modules:  Ansible works by connecting to your nodes and pushing out scripts called “Ansible modules” to them. Most modules accept parameters that describe the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required.
  • Plugins: Plugins augment Ansible’s core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the /usr/bin/ansible process.
  • Playbook: Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible  starts to get most interesting.
• Inventory: By default, Ansible represents the machines it manages in a file (INI, YAML, etc.) that puts all of your managed machines in groups of your own choosing.To add new machines, there is no additional SSL signing server involved, so there’s never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.If there’s another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.

 

Salt Stack Architecture

 

 

 

• SaltMaster − SaltMaster is the master daemon. A SaltMaster is used to send commands and configurations to the Salt slaves. A single master can manage multiple masters.
• SaltMinions − SaltMinion is the slave daemon. A Salt minion receives commands and configuration from the SaltMaster.
• Execution − Modules and Adhoc commands executed from the command line against one or more minions. It performs Real-time Monitoring.
• Formulas − Formulas are pre-written Salt States. They are as open-ended as Salt States themselves and can be used for tasks such as installing a package, configuring and starting a service, setting up users or permissions and many other common tasks.
• Grains − Grains is an interface that provides information specific to a minion. The information available through the grains interface is static. Grains get loaded when the Salt minion starts. This means that the information in grains is unchanging. Therefore, grains information could be about the running kernel or the operating system. It is case insensitive.
• Pillar − A pillar is an interface that generates and stores highly sensitive data specific to a particular minion, such as cryptographic keys and passwords. It stores data in a key/value pair and the data is managed in a similar way as the Salt State Tree.
• Top File − Matches Salt states and pillar data to Salt minions.
• Runners − It is a module located inside the SaltMaster and performs tasks such as job status, connection status, read data from external APIs, query connected salt minions and more.
• Returners − Returns data from Salt minions to another system.
• Reactor − It is responsible for triggering reactions when events occur in your SaltStack environment.
• SaltCloud − Salt Cloud provides a powerful interface to interact with cloud hosts.
• SaltSSH − Run Salt commands over SSH on systems without using Salt minion.

 

 

What we choose for our Client Automation

 

With all the requirements from our client and the applications that runs on Azure  and on premise We choose to go with up Ansible.

 

Driving Factors for the Ansible

• Quick Setup
• Less dependancies
• Scalable
• Open source
• works very will with Microsoft DSC
• Less expensive to setup and maintain
• No agents
• Great Community support and module availability
• Very good Module support for Azure.
• Azure DevOps Support