Many people wonder how to implement Infrastructure as Code with Ansible. In this article, we covered how to implement Infrastructure as Code with Ansible.
What Is Infrastructure as Code?
To simplify the approach, consider your infrastructure as a picture (end-state) and the primary features (configuration) that would be used to define it.
You should be able to duplicate the image at any time using this information, and the outcome should always be identical to the original.
There are several tools and ways for implementing this strategy, but the critical point to remember is that you must also modify your management processes to transition from the classic imperative model to the infrastructure as code declarative one.
What Is Ansible? How to Implement Infrastructure as Code with Ansible
In a nutshell, Ansible is a program that enables you to automate processes in order to attain the desired state in a system. A job may be as basic as specifying a package to be installed, stating web server settings, or even putting up a complete deployment orchestration.
Install Ansible
There are several methods to install Ansible, but the ideal option is via your Linux distribution package manager. For instance, to install it on RHEL or CentOS, just run the following command:
$ sudo yum install ansibleThe program will download and install Ansible, as well as any required dependencies.
Additionally, you may run Ansible from its source code or install it via pip (the Python package manager).
Basic Concepts & Terms
Host: A remote Ansible-managed system
Group: Multiple hosts that share a characteristic are grouped together as a group.
Inventory: Ansible’s inventory is a list of all the hosts and groups it controls. This might be a static file in basic circumstances, or we could get the inventory from external sources, such as cloud providers.
Modules: Code units that Ansible distributes to distant nodes for execution.
Tasks: Action units composed of a module and its arguments, as well as certain additional parameters.
Playbook: Hierarchical array of tasks and their associated parameters that provide a blueprint for configuring a system.
Roles: Re-usable organizational units that enable users to collaborate more easily on automation code.
YAML: A widely used and straightforward data format that is very clean and human-readable.
Push mode is the most often used mode of Ansible. In push mode, Ansible connects to each host in the inventory file and executes all the plays described in the playbook, doing tasks on hosts that are involved in a given play.
There is no need for the target hosts to have an agent or any other software running. Ansible will establish a connection to them over SSH, but this is not the only method.
Ansible tasks are intended to be idempotent, which means that they may be executed again without resulting in new modifications. This implies that you may re-run Ansible playbooks as you refine and expand your automation. If any tasks fail, you can re-run the whole playbook.
This is an example of a basic Ansible inventory file:
192.168.1.23
[db]
10.2.14.23
[webservers]
server1.domain.com
server2.domain.orgAs you can see, it is nothing more than a collection of IP addresses and fully qualified domain names. It may, however, incorporate ranges or custom scripts to get all hosts on which the playbooks will be performed. Additionally, the text shown in squares assists in defining a group of hosts. When a group is specified in the playbook, Ansible will connect to just the hosts included inside it.
This is a playbook example from Ansible documentation:
---
- hosts: webservers
remote_user: yourname
tasks:
- service:
name: nginx
state: started
become: yes
become_method: sudoThe playbook instructs Ansible to use the supplied user to connect to each host in the group webservers. Following that, it will execute sudo to get the necessary rights to verify that the Nginx service is running. If not, the tasks will initiate it. Nothing will be performed if the service is already running.
As shown before, the playbook is a YAML file. It’s quite simple to read, which means that any member of your team will understand what’s going on with the tasks being completed.
We now have a playbook and an inventory. All that remains is to run Ansible. This is the procedure:
$ ansible-playbook playbook.yml
Following execution, all hosts in the webservers group will automatically have the nginx service running.
The Last Step
We are not finished yet! Now that you understand how playbooks function, we need to ensure that they are accessible to everyone on your team, as well as updated and executed again as needed. Due to the fact that all Ansible configurations are saved as unencrypted files, they may simply be added to source control management.
Configurations may then be enhanced, changed, or audited. There will be no need to log into each host to verify or evaluate the setup. However, if this occurs for whatever reason, all you need to do is re-execute Ansible.
At this point, I trust you understand the value of automation and how it may assist you in optimizing your application development and deployment processes. Now is the time to get started. Have some fun!
You may also be interested in:
