Today’s companies routinely leverage IT products to conduct their business. Many of them empower their IT departments to maintain the computing environments as well as the software and services that are used throughout the company. As virtualization and cloud technologies continue to grow, automating the deployment and environment setup has become even more challenging and important.
There is a wide variety of software products that need to be treated differently for production, development, testing, and other environments. The migration of the entire infrastructure from one cloud provider to another often requires a lot of work. This is because there are many complex tasks related to the migration of a whole infrastructure. In addition, the increased load placed on these products requires an expansion in the number of service instances that are managed by the same load balancer.
Fortunately, several solutions are available to DevOps engineers who face these demanding issues.
Puppet scripts, Chef and Ansible have emerged as popular product examples that decrease the time required for changes in the middleware infrastructure as well as complete migrations.
All of these products are based on the same premise: represent the state of the deployed system and define how to maintain this state under different conditions. The circumstance is described in a particular DSL language, which is extended by support of templates, expressions/flow operators, external configurations and integration with third-party tools.
By using these solutions, the engineer no longer needs to be concerned about correctly adjusting the system to the desired state. Now the focus is only on what’s needed to be seen in the deployed system. So all of the implementation is done out of the box by the automated framework. This makes the automation software more readable and the ongoing maintenance much less error prone.
Let’s consider some of these solutions in greater detail:
Puppet Scripts
The Puppet solution uses its own DSL (similar to YAML) for declaring resources, classes and nodes in manifest files.
Resources are referenced by names and a set of attributes is provided for every resource. In addition, multiple resources remain enclosed by classes. For clarification, resources represent files, users, services and other system parts.
In turn, classes are used to describe nodes. The order of applying resources in this way can be defined by utilizing a before/declare and subscribe/notify relationship between them. Classes can then be parametrized/tagged with the use of tags and run stages. Finally, the node manifest contains a list of node definitions (names and lists of classes). It’s important to note that environments can be assigned to nodes by names.
Puppet supports inheritance for classes and attribute sets, regular expressions and multiple data types, including enum, struct, hash, array, tuple, variant and callable. Structural language operations are also integrated in this solution, which features if/else, loops, lambda functions, chained functions and iterations.
Another crucial detail is that Puppet uses EPP (Puppet language-based) and ERB (Ruby-based) templates to define the content of external files. Facts (variables related to nodes and servers states) are then collected from configured nodes and accessed in the form of variables.
Where operation is concerned, Puppet can function well in agent/master and in standalone architectures. Also, Puppet agents that send reports and node metadata run actions and metrics to puppet master servers in non-standalone mode. These Puppet servers provide HTTP API by using PSON and YAML data format.
Chef
Unlike Puppet, Chef defines resources as a set of recipes within cookbooks. It uses Ruby-style declarations for resources and also supports Ruby language inside its recipes. Each recipe contains a resource name and its attributes. Roles and environments are defined in separate folders. Additionally, facts are established in ‘node’ variables as hash. Recipes can be combined into run-lists that merge together in the same bundle.
Chef uses scaffolding to generate cookbooks and recipes from the command line. For file content generation, ERB templates are generally used to fulfill this role. To set up Chef, a server can be positioned either in a local environment or in the software’s cloud.
Chef supports both client/server and standalone (chef-apply) modes. It includes a special local environment (Test Kitchen) for quickly deploying/testing changes without impacting live services. However, you might consider initially verifying their functionality before final integration.
In terms of unit tests, Chef is compatible with InSpec and ChefSpec, which are similar to RSpec in the Ruby language. Unit tests allow you to prepare a separate context for different OSes/versions. RubiCop and Foodcritic can be used for static code analysis and better pattern usage in Chef Recipes.
Chef provides a unique feature called Chef Compliance that checks the PCI, HIPPA and other requirements in real-time iteratively. It also has dashboard and reporting modules. An automatic test-and-prepare approach during a Chef compliance check is applied before the integration of any changes.
The Chef Analytics component permits you to track and alert the events in certain instances such as when cookbooks are updated, stop working, nodes are added/removed or at the moment compliance fails among other actions. The Chef delivery component automates this distribution pipeline by supporting different environments and integration with Git.
Ansible
Ansible defines resources as tasks and handlers in playbooks. It uses a simple text / Yaml to provide configurations. The Jinja2 system is utilized for templates. Playbooks can be included as modules to other playbooks and facilitate how variables are passed between them. Roles allow you to include tasks, handlers and even additional versions of this tool. Also, roles can be parametrised for more convenience.
Ansible DSL supports loops over file content, lists, sequences, hashes and more. Jinja2 filters are used for transforming expressions. Conditional statements and blocks are also key aspects of this program. Blocks can be employed for logical grouping and error handling. Plus, data is able to be looked up in external files using plugins. Another convenient feature is the Ansible Vault, which is a component designed to work with encrypted files.
For operational purposes, it is possible to run the playbook in check mode before making actual changes. Several modules can be used for tests, including “assert-that,” “fail-when” and “wait-for.”
In addition, it’s possible to make tasks asynchronous with polling ability. They may also be executed by batches and run once. Depending on your strategy, you can structure tasks as sequential and parallel. To repair the playbooks, a debugging approach is usually selected.
Ansible uses agentless architecture that installs modules from system packages/Git and then communicates over SSH. The Ansible Tower is utilized as an automation engine and the analytics can be chosen as an alternative to command line tools.
What is the Best Solution to Automate Your DevOps?
All of these solutions provide similar features that can automate your deployment and system setup. However, there are often additional factors that you should keep in mind to help you select the best solution.
Chef contains the most complete set of components and tools inside of itself and it is able to automate all of the DevOps processes, which include the automation of tests, compliance check and reporting/analytics delivery. This choice is also convenient for those who know the Ruby language. That’s because it allows you to avoid going down the learning curve with its DSL.
Chef’s site contains easy to understand documentation with examples. You can even find samples of output that demonstrate how it can work as if run with a real server. One of the most appealing features is that many of the cookbooks can be reused from Chef Supermarket without having to write down the popular tasks.
Chef allows you to implement complex setups quite easily. For example, the dynamic load balancer automatically includes all configuration nodes of specified types while Puppet and Ansible are unable to resolve this issue as easily. These benefits illustrate the power of integrated Ruby support in Chef.
Experts often recommend using Chef when a complete automation and thorough compliance check are required for the system. Since DevOps engineers already have extensive knowledge of Ruby, complex non-standard automation tasks are necessary to enhance its use.
For those who prefer a more straightforward approach, Ansible is the simplest solution and it can be chosen when the automation needs to be provided in a short period of time. It’s also helpful to use when your company doesn’t want to integrate too many new tools and technologies into its infrastructure.
Despite its simplicity, Ansible contains a nice monitoring and management Dashboard, which includes analytic support that is easily integrated with other tools and services. Ansible Galaxy provides a lot of Roles and Templates from the Ansible Community. For small to medium size infrastructures, Ansible could be a good choice because it only requires a minimal learning curve.
Puppet is somewhere between the Ansible and Chef spectrum. It has excellent support and a lot of documentation with learning resources. Puppet allows you to build a set of system components, which can be reused later for different solutions with other consumers of your automation team.
In addition, Puppet’s API allows you to integrate the management of your infrastructure to other products. If you already have a well configured automation environment, then you can easily empower it with Puppet modules due its ease of integration with other tools.
Conclusion
In short, all three software programs have prominent advantages. To choose the best one for your particular circumstances, it’s best to examine which tool suits your individual needs. Our Sphere team has helped a wide range of clients by recommending customized solutions.
