Installing Ansible and the Control Node

Ansible installs on exactly one machine — the control node — and from there it reaches every managed server. So "installing Ansible" really means setting up that one box and confirming the targets are reachable over SSH; there is nothing to install on the servers themselves. The package you want is either ansible, the batteries-included bundle, or the lean ansible-core alone, and the right install method is pip or pipx far more often than your distribution's repository.

This is the agentless model showing up in the install step itself: one control node to manage, and a fleet that needs nothing but SSH and Python it already has. The sections below cover what the control node is, which package to choose, how to install it without ending up a year behind, what a managed node actually requires, and how to pin a version so the whole team runs identical behavior.

The Control Node

The control node is a Linux or macOS machine with Python — that is the entire hardware requirement. It needs network reach and SSH access to every managed host, and nothing else; it is not a server other machines connect to, just the place you run Ansible from. A laptop, a jump host, or a CI runner all qualify equally.

Windows is not supported as a control node. If your workstation is Windows, run the control node inside WSL or on a Linux box — the managed nodes can be anything Ansible can reach, but the place you run ansible-playbook from has to be Linux or macOS. That single constraint trips up newcomers who assume the tool runs anywhere.

ansible vs ansible-core

There are two packages, and the difference is scope. ansible-core is the engine plus a handful of built-in modules — the ansible.builtin collection and not much else. The ansible package is ansible-core plus a large, community-curated set of vetted collections — more than 85 of them, holding thousands of modules and plugins: community.general, ansible.posix, the major cloud collections, and more.

Pick ansible for a batteries-included start, when you want common modules present without thinking about which collection they live in. Pick ansible-core once a project matures and you want to declare collection dependencies explicitly — a minimal, reproducible install where every collection is pinned in a requirements file rather than pulled in wholesale. Most people start on ansible and graduate to ansible-core plus an explicit collection list.

Install Methods

The recommended method is pipx install ansible, which installs Ansible into its own isolated environment and puts the commands on your path without colliding with system Python packages. A pip install into a virtualenv works the same way and is the right choice inside CI. The distribution package — apt install ansible or dnf install ansible — is the one to avoid: it lags upstream releases badly, often by a year, so you hit bugs that were fixed long ago.

After installing, verify with ansible --version. It prints more than a version string — it shows the Python interpreter Ansible is running on and the config file currently in effect, which is the fastest way to confirm you are running the install you think you are and not a stale distro copy still on the path.

# isolated, current install — the recommended path
pipx install ansible

# verify: version, the Python it runs on, and the config file in effect
ansible --version
# ansible [core 2.19.x]
#   config file = /home/you/larkspur/ansible.cfg
#   python version = 3.12.x

The output above confirms three things at once: a current core version, the project's own ansible.cfg being picked up rather than a system default, and the Python interpreter in play. If ansible --version reports a version a year old, you are running the distro package and should switch to the pipx install before going further.

Managed-Node Requirements

A managed node needs only two things: an SSH server and Python 3. There is no Ansible installed on it — that is the entire point of agentless, and it is worth stating plainly because the agent-based habit dies hard. You do not install "Ansible" on every target; you confirm the target answers SSH and has a Python interpreter, and it is already manageable.

The way to prove that path end-to-end is the ping module, which the next topic covers in full. It logs in over SSH and runs a trivial Python module on the node, so a green result confirms Ansible can both connect and execute there — not merely that the host is up. Running it before you write any playbook turns a silent connectivity failure into an obvious one.

Versions and the Release Cadence

ansible-core ships on a fast minor cadence with a documented support window, which means behavior can shift between minor versions in ways a playbook notices. Left unpinned, each engineer ends up on whatever they happened to install, and a play that is green on one laptop fails on another over a change neither person saw.

Pin the version in CI and document it in the repo, the same discipline a disciplined Terraform setup applies to its CLI. When local installs and the pipeline run an identical ansible-core, "works on my machine" stops being a category of bug. The cost is one line in a requirements file; the payoff is that the team and the pipeline behave the same way every time.