unit 2 · Setup
Installing a control node
One pip install — and one contradiction in the docs
you may want to read 2 · Agentless, push-based first — but nothing is locked
tl;dr
- pip install ansible (core + 85+ collections) or ansible-core (engine only); distro packages exist too.
- The control node needs a supported Python — policy is the three most recently released Python versions.
- No native Windows control node. WSL works — but the two official guides contradict each other about it.
why it matters Building your own control node is day one at any Ansible job. Pick the wrong package, an unsupported Python, or the wrong side of the WSL debate and you lose hours before anything runs.
Four lessons of architecture and packaging — time to own a control node. Lesson 2 already delivered the good news: Ansible gets installed in exactly one place. No agent rollout, no per-server anything. One machine, one install, and your whole estate is reachable.
Two pip installs, one decision
Ansible ships as a Python package, so the install is pip — ideally inside a venv , so Ansible’s dependencies never tangle with the system Python:
# a venv keeps Ansible's Python deps isolated and easy to rebuild
python3 -m venv ~/.venvs/ansible
source ~/.venvs/ansible/bin/activate
pip install ansible # community package: engine + 85+ collections
# pip install ansible-core # ...or engine only; you install collections yourselfWhich line to run is the decision you already made in lesson 3 — the community package unless you have a reason. Distro packages (apt, dnf) exist too if you want your OS to manage the lifecycle. Either way, verification is one command:
ansible --version # shows the core version and the Python it runs onPython is the real dependency
The control node needs a supported Python, and the support policy moves:
Ansible tracks the three most recently released Python versions on the
controller. Right now, ansible-core 2.21 tracks
Python 3.12–3.14 . So when an install misbehaves
on some aging LTS box, check python3 --version before you blame Ansible —
a Python below the floor is the classic cause.
One extra paragraph for your estate: managing Windows targets needs
connection libraries on the control node — pywinrm (at
least 0.4.0 ) for WinRM, pypsrp for PSRP, plus the
[kerberos] or [credssp] pip extras when your auth needs them. Note where
they go: the control node’s venv. The Windows targets themselves still get
nothing installed — Unit 8 covers which library you need when.
The WSL contradiction
So can your Windows laptop be the control node? Natively, no — both official guides agree with the lesson 2 verdict: “Ansible cannot run on Windows as the control node due to API limitations on the platform.” The sanctioned escape hatches are WSL or a container. And on WSL, the official docs genuinely disagree with themselves:
- The installation guide lists WSL as a usable control-node option.
- The OS guide says WSL “is not supported by Ansible and should not be used for production systems.”
Both sentences are live in the docs today. This course won’t pick a side, because knowing the contradiction exists is the job-relevant part: it decides arguments.
Your control node exists and ansible --version proves it. But before it
runs anything against real hosts, you should know where Ansible reads its
configuration from — because four different places can claim that job, and
only one wins. That’s ansible.cfg, next.
self-check — recall, not a test
1 What is the difference between pip install ansible and pip install ansible-core?
2 How current does the control node’s Python have to be?
3 One colleague says the docs bless WSL as a control node; another says the docs ban it for production. Who is right?
lab (optional — never required)
Create a venv on any Linux box or WSL distro, pip install ansible into it, and prove the node works with ansible --version.
needs: Any Linux machine, VM, container or WSL distro with Python 3.