The shift from Chef to Red Hat Ansible Automation Platform has become a strategic choice for many organizations seeking simplicity, scalability and ease of use for configuration management and automation tools. This article explores the process of converting Chef cookbooks into Ansible Playbooks, providing insights and guidance for a smooth and efficient transition.

Understanding the differences

Chef and Ansible Automation Platform, while both prominent tools share the common goal of automating infrastructure tasks, they differ in their approaches to configuration management and exhibit distinctive features in terms of syntax, architecture and operational methodologies. Let's explore the key differentiators between these two remarkable technologies.

• Configuration Language: Chef utilizes a domain-specific language (DSL), which requires users to be familiar with Ruby scripting for defining configurations. The Chef DSL consists of resources, recipes, and attributes, providing a flexible but code-intensive approach.
  In contrast, Ansible Automation Platform relies on a YAML-based syntax, which is known to be a simple and easy-to-understand human-readable format.
• Agent Vs. Agentless: Chef follows a client-server architecture where a Chef client, installed on each managed node, communicates with a central Chef server. This requires the installation of the Chef client on each managed machine.
  Ansible Automation Platform, on the other hand, operates in an agentless manner over SSH. It does not require the installation of agents on managed nodes, reducing the overhead associated with agent-based systems.

• Execution model: Chef operates with a procedural execution model where recipes define the order in which tasks are executed on nodes. It uses resources and providers to manage configurations and dependencies.
  Ansible Automation Platform adopts a declarative approach, specifying the desired state of the system rather than the sequence of steps to reach that state. Ansible Playbooks define the desired configuration, and Ansible Automation Platform handles the execution details. The following example showcases the procedural nature of Chef where the action to be performed is explicit whereas the Ansible Automation Platform equivalent simply expresses the desired state.

# Install Nginx (Chef)
package 'nginx' do
  action :install
end

 # Install Nginx (Ansible)
  - name: Install Nginx
    yum:
      name: nginx
      state: present

• Ease of adoption: Learning and mastering the Ruby language is a prerequisite for effectively using Chef. While powerful, this can be a barrier for those unfamiliar with Ruby.
  Ansible Automation Platform's YAML syntax is straightforward and requires a minimal learning curve. Its simplicity contributes to a lower entry barrier, making it accessible to a broader audience with varying skill sets.

Chef and Ansible Automation Platform terminology

Let's closely examine and dissect the terminology employed in Chef and Ansible Automation Platform, shedding light on both their nuanced disparities and shared foundational concepts.

In the realm of shared concepts, both Chef and Ansible Automation Platform utilize the term "node" which signifies a system under Chef's (or Ansible Automation Platform’s) management. They both use the concept of a "role" as a means to encapsulate patterns and processes across managed nodes. In Chef, a role defines a set of attributes and a run list, specifying what should be applied to a node when it assumes that particular role. Similarly in Ansible Automation Platform, a role is a collection of tasks, handlers, templates and other elements organized in a predefined directory structure. Roles promote reusability and consistency in configuring different servers. Additionally, they both use the concept of "attribute" also termed as "variable" or reusable values which is a means to customize configurations.

Chef introduces a distinctive set of tool-specific terms. A "cookbook" serves as a fundamental unit, encapsulating recipes, attributes and resources. A "recipe" is akin to a script, detailing the actions Chef should perform on a given node and composed of resources, which represent building blocks specifying the desired state of a specific system aspect. A “Data Bag” is a centralized container for data that is not tied to a single node and is shared by all nodes.

On the Ansible Automation Platform front, the terminology reflects its unique approach and design philosophy. A "playbook" stands out as a YAML file that defines a set of tasks and configurations to be executed on remote hosts (the equivalent of cookbook in Chef). A "task" serves as the fundamental unit of work within an Ansible Playbook, representing a specific configuration action to be performed on a remote host. "Inventory" is a file or script that enumerates the hosts or nodes to be managed by Ansible Automation Platform. "Module" refers to a standalone, reusable piece of code that encapsulates specific tasks, enhancing modularity and reusability (the equivalent of resource in Chef). "Collections" are a way to organize, package and distribute Ansible content, including playbooks, roles, modules and plugins. "Facts" denote system information automatically gathered by Ansible Automation Platform from remote hosts, serving as variables in playbooks. Lastly, a "handler" in Ansible Automation Platform is a task triggered by other tasks, typically used for actions like restarting services.

Folder structure

In Chef, the folder structure revolves around the concept of cookbooks. Each cookbook resides within a dedicated directory, containing subdirectories like "recipes," "attributes," and "files" to organize various components. This modular structure aligns with Chef's procedural execution model, where recipes dictate the order of tasks. On the other hand, Ansible Automation Platform, following a declarative execution model, adopts a flatter and more straightforward folder structure. Playbooks, written in YAML, are at the core, residing alongside additional directories like "roles" for organizing reusable components with subdirectories for tasks, handlers, defaults, and templates.

In the subsequent table, we illuminate the key files and directories commonly encountered in a Chef folder structure, juxtaposed with their counterparts in Ansible Automation Platform.

Now let’s compare some of the main Chef files and folders side by side with their closest equivalents in Ansible Automation Platform, while explaining the nuances and differences.

Migration stages

Migrating from Chef to Ansible Automation Platform involves a strategic transition plan that typically unfolds in distinct phases to ensure a smooth and efficient process.

Planning phase

The primary objective of the planning phase is to gain a comprehensive understanding of the existing Chef infrastructure. This involves identifying the roles, recipes and attributes currently in use within the Chef environment. Clearly identify the key components within Chef that play a crucial role in defining and managing the infrastructure. These components may include custom roles created for specific server types, recipes outlining application deployment steps, and attributes specifying configuration parameters. We can then determine how each identified component in Chef can be translated into Ansible Automation Platform equivalents. Roles in Chef may correspond to roles or even collections in Ansible Automation Platform, recipes may become tasks in Ansible Playbooks and Chef attributes might be replaced with Ansible variables.

Finally identify any potential challenges or risks associated with the migration process. This may include dependencies between roles or specific configurations that require careful consideration.

Translation phase

In this step, the focus is on the conversion of Chef recipes into Ansible Playbooks. A Chef recipe, which defines the tasks to be executed on a node, is now translated into Ansible's equivalent structure using YAML syntax.

Translate each task defined in a Chef recipe into the equivalent task in Ansible Automation Platform. Pay attention to the sequence, parameters, and dependencies of each task. Consider the use of handlers if event handling is being used in the Chef recipes that you are translating. Handlers are typically employed to respond to specific events. In Ansible Automation Platform, handlers serve a similar purpose.

Convert Attributes to Ansible Variables

In Chef, attributes are used to define configuration settings. These attributes store information about the current state and configuration of nodes. They play a crucial role in customizing the behavior of recipes and, by extension, the overall infrastructure. As part of the migration process, Chef attributes need to be translated into Ansible variables. Ansible variables serve a similar purpose—they allow the dynamic definition of values that can be used across playbooks.

A classical pattern found in Chef projects is the reliance on a central data location called data bag. It acts as a global repository for sensitive information, configuration settings, or any data needed during the configuration process. How does one manage the equivalent of Chef data bags in Ansible Automation Platform?

When transitioning from Chef to Ansible Automation Platform, careful consideration is required when dealing with data bags. Ansible Automation Platform lacks a direct equivalent to the centralized server-based data bag concept in Chef due to its decentralized and agentless architecture. Consequently, translating data bags to Ansible Automation Platform involves distributing their content across multiple locations. Sensitive information may be stored in encrypted files or managed using Ansible vault for security. Configuration settings and other data can be dispersed throughout playbooks, roles or inventory files. The key lies in analyzing the specific contents of the data bag and strategically placing the information within the Ansible Automation Platform structure, enabling a seamless transition while adhering to Ansible Automation Platform's decentralized nature.

In Ansible Automation Platform, variable files provide a structured way to organize and manage variables across playbooks and roles. Several types of variable files serve different purposes within the Ansible Automation Platform framework. Firstly, there are "host_vars" and "group_vars" directories at the inventory level, allowing the assignment of variables to specific hosts or groups of hosts respectively. These variables are then accessible during playbook execution. At the playbook level, "vars_files" can be specified to include external YAML files containing variables. Roles, which encapsulate reusable components, can have their own set of variables stored in the "vars" directory. Additionally, "defaults" in the role structure can house default variable values. Lastly, Ansible vault provides a secure way to manage sensitive information by encrypting variable files. This rich ecosystem of variable files in Ansible facilitates a modular and organized approach to configuration, enabling efficient management of variables at different levels of the playbook and role hierarchy.

If the need arises to centralize data for accessibility across various independent playbooks and multiple runs, a recommended approach is to establish a dedicated data repository. This repository can house your data in either YAML or JSON files. By pushing this repository to an accessible location such as Git or its equivalent, you not only allow a centralized and version-controlled storage of data but also facilitate seamless sharing and retrieval across different playbooks. Additionally, leveraging the Ansible Git module allows for automated retrieval and synchronization of data, further streamlining your workflow and enhancing collaboration.

A complementary method to employing the Ansible Git module for retrieving common data from a Git repository is to create a dedicated Ansible Role. This role would be responsible for fetching the required data from Git and injecting it as facts, readily available for consumption by your playbook. This approach encapsulates the logic within a reusable and modular component, promoting better organization and maintainability of your Ansible infrastructure.

Leverage Ansible Modules

Ansible Automation Platform's strength lies in its extensive library of modules that abstract complex tasks into simple, reusable components. Identify Chef resources and actions and replace them with corresponding Ansible modules. Thanks to Ansible's extensive module ecosystem, it's rare not to find a suitable replacement for a Chef resource. However, in exceptional cases where a direct equivalent isn't available, Ansible Automation Platform offers the flexibility to develop custom modules using Python programming language.

A common pattern found in Chef cookbooks is the extensive use of Ruby code. Injecting Ruby code in Chef cookbooks is very tempting and powerful at the same time but leads to a complicated logic and hard to understand automation scripts. When converting to Ansible Automation Platform,  you may also be tempted to simply translate the Ruby code into Python or even shell scripts and then call these from your playbook. This is generally a bad idea and the best practice is to look for an Ansible module that does what you want. Ansible modules are idempotent and regularly maintained and updated. If you code your own script or module, the responsibility of assuring idempotency and maintenance falls on you.

Test and optimize

Thorough testing is crucial to validate the functionality and integrity of your converted playbooks. Create a staging environment that mirrors your production setup and run comprehensive tests to identify and resolve any issues. This iterative testing process offers a seamless transition when deploying to production. Ansible Automation Platform has an ecosystem ranging from static syntax checking and linting such as Ansible lint to testing the execution of playbooks, roles and collections such as Ansible Molecule which provisions virtualized test hosts.

Closing thoughts

Chef and Ansible Automation Platform are both great automation tools helping companies to configure and maintain large infrastructures. In this article we shed some light on the journey of converting a Chef automation environment to its Ansible Automation Platform equivalent by highlighting commonalities and differences between the two systems.