Setting Up an Ansible Control Node Using WSL2
In the previous part of the series, we:
Installed VMware Workstation Pro
Installed Ubuntu and Rocky Linux VMs
Configured internal networking
Setup up static IP addresses
Built a gateway router VM using nftables Now, It's time to level up
Instead of manually SSH-ing into each server, we will use Ansible.
What Is Ansible?
Ansible is an open-source automation tool for
Provisioning
Configuration management
Application deployment
Orchestration. It follows an agentless architecture, meaning nodes do not need any additional software.
Ansible works over SSH(Linux) or WinRM(Windows) and uses human-readable YAML playbooks to describe desired system state.
Why Do We Need Ansible?
So far, we've been managing servers manually using SSH.
ssh [email protected]
This works for 2-3 machines. But in real environments:
You might have to manager 10s or 100s of servers
You will need consistency
You will need repeatability This is where Ansible comes in. With Ansible, You can:
Run commands on multiple servers at once
Enforce configuration
Automate provisioning and deployments
Consider this scenario:
Imagine you have 50+ VMs:
Some running DBs
Some running backend service
Some handling frontend traffic Now a critical patch for OpenSSL or SSH is released.
Are you going to SSH into all 50+ machines manually? No.
With Ansible, you can:
Run a single command (ad-hoc commands) or playbook
Ensure systems are updated to the required version
The machine from which Ansible runs is called Control Node
NOTE: This series focuses on building a DevOps Homelab We are using Ansible as an example, so we will not go deep into playbooks and advanced usage here.
What is WSL2 and Why Use WSL2 Instead of Another VM or Windows itself?
Why Not Windows?
Ansible is designed for Linux Environments While it can run on Windows via python:
SSH behavior may be inconsistent
Many modules assume Linux utilities
Debugging becomes painful In short: Its not production aligned.
Why not another VM?
This is valid approach. In production, the control node is usually a dedicated Linux Machine. But for a home lab setup:
It uses additional CPU/RAM
Adds management overhead
Slower Iteration That means: Overkill for a home lab setup
Why not Docker?
Docker is great, but Docker containers are meant to be ephemeral. And are not good for control node in early stages of learning DevOps.
SSH key management becomes messy
Container networking adds complexity
Not ideal for persistent configuration Meaning: Unnecessary abstraction headache
What is WSL2 and Why it's the Best Fit?
WSL2 or Windows Subsystem for Linux 2 is a compatibility layer for running Linux Distributions directly on Windows 10/11 with a real Linux kernel inside a lightweight VM. WSL2 is best fit for our use case because:
Native Linux environment
Fast startup
Minimal resource consumption than a VM
Easy Integration with VS Code and most importantly, it can reach our VM via internal network because of the VMware network configuration.
Since we enabled Host-only adapter while creating internal networks:
Windows host is a part of that internal network
WSL2 shares host network stack That is WSL2 can access the VMs easily
Architecture Diagram
Below gives a high level overview of the architecture of the whole Home lab
Note: The gateway VM connects both NAT (internet) and internal network, enabling outbound access for all nodes
Installing WSL2 + Ubuntu
If you haven't installed WSL 2 yet, install it by entering the following command in powershell.
wsl --install -d ubuntu
This will ensure that wsl2 is available and will install Ubuntu. It may ask for UAC and will prompt you to create username and password
To start WSL type:
wsl
First update the packages using
sudo apt-get update && sudo apt-get upgrade -y
Installing Ansible
Ansible can be installed using apt.
Inside WSL run
sudo apt-get install ansible -y
Verify the installation using
ansible --version
Configuring SSH (Password-less Authentication)
Ansible uses SSH for communication. For this we will enable Password-less authentication with client. For this:
We need to generate SSH-Keys from WSL (control node)
Transfer generated public key to clients
To generate key, enter below command from WSL:
ssh-keygen -t ed25519 -C 'ansible-control-node'
Press Enter to accept defaults. Keys will be
~/.ssh
To transfer keys to target nodes, do the following for all the nodes:
ssh-copy-id <user>@<ip>
Replace <user> and <ip> with username and IP of your nodes.
Example:
ssh-copy-id [email protected] # ubuntu VM
ssh-copy-id [email protected] # rocky VM
It will ask for the password. To verify try SSH. If no password is asked, that means setup is successful
Summary so far
At this point:
WSL2 can reach VMs
Ansible has been installed in WSL2
Password less authentication has been configured Next we will test ansible.
Creating an Inventory File
We will store all files inside a directory in WSL.
Create a directory ansible-tests and cd into it
mkdir ~/ansible-tests && cd ~/ansible-tests
Create inventory file inventory.ini with following contents
[ubuntu]
ubuntu1 ansible_host=172.29.10.10 ansible_user=aurora
[rocky]
rocky1 ansible_host=172.29.10.20 ansible_user=aurora
[all:vars]
ansible_python_interpreter=/usr/bin/python3
Replace aurora with the username inside the VM.
TIP: Create a dedicated
ansibleuser in real environments
Testing Ansible
The most basic ansible test is checking connectivity to all hosts Use the ansible's ping module to test the connectivity:
ansible all -i inventory.ini -m ping
the output should be something like :
This confirms that the SSH Works and Inventory is correct and ansible control node is functional.
Whats Next?
This completes the core DevOps Homelab setup demo. We now have:
Multiple Linux servers
A segmented network
A gateway router
An Ansible control node
You can now extend your lab with:
Kubernetes (K8s)
Monitoring (Prometheus + Grafana)
Logging stack (ELK/Loki)
I have personally extended this lab further with additional VMs and Planning to implement Monitoring with it.
Series Roadmap
Setting Up an Ansible Control Node Using WSL2 ✅