Ansible Quick Start: Inventory, Authentication, and Playbooks
Getting Ansible off the ground with one control node and two CentOS 7.8 managed nodes: the EPEL repo and installation, three ways to write the inventory (per host, shared vars, a range), public-key versus password authentication, the first-login fingerprint check, and writing and running a playbook.
On this page11 sections
Getting started
Preparing the environment
Server hardware
| Name | OS | CPU | Memory | Internal IP | Public IP | Cluster role |
|---|---|---|---|---|---|---|
| ECS | CentOS 7.8 64-bit | 2 vCPU | 2GB | 192.0.2.18 | 203.0.113.222 | Master |
| ECS | CentOS 7.8 64-bit | 2 vCPU | 2GB | 192.0.2.11 | 203.0.113.28 | Node |
| ECS | CentOS 7.8 64-bit | 2 vCPU | 2GB | 192.0.2.20 | 203.0.113.221 | Node |
On the control node
Configure the EPEL repository:
yum install -y epel-release
Install Ansible:
yum install -y ansible
Verify:
ansible --version
Inventory
The inventory here means writing the SSH details of the managed hosts into the control node’s Ansible configuration file, so that Ansible on the control node can reach them.
View Ansible’s host configuration:
cat /etc/ansible/hosts
Edit the configuration file to append the managed hosts:
cat >> /etc/ansible/hosts << EOF
[k8s-cluster]
192.0.2.11
192.0.2.20
EOF
Above we group the IPs of the two worker nodes into an inventory group called “k8s-cluster” and append it to Ansible’s host configuration file.
Now try running it:
ansible k8s-cluster -m shell -a "free -m"
This command tells Ansible to have every managed host in the “k8s-cluster” group run a shell command that reports its memory usage, and the results are shown on the control node.
Authentication
Authentication is what lets the control node act on a managed host: it has to pass that host’s security check first. The two common approaches are public key and password.
Public key
Distribute the control node’s public key to each managed host, and from then on the control node can log in to them without a password.
Password
In the control node’s Ansible host configuration file, add the port, user, and password alongside each managed host.
| Parameter | Description | Notes |
|---|---|---|
| ansible_port | Port to use, default: 22 | – |
| ansible_user | User to use, default: root | – |
| ansible_password | Password | – |
Appending the password and related parameters with the inventory:
cat >> /etc/ansible/hosts << EOF
[k8s-cluster]
192.0.2.11 ansible_port=22 ansible_user='root' ansible_password='YourPassword123'
192.0.2.20 ansible_port=22 ansible_user='root' ansible_password='YourPassword123'
EOF
Shared variables:
cat >> /etc/ansible/hosts << EOF
[k8s-cluster:vars]
ansible_port=22
ansible_user='root'
ansible_password='YourPassword123'
[k8s-cluster]
192.0.2.11
192.0.2.20
EOF
A variable range:
cat >> /etc/ansible/hosts << EOF
[k8s-cluster:vars]
ansible_port=22
ansible_user='root'
ansible_password='YourPassword123'
[k8s-cluster]
192.0.2.[11:20]
EOF
Host key fingerprint
When the control node logs in to a managed host it has to confirm a fingerprint first, to avoid security problems. This confirmation is only needed the first time; once confirmed it never asks again. There are roughly three ways to deal with it:
- Set up passwordless login — distributing the control node’s key to a managed host confirms the fingerprint along the way.
- Authenticate with a password in the inventory.
- Configure Ansible to skip the fingerprint confirmation.
Skipping the confirmation
Configure Ansible to skip it:
sed -i 's/host_key_checking = True/host_key_checking = False/g' /etc/ansible/ansible.cfg
Ansible has no daemon (it is agentless) and reads its configuration on every run, so there is no service to restart after editing ansible.cfg.
Playbooks
Create a playbook file: my-action.yml
- hosts: all
tasks:
- name: touch file
shell: touch /tmp/mylinux.txt
Run the playbook:
ansible-playbook -i hosts my-action.yml -C
Another example — updating the system:
- hosts: all
tasks:
- name: update system
shell: yum update