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.
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 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? That’s the decision from lesson 3: the community package unless you have a reason. Distro packages (apt, dnf) exist too, if you’d rather your OS manage the lifecycle. 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 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 . When an install misbehaves
on an aging LTS box, check python3 --version before you blame Ansible.
A Python below the floor is the classic cause.
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. They go in the control node’s venv. The Windows
targets themselves still get nothing installed — Unit 8 covers which
library you need when.
The WSL contradiction
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 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 — knowing the contradiction exists is the job-relevant part.
Your control node exists and ansible --version proves it. Before it runs
anything against real hosts, learn where Ansible reads its configuration.
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.