Introduction
What is Ansible?
Ansible is an automation language that can describe any IT environment, whether home-lab or large-scale infrastructure. It is easy to learn, beautiful code that reads like clear documentation.
There are many repetitive tasks that we may perform on a server, a VM, or a VPS. The tasks can range from setting up SSH keys to disabling the root user to firewall configs. If you manage multiple servers daily and you have to do the same configuration over and over, Ansible can automate the process, allowing you to increase your productivity.
It requires installing Ansible on the Control Node and just having Python 3 installed on the Managed Node.
What is the Control Node?
It's simply the system that Ansible is installed on that controls the remote machines.
What is the Managed Node?
A remote system, or host, that Ansible controls. Ansible is agent-less, so you don’t need to install Ansible on the managed node; you simply need Python 3 to be installed.
Install Ansible on Ubuntu (Control Node—local machine. Running ZorinOS).
your-command-prompt:~$ sudo apt update
your-command-prompt:~$ sudo apt install software-properties-common
your-command-prompt:~$ sudo add-apt-repository --yes --update ppa:ansible/ansible
your-command-prompt:~$ sudo apt install ansible
Note: Ensure that Python 3 is installed on your remote server. At this time of writing, Ubuntu 26.04 LTS has Python 3.14.4 installed by default. This is enough to get your remote server running with Ansible.
Create an inventory folder with a host file.
This file contains a list of the remote machines, VMs, or VPSs that you want to control using Ansible.
For this step you can use a code editor; I will be using Vs Code.
Create a folder called Ansible and open it in vs code
In that folder, create another folder and name it inventory
Inside the inventory folder, create a file named hosts with no extension
hosts file
Start with an attribute; give it whatever name you want.
[servers]
Then list the servers that you want to manage using their DNS names or their IP addresses.
[servers]
vpsServer ansible_host=10.10.100.45
work-ToRule
10.10.45.62
We can give our hosts an alias by passing in their IP address to any name we wish to give it. In the list above, I have given the VPS with IP address 10.10.100.45 an alias of vpsServer. (IP address, just an example)
Create a folder named Playbook
In this folder we will create the actual yml files that we will use to automate the different processes we want to run on our remote servers. It can be an update, firewall config or install a package.
Our first playbook will update the Ubuntu server and set the right timezone. I will name it apt-update.yml.
Examine the YML file.
- hosts: "*" — this means all remote hosts will be updated. A single host can be selected by either its alias, DNA name, or IP address.
become: true—gives Ansible the administrative authority to act as a sudo user.
serial: 1 —In Ansible, serial: 1 tells the automation engine to manage your servers one by one rather than updating all of them at the same time.
tasks —In Ansible, the tasks section is structured as a list of individual actions. Each task is a YAML block that breaks down into four main parts: the Identity, the Module, the Arguments, and Directives.
- name: This is a plain-text description of what the task does and always starts with a dash or hyphen.
The Collection (community.general): An Ansible Collection is a standardized packaging format used to bundle and distribute Ansible content, including playbooks, roles, modules, and plugins.
The Module (timezone): This is the specialized tool or command line plugin you want to use. It tells Ansible how to execute the action on the server. Instead of writing raw terminal commands, you use abstract modules like apt (for packages), copy (for files), user (for accounts), or service (for daemons).
The Parameters (name: America/Port_of_Spain): These are the specific settings, options, or instructions you pass into the module. It defines the exact parameters of your action. The name: parameter is a mandatory argument required by the community.general.timezone module. It specifies the exact geographical timezone identifier you want to apply to the target Linux operating system.
If you're new to Ansible, you can find a collection of the modules and arguments available @ https://docs.ansible.com/projects/ansible/latest/collections/index.html
Run Playbook
Connect to the remote host in your terminal.
your-command-prompt:~$ ANSIBLE_HOST_KEY_CHECKING=FALSE ansible -i ./inventory/hosts vpsServer -m ping --user root --ask-pass
ANSIBLE_HOST_KEY_CHECKING=FALSE
This is a temporary environment variable that changes how Ansible handles security signatures. It tells Ansible to skip looking inside your local ~/.ssh/known_hosts file. It allows you to connect to a fresh or reinstalled VPS instantly without throwing the strict “Host key verification failed” fingerprint error.
ansible
This invokes the ad-hoc command line engine (used for running single, quick tasks instead of running an entire playbook file)
-i ./inventory/hosts
The -i flag stands for Inventory. It tells Ansible exactly where your infrastructure map file is saved. In this case, you are instructing it to bypass any default system paths and read the specific file named hosts located inside your ./inventory/ folder
vpsServer
This is the specific destination target. Ansible looks into your inventory to find a server or group named exactly vpsServer to run the task against.
-m ping
The module flag. It tells Ansible to execute the built-in ping software module. This is a diagnostic module that logs into the server, checks if Python is available, and returns a successful green"pong"if the link is healthy.
Once you get a green ‘pong’ you can run the next command.
your-command-prompt:~$ ansible-playbook ./playbooks/apt-update.yml --user root -e “ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts
ansible-playbook
This invokes Ansible's playbook execution engine. Unlike the simple ansible command (which runs just one quick ad-hoc task), ansible-playbook is designed to open an automation script file and run a whole sequence of structured tasks in order.
./playbooks/apt-update.yml
This is the relative file path to the exact automation script you want to run. : You are telling Ansible to open the file named apt-update.yml inside your playbooks folder and execute whatever configuration steps (like package updates or installations) are written inside it.
--user root
This asks Ansible to establish the initial SSH network connection using the root account, completely ignoring any other default usernames written inside your configuration files.
-e “ansible_port=22”
The -e flag stands for Extra Variables. This dynamically injects a temporary variable into the execution. Here, you are explicitly forcing Ansible to connect over standard Port 22, overriding any custom ports (like 2222) saved in your host files.
--ask-pass
Tells Ansible that you are using password authentication instead of an SSH key token. It forces the terminal to prompt you for the root SSH login password when you launch the command.
--ask-become-pass
This tells Ansible to prompt you for the privilege escalation (sudo) password.
Note: Since you are logging in directly as the absolute system master (root),--ask-become-pass is actually redundant here because root already has absolute power and never needs to escalate further.
-i ./inventory/hosts
The -i flag maps your Inventory. It tells the playbook engine exactly where to look to find your list of servers. You are directing it to read the specific hosts file located inside your ./inventory/ folder.
Summary of the Execution Flow
When you execute this command from your Control Node terminal, Ansible handles it in this sequence:
It opens your./inventory/hostsfile to look up the IP address of the target server.
It stops and asks you to type the SSH password (due to –ask-pass).
It stops and asks you to type the Sudo password (due to –ask-become-pass).
It bypasses port variables, connects directly to Port 22 as root, opens up your apt-update.yml playbook, and begins executing its tasks.
Conclusion
I want to give a shout-out to Aldo @https://dev.to/aldo_cve. He recommended Ansible in a previous post I published, and I looked it up.
I found Ansible to be a great addition to my workflow in setting up my backend. I hope you guys enjoyed this walk through. You can look forward to more posts where I publish some of the playbooks that I find useful.