- \r\n
- You need at least two servers to follow this tutorial, a server for the control host where you install Ansible, and a server for a remote host that will be controlled by Ansible. If you haven't noticed, we offer extremely affordable VPS plans. Check out our website<\/a> and check out our incredible deals<\/a>!<\/li>\r\n
- Whenever you see the SUBDOMAIN<\/strong>, DOMAIN<\/strong>, or TLD<\/strong> variables, replace them with the details of your domain name. In example.ssdnodes.com<\/strong>, the SUBDOMAIN<\/strong> is example, ssdnodes<\/strong> is the DOMAIN<\/strong> and .com<\/strong> is the TLD<\/strong>. Or you can just use an IP address instead of a domain.<\/li>\r\n<\/ul>\r\n
![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/Ansible-Blog.png\")
<\/p>\r\n\r\n\r\n\r\n\r\nAnsible for Beginners - A Simple Definition<\/h2>\r\n
Ansible<\/a>\u00a0is an open source IT configuration management<\/a>, deployment, and orchestration tool. It empowers DevOps teams to define their infrastructure as a code in a simple and declarative manner. Imagine being able to set up and control 100 servers as easily as you control one server. That's what Ansible does. It's like a remote control for servers. Instead of doing the same tasks over and over on different machines, you write a simple instruction list once, and Ansible automatically follows those instructions on all your servers at once.
A lot of people compare Ansible to similar tools like\u00a0Chef<\/a>\u00a0or\u00a0Puppet<\/a>. They all help automate and provision infrastructure, but there are a few features that make me prefer Ansible over the others.<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n\r\n\r\n\r\nStep 1: Installing Ansible<\/h2>\r\n
To take your first steps with Ansible, you first need to install it on your control machine. This is the machine you\u2019ll use to dispatch tasks. For most people, this will be your desktop machine at home or your laptop, but you can also use one VPS as a control host to connect to other VPSs.<\/p>\r\n
Installing Ansible on Ubuntu 24.04<\/h3>\r\n\r\n\r\n\r\n
You can install Ansible using standard package managers like
apt\/yum<\/code> or Python\u2019spip<\/code> command. To install it using standard package manager in Ubuntu, add its repository informationapt-add-repository<\/code>. Next, update the system and install Ansible usingapt-get<\/code>.<\/p>\r\n\r\n\r\n\r\n$ sudo apt-get install software-properties-common\r\n$ sudo apt-add-repository ppa:ansible\/ansible\r\n$ sudo apt-get update\r\n$ sudo apt-get install ansible\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nInstalling Ansible on AlmaLinux 9<\/h3>\r\n\r\n\r\n\r\n
To install Ansible on AlmaLinux 9, update the package list, then install the\u00a0
ansible-core<\/code>\u00a0package:<\/p>\r\n\r\n\r\n\r\n$ sudo<\/span> dnf update
$ sudo<\/span> dnf install<\/span> ansible-core<\/code><\/pre>\r\n\r\n\r\n\r\n\r\n\r\nStep 2: Understanding Ansible Control Host<\/h2>\r\n
The control host<\/strong><\/a> is the main server on which you've installed Ansible, which you will use to dispatch tasks to the remote managed Ansible hosts.<\/p>\r\n\r\n\r\n\r\n
Before you start delegating tasks to a managed host, make sure you have non-root, a sudo-enabled user on your control host\u2014it\u2019s always a bad idea to connect to a remote VPS via a root user.<\/p>\r\n\r\n\r\n\r\n
Step 3: Ansible Inventory Files<\/h2>\r\n\r\n\r\n\r\n
The Ansible inventory file<\/a> lists which hosts will receive commands from the control host. The inventory can list individual hosts, or group them under categories you distinguish. This file is crucial for defining the managed infrastructure and can include IP addresses or domain names of the hosts. Additionally, you can organize hosts into groups based on various criteria such as their roles, environments (e.g., development, staging, production), or geographic locations.<\/p>\r\n
Ansible Inventory File Location<\/h3>\r\n\r\n\r\n\r\n
The default location for the inventory file is\u00a0
\/etc\/ansible\/hosts<\/code>, but it\u2019s also possible to change the location of the inventory file by uncommenting and modifying the inventory parameter in\u00a0\/etc\/ansible\/ansible.cfg<\/code>. This flexibility allows you to maintain multiple inventory files tailored for different environments or projects. For instance, you might have separate inventory files for development, testing, and production environments. Ansible Inventory files are mostly in the INI and YAML formats.<\/p>\r\n\r\n\r\n\r\nAnsible Inventory File Example<\/h3>\r\n
A typical inventory file sample can list the managed host either by IP address or by domain names. It is also possible to list one managed host in more than one group. Here\u2019s an example of listing two hosts under the
webservers<\/code> anddbservers<\/code> categories.<\/p>\r\n\r\n\r\n\r\n[webservers]\r\n123.45.67.89\r\nSUBDOMAIN.DOMAIN.TLD
[dbservers]
123.45.67.89
SUBDOMAIN.DOMAIN.TLD
<\/code><\/pre>\r\n\r\n\r\n\r\n\r\n\r\nTo test if all the hosts are discoverable by the inventory file, use the following ad-hoc command.<\/p>\r\n\r\n\r\n\r\n
$ ansible all --list-hosts<\/code><\/p>\r\n![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/ansible-all-list-hosts.webp\")
<\/p>\r\nYou can also list the hosts by group name:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
$ ansible dbservers --list-hosts\r\nhosts (2):\r\n 123.45.67.89\r\n SUBDOMAIN.DOMAIN.TLD\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nAd-hoc<\/strong> commands in Ansible are merely those that perform a single command across one or many hosts. They don\u2019t use tasks but allow you to do a lot of things quite easily without building out playbooks (more on those in the second part of this guide).<\/p>\r\n\r\n\r\n\r\n
To find out if all the hosts are up and running, use the following ad-hoc command that uses the
ping<\/code> module of Ansible. The-u<\/code> switch specifies which user Ansible will connect to via SSH\u2014change it according to the non-root user you created earlier.<\/p>\r\n\r\n\r\n\r\n$ ansible all -m ping -u USER\r\n<\/code><\/pre>\r\n\r\n\r\n\r\n![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/ansible-all-m-ping-u-USER.webp\")
<\/p>\r\n<\/p>\r\n
The
\"changed\": false<\/code> in the above JSON result tells us that theping<\/code> Ansible task didn\u2019t change anything on the remote server.
Note:<\/strong> You might get an error saying that your host is unreachable. To solve this, simply create an ssh key pair if you don't already have one on your control host:\u00a0ssh-keygen -t rsa -b 4096<\/code>, then copy it to your remote host:\u00a0ssh-copy-id USER@REMOTE_HOST_IP<\/code>.<\/p>\r\nRather than specifying all the hosts as in the above command, you can also ping a group of hosts. Specify the group name in place of \u2018all\u2019 with the following command:<\/p>\r\n\r\n\r\n\r\n
$ ansible webservers -m ping -u USER\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nStep 4: Ansible Modules<\/h2>\r\n\r\n\r\n\r\n
Modules<\/strong> are the discrete units of code<\/a> that can be used from the terminal or in a playbook task. They simplify Ansible tasks by installing software, copying files, using templates, and so on.<\/p>\r\n\r\n\r\n\r\n
Modules use the available context to determine what actions if any needed to bring the managed host to the desired state and are idempotent, that means if you run the same task again and again, the state of the machine will not change.<\/p>\r\n\r\n\r\n\r\n
To find the list of available modules, use the following command:<\/p>\r\n\r\n\r\n\r\n
$ ansible-doc -l\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nLet\u2019s try to install Nginx on an Ubuntu\/Debian host using an ad-hoc command in Ansible:<\/p>\r\n\r\n\r\n\r\n
$ ansible webservers -b --become-user=root -m shell -a 'apt -y install nginx' -u USER\r\n\r\n172.104.160.8 | SUCCESS | rc=0 >>\r\nReading package lists...\r\nBuilding dependency tree...\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nThe following flags were used with the above command:<\/p>\r\n\r\n\r\n\r\n
- \r\n
-b<\/code>: Instruct ansible to become another user to run the command<\/li>\r\n--become-user=root<\/code>: Run the command as aroot<\/code> user<\/li>\r\n-m<\/code>: Declares which module is used in the command<\/li>\r\n-a<\/code>: Declares which arguments are passed to the module<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\nThe alternate and preferred way of installing software using an ad-hoc command is to use
apt<\/code> module. If your remote managed host is running RHEL\/CentOS, then change the module name fromapt<\/code> toyum<\/code>.<\/p>\r\n\r\n\r\n\r\n$ ansible webservers -b --become-user=root -m apt -a 'name=nginx state=present update_cache=true' -u USER\r\n<\/code><\/pre>\r\n\r\n\r\n\r\n![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/alternate-and-preferred-way.webp\")
<\/p>\r\n<\/p>\r\n
In the above Ansible command, the
-a<\/code> switch passes the arguments to theapt<\/code> module by specifying the name of the package to be installed, the desired state, and whether to update the package repository cache or not.<\/p>\r\n\r\n\r\n\r\nThe line
change: true<\/code> in the result section of the above ad-hoc command signifies that the state of the system has been changed. If you run the above ad-hoc command again, the value ofchanged<\/code> field will befalse<\/code>, which means the state of the system remains unchanged, because Ansible is aware that Nginx is already present in the system and will not try to alter the state again.<\/p>\r\n\r\n\r\n\r\nThat\u2019s what we call Ansible idempotent<\/strong>. You can run the same ad-hoc command as many times as you\u2019d like and it won\u2019t change anything unless it needs to.<\/p>\r\n\r\n\r\n\r\n
172.104.160.8 | SUCCESS => {\r\n \"cache_update_time\": 1530378676,\r\n \"cache_updated\": true,\r\n \"changed\": false\r\n}\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nSo far, we have understood the ansible modules and its usages through ad-hoc way, but this is not so useful until we use the modules in ansible playbooks to run multiple tasks in the remote managed host.<\/p>\r\n\r\n\r\n\r\n
Step 5: Tasks in Ansible<\/h2>\r\n\r\n\r\n\r\n
When you dispatch a job from a control host to a managed host using an Ansible module, it is known as a task<\/strong>. Tasks can be implemented using ad-hoc commands, as we\u2019ve done just above, or you can use an Ansible playbook<\/strong> (more on those in a moment).<\/p>\r\n\r\n\r\n\r\n
One example of a task is copying a file from the control host to a managed host, since it requires the use of \u2018copy\u2019 module. There are thousands of modules in Ansible, which means a task can use any of the modules to bring a managed host to the desired state. How many modules are there by default in Ansible? Let\u2019s see:<\/p>\r\n\r\n\r\n\r\n
$ ansible-doc -l | wc -l\r\n1852\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nIf you haven\u2019t guessed, there are a lot of things you can do when combining Ansible tasks and modules.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
Step 6: Ansible Playbooks<\/h2>\r\n\r\n\r\n\r\n
No Ansible tutorial would be complete without a guide to Playbooks<\/a>. And some concrete Ansible Playbook examples.<\/p>\r\n\r\n\r\n\r\n
Ansible Playbooks<\/strong> are composed of one or more plays and offer more advanced functionality for sending tasks to managed host compared to running many ad-hoc commands.<\/p>\r\n\r\n\r\n\r\n
The tasks in Ansible playbooks are written in Yet Another Markup Language (YAML), which is easier to understand than a JSON or XML file. Each task in the playbook is executed sequentially for each host in the inventory file before moving on to the next task.<\/p>\r\n\r\n\r\n\r\n
Let\u2019s create a simple Ansible playbook example that will install Nginx and a MySQL server on the managed hosts that we had already defined in the inventory file.<\/p>\r\n\r\n\r\n\r\n
To be more precise, we want Nginx installed on hosts in the
webservers<\/code> group and a MySQL server installed on hosts in thedbservers<\/code> group.<\/p>\r\n\r\n\r\n\r\n$ vi playbook.yml\r\n\r\n---\r\n- hosts: webservers\r\n gather_facts: yes\r\n become_user: root\r\n tasks:\r\n - name: Install Nginx\r\n apt: pkg=nginx state=present\r\n notify:\r\n - restart nginx\r\n - name: Enable Nginx during boot\r\n service: name=nginx state=started enabled=yes\r\n handlers:\r\n - name: restart nginx\r\n service: name=nginx state=restarted\r\n\r\n- hosts: dbservers\r\n become_user: root\r\n tasks:\r\n - name: Install mysql\r\n apt: pkg=mysql-server state=present\r\n\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nThe
hosts<\/code> tells Ansible on which hosts to run the tasks. The above Ansible playbook includes two host groups from the inventory file. The tasks forwebservers<\/code> group are to install Nginx<\/em> and enable Nginx during boot<\/em>, and thedbservers<\/code> group includes a single task to install MySQL<\/em>.<\/p>\r\n\r\n\r\n\r\nThe
become_user<\/code> in both the host section tells ansible to usesudo<\/code> to run the tasks.<\/p>\r\n\r\n\r\n\r\nThe
gather_facts<\/code> option gathers information about managed hosts such as distribution, OS family, and more. In ansible terminology, this information is known asFACTS<\/code>.<\/p>\r\n\r\n\r\n\r\nThe
handlers<\/code> section restarts Nginx when Ansible gets notified that Nginx has been installed.<\/p>\r\n\r\n\r\n\r\nA handler is the same as a task, but it will be executed when called by another task. It is like an event-driven system. A handler will run a task only when it is called by an event it listens for.<\/em><\/p>\r\n\r\n\r\n\r\n
Now run the above playbook example using
ansible-playbook<\/code>. Append the name of the user from a remote managed host in the command using-u<\/code> switch.<\/p>\r\n\r\n\r\n\r\n$ ansible-playbook playbook.yml -u USER\r\n<\/code><\/pre>\r\n![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/ansible-playbook.webp\")
<\/p>\r\nThe last line contains information about the current run of the above playbook. The four points of data are:<\/p>\r\n\r\n\r\n\r\n
- \r\n
ok<\/code>: The number of tasks that were either executed correctly or didn\u2019t result in a change.<\/li>\r\nchanged<\/code>: The number of things that were modified by Ansible.<\/li>\r\nunreachable<\/code>: The number of hosts that were unreachable for some reason.<\/li>\r\nfailed<\/code>: The number of tasks failed to execute correctly.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\nStep 7: Ansible Roles<\/h2>\r\n\r\n\r\n\r\n
In Ansible, a role<\/strong> provides a mechanism to break a complicated playbook into multiple reusable components. Each component offers a small function that can be used independently within the playbook. So rather than creating one complex playbook, you can create many roles and simply drop them into your playbooks.<\/p>\r\n\r\n\r\n\r\n
You can\u2019t execute roles directly, the way you do a playbook, and you can\u2019t specify which host you want to execute a role, the way you would an ad-hoc command. Instead, they\u2019re built into the playbooks you use to define a host.<\/p>\r\n\r\n\r\n\r\n
The Ansible Galaxy<\/a> repository has thousands of pre-built roles for you to choose from, although you\u2019re free to create your role framework. Let\u2019s dig into how you might want to do just that.<\/p>\r\n\r\n\r\n\r\n
Step 8: Ansible Variables<\/h2>\r\n\r\n\r\n\r\n
In Ansible, variables<\/strong> are similar to variables in any programming language\u2014they let you input values and numbers dynamically into your playbook. Variables simplify operations by allowing you define and declare them throughout all the various roles and tasks you want to perform.<\/p>\r\n\r\n\r\n\r\n
There are few places where you can define variables in an Ansible playbook.<\/p>\r\n\r\n\r\n\r\n
- \r\n
- In the playbook<\/li>\r\n
- In the inventory file<\/li>\r\n
- In a separate variable file<\/li>\r\n
- Using
group_vars<\/code><\/li>\r\n<\/ul>\r\n\r\n\r\n\r\nTo define variables in a playbook, use
vars<\/code> key just above the task where you want to use the variable. Once declared, you can use it inside the{{ }}<\/code> tag. Let\u2019s declare a variable by the namepkgname<\/code> and assign it the value of the package name that we want to install, which isnginx<\/code>. Once done, we can use the variable in a task.<\/p>\r\n\r\n\r\n\r\n---\r\n- hosts: webservers\r\n gather_facts: yes\r\n become_user: root\r\n\r\n vars:\r\n pkgname: nginx\r\n\r\n tasks:\r\n - name: Install \"{{ pkgname }}\"\r\n apt: pkg=\"{{ pkgname }}\" state=present\r\n ...\r\n ...\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nIt is also possible to declare a variable in the inventory file using the syntax
[host_group_name:vars]<\/code>. Let\u2019s define the variablepkgname<\/code> in the inventory file.<\/p>\r\n\r\n\r\n\r\n[webservers:vars]\r\npkgname=nginx\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nNow the variable
pkgname<\/code> can be used anywhere in thewebservers<\/code> hosts section in the playbook.<\/p>\r\n\r\n\r\n\r\nYou can also define variables in a separate variable file and import it into the playbook. Create a variable file using
vi<\/code> another text editor and define the variablepkgname<\/code> here.<\/p>\r\n\r\n\r\n\r\n$ vi ansible_vars.yml\r\n\r\n---\r\npkgname: nginx\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nTo use the variable
pkgname<\/code>, import the above file using thevars_files<\/code> keyword in the playbook.<\/p>\r\n\r\n\r\n\r\n$ vi playbook.yml\r\n\r\n---\r\n- hosts: webservers\r\n gather_facts: yes\r\n become_user: root\r\n\r\n vars_files:\r\n - .\/ansible_vars.yml\r\n...\r\n...\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nAnother preferred way of managing variables is to create a
group_vars<\/code> directory inside your Ansible working directory. Ansible will load any YAML files in this directory with the name of any Ansible group.<\/p>\r\n\r\n\r\n\r\nCreate the directory
group_vars<\/code> in your Ansible working directory, and then create the variable files matching with the group name from the inventory file. In our example, this would bewebservers<\/code> anddbservers<\/code>. This allows you to separate variables according to host groups, which can make everything easier to manage.<\/p>\r\n\r\n\r\n\r\n$ cd <your_ansible_working_directory>\r\n$ mkdir group_vars\r\n$ cd group_vars\r\n$ vi webservers\r\n<\/code><\/pre>\r\n\r\n\r\n\r\n![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/can-make-everything-easier-to-manage.webp\")
You don\u2019t need to declare the variable in your playbook, as Ansible will automatically pull the variables from eachgroup_vars<\/code> files and will substitute them during runtime.<\/p>\r\n\r\n\r\n\r\nNow suppose you want to have variables that will apply to all the host groups mentioned in the inventory file. To accomplish it, name a file by the name
all<\/code> insidegroup_vars<\/code> directory. Thegroup_vars\/all<\/code> files are used to set variables for every host that Ansible connects to.<\/p>\r\n\r\n\r\n\r\nStep 9: Ansible Conditionals<\/h2>\r\n\r\n\r\n\r\n
In Ansible, conditionals<\/a> are analogous to an if statement in any programming language. You use a conditional when you want to execute a task based on certain conditions. For example, if you only want to install a package on a remote server if it is not already installed, you would use a conditional to check the package's status before proceeding with the installation task.<\/p>\r\n
Ansible Conditionals Example<\/h3>\r\n\r\n\r\n\r\n
In our last playbook example, we installed Nginx, so let\u2019s extend that by creating a task that installs Nginx when Apache is not<\/em> present on the host. We can add another task to the playbook we\u2019ve already built.<\/p>\r\n\r\n\r\n\r\n
...\r\n...\r\n tasks:\r\n - name: Check if Apache is already installed\r\n shell: dpkg -s apache2 | grep Status\r\n register: apache2_is_installed \r\n failed_when: no\r\n - name: Install \"{{ pkgname }}\"\r\n apt: pkg=\"{{ pkgname }}\" state=present\r\n when: apache2_is_installed.rc == 1\r\n notify:\r\n - restart nginx\r\n...\r\n...\r\n<\/code><\/pre>\r\n\r\n\r\n\r\nThe first task in the above playbook checks if Apache is installed using
dpkg -s<\/code> command and stores the output of the task toapache2_is_installed<\/code> variable. The return value of the task will be a non-zero value if Apache is not<\/em> installed on the host.<\/p>\r\n\r\n\r\n\r\nUsually, Ansible would stop executing other tasks because of this non-zero value, but the
failed_when: no<\/code> gives Ansible permission to continue with the next set of tasks when it encounters a non-zero value.<\/p>\r\n\r\n\r\n\r\nThe second task will install Nginx only when the return value of
rc<\/code> is equal to one, which is declared viawhen: apache2_is_installed.rc == 1<\/code>.<\/p>\r\n\r\n\r\n\r\nStep 10: Ansible Loops<\/h2>\r\n\r\n\r\n\r\n
- Whenever you see the SUBDOMAIN<\/strong>, DOMAIN<\/strong>, or TLD<\/strong> variables, replace them with the details of your domain name. In example.ssdnodes.com<\/strong>, the SUBDOMAIN<\/strong> is example, ssdnodes<\/strong> is the DOMAIN<\/strong> and .com<\/strong> is the TLD<\/strong>. Or you can just use an IP address instead of a domain.<\/li>\r\n<\/ul>\r\n
![\"Ansible](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2018\/08\/Ansible-Templates.webp\")
<\/p>\r\n\r\n\r\n\r\n