Installing and Configuring Ansible
Ansible only needs to be installed on the control node, never on managed nodes, which keeps the setup process short: install a recent Python 3 interpreter, then install the ansible or ansible-core package. The ansible-core package contains the runtime engine and the built-in modules maintained by the core team, while the full ansible package additionally bundles thousands of community and partner-maintained collections (like community.general or amazon.aws) so most getting-started guides recommend installing the full ansible metapackage.
Cricket analogy: Installing only on the control node is like a team only needing to equip the head coach with tactical software, while players just need their kit and the ability to follow instructions on the field.
Installation Methods
The most portable installation method is pip, Python's package manager, which works identically across Linux distributions and macOS and lets you pin an exact version inside a virtual environment for reproducibility across a team. Alternatively, most Linux distributions ship Ansible in their system package manager (apt on Debian/Ubuntu, dnf on Fedora/RHEL), which is convenient but often lags behind the latest pip release and installs system-wide rather than in an isolated environment.
Cricket analogy: Choosing pip with a virtual environment is like a franchise using its own dedicated training kit for every player, ensuring identical gear, rather than relying on whatever generic equipment the local stadium happens to stock.
# Recommended: install in an isolated virtual environment via pip
python3 -m venv ~/.venvs/ansible
source ~/.venvs/ansible/bin/activate
pip install --upgrade pip
pip install ansible
# Verify installation
ansible --version
# Alternative: system package manager (Debian/Ubuntu)
sudo apt update && sudo apt install -y ansibleThe ansible.cfg File
Ansible reads configuration from ansible.cfg, checked in a defined precedence order: first the ANSIBLE_CONFIG environment variable, then ./ansible.cfg in the current directory, then ~/.ansible.cfg in the user's home directory, and finally /etc/ansible/ansible.cfg as a system-wide fallback — the first file found wins, and settings are not merged across files. Common settings configured here include the default inventory path, the remote_user to connect as, forks for parallelism, and roles_path for where to look up reusable roles, all of which can also be overridden per-run via environment variables or command-line flags.
Cricket analogy: Config file precedence is like a match using the local ground's specific playing conditions if defined, falling back to the league's standard rules only if the ground hasn't specified anything.
Verifying Your Setup
After installation, verify connectivity before writing any playbooks by running the ping module against your inventory: ansible all -m ping -i inventory/hosts.ini, which confirms SSH access and that Python is reachable on every target without changing anything. It is common for the first attempt to fail on SSH host key prompts or missing Python interpreters on minimal container images, both of which are worth resolving immediately since every subsequent playbook run depends on this basic connectivity working reliably.
Cricket analogy: Running a ping check first is like a team doing a pitch inspection and fitness test before the toss, rather than discovering mid-match that a player or the ground itself isn't ready.
If 'ansible all -m ping' fails with '/usr/bin/python: not found', the target likely lacks Python at the expected path. Set ansible_python_interpreter=/usr/bin/python3 (or auto via ansible_python_interpreter=auto_silent) for that host or group rather than assuming the control node's Python version applies remotely.
- Ansible is installed only on the control node, never on managed nodes.
- pip in a virtual environment gives portable, version-pinned installs; system packages are convenient but often outdated.
- ansible-core has the engine and built-in modules; the full ansible package adds community collections.
- ansible.cfg is resolved in a strict precedence order: ANSIBLE_CONFIG, ./ansible.cfg, ~/.ansible.cfg, /etc/ansible/ansible.cfg.
- Common config settings include inventory path, remote_user, forks, and roles_path.
- The ping module verifies SSH and Python connectivity without making any changes.
- Missing Python on a target is a common first-run failure, fixed via ansible_python_interpreter.
Practice what you learned
1. Where must Ansible be installed?
2. What is the difference between ansible-core and the full ansible package?
3. What is the ansible.cfg lookup precedence order?
4. What does 'ansible all -m ping' verify?
5. What commonly causes 'ansible all -m ping' to fail on minimal container images?
Was this page helpful?
You May Also Like
What Is Ansible?
Ansible is an open-source, agentless automation tool for configuration management, application deployment, and orchestration, driven by human-readable YAML playbooks.
Agentless Architecture and SSH
Ansible manages remote systems without installing any persistent software on them, relying entirely on existing SSH connectivity and Python for execution.
Inventory Files Explained
An inventory file tells Ansible which hosts exist and how they're grouped, and can be static (INI or YAML) or generated dynamically from a cloud provider or CMDB.
Ad-Hoc Commands
Ad-hoc commands run a single Ansible module against a set of hosts directly from the command line, ideal for quick one-off tasks that don't warrant a full playbook.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics