Engineering Automation Environments: Deploying Ansible on Windows 10 via WSL and Containerization

The challenge of implementing Ansible on a Windows 10 workstation has historically been a point of friction for DevOps engineers and system administrators. Because Ansible is designed to run on Unix-like systems, Windows users were previously forced to rely on fragmented solutions such as Cygwin, the Git shell, or Cmder. While these tools provided a semblance of a Linux-like environment, they often felt kludgy and lacked the native integration required for professional automation workflows. Alternatively, the only robust method was the deployment of a full Linux Virtual Machine (VM), which consumes significant system resources and introduces overhead in managing network interfaces and shared folders.

The introduction of the Windows Subsystem for Linux (WSL) revolutionized this landscape by allowing a full Ubuntu Long Term Support (LTS) release to run directly inside Windows 10. This architectural shift enables a more stable, friendly, and performant way of using Ansible on a Windows workstation without the weight of a full VM. Parallel to this, the emergence of Docker for Windows (DfW) provided a container-based alternative, allowing engineers to leverage the "magic of containers" to instantiate Ansible environments quickly. This is particularly useful for specific project-based requirements, such as building demos for HPE Synergy systems using the OneView Composer API, where a traditional controller node is required to manage hardware frames.

Architectural Prerequisites for WSL Deployment

Before the installation of the Linux subsystem can commence, the host system must meet specific hardware and software criteria to ensure the virtualization layer functions correctly.

• Windows 10 version: The system must be running the Anniversary Update or a later version.
• System Architecture: The installation must be 64-bit. WSL cannot run on 32-bit systems.

The requirement for a 64-bit architecture is rooted in the way the subsystem handles memory mapping and the translation of Linux system calls to the Windows kernel. Using an outdated version of Windows 10 or a 32-bit installation will result in a failure to initialize the subsystem, as the underlying virtualization primitives required for the Ubuntu LTS distribution are absent.

Enabling the Windows Subsystem for Linux

The process of activating WSL involves transitioning the operating system into a mode that permits the execution of Linux binaries.

1. Open 'Settings' by clicking the cog icon in the start menu.
2. Navigate to 'Update & Security' and select the 'For developers' option located on the left-hand sidebar.
3. Toggle the 'Developer mode' option to the 'On' position and accept any warnings provided by the Windows operating system.

Activating Developer Mode is a technical necessity because it signals to Windows that the user intends to install and test applications that may not be digitally signed or may require low-level system access. Once this toggle is flipped, Windows initiates background processes to prepare the environment. Although the system may prompt the user for a restart to apply these changes, this step can be temporarily ignored during the initial setup phase.

Following the enablement of Developer Mode, the user must install the Ubuntu distribution. This process involves filling out configuration prompts and creating a separate user account specifically for the Linux subsystem. This separation of identities is critical for maintaining the Linux filesystem's permission structure, which differs fundamentally from the Windows NTFS permission model.

Ansible Installation Path within Ubuntu on Windows

Once the Ubuntu environment is operational, Ansible can be installed using the Python Package Index (pip). Because the environment is a standard Ubuntu LTS release, the installation follows standard Linux procedures.

First, the user must open a bash prompt by typing bash in the start menu and hitting enter. The initial setup requires the installation of pip and several essential development libraries.

• Install Pip and dependencies:
  sudo apt-get -y install python-pip python-dev libffi-dev libssl-dev

The inclusion of python-dev, libffi-dev, and libssl-dev is mandatory. These libraries provide the necessary headers and SSL capabilities required to compile and run Ansible's Python modules. Without these, the installation of Ansible via pip may fail during the build process of its dependencies.

Next, Ansible is installed using the following command:

• Install Ansible:
  pip install ansible --user

The use of the --user flag is a critical technical requirement due to the peculiarities of the Windows Subsystem for Linux. In this environment, pip cannot easily install packages globally without risking permission conflicts or corrupting the system-level Python environment. By using --user, the packages are installed into the user's home directory, specifically under ~/.local/bin.

Environment Configuration and Path Optimization

Because the --user flag redirects the installation to a non-standard directory, the operating system will not automatically recognize the ansible command until the binary path is added to the system's environment variables.

The following command must be executed to append the local bin directory to the bash configuration file:

• Update PATH:
  echo 'PATH=$HOME/.local/bin:$PATH' >> ~/.bashrc

This action ensures that every time a bash session is initiated, the shell knows where to look for the Ansible executable. To apply these changes immediately without restarting the shell, the user must run:

• Source configuration:
  source .bashrc

After completing these steps, the installation can be verified. The command which ansible should return the path to the executable, and ansible --version should display the currently installed version of the software.

Troubleshooting Common Installation Errors

During the installation process, some users may encounter a specific Python error related to the MarkupSafe library. This manifests as an ImportError: No module named markupsafe.

This error typically occurs due to a mismatch in how dependencies are resolved within the WSL environment. To resolve this, the user must manually install the missing module using pip:

• Fix MarkupSafe error:
  pip install markupsafe --user

Manually forcing the installation of this dependency ensures that the Ansible core can properly render templates and manage the internal logic required for playbook execution.

Integrating Windows Filesystems with Ansible

One of the most powerful features of WSL is the ability to interact with the native Windows filesystem. This allows users to store their playbooks in standard Windows directories (like the Documents folder) and execute them from the Linux subsystem.

Windows drives are automatically mounted within the subsystem inside the /mnt directory. For a user named jgeerling, the path to the Documents folder would be /mnt/c/Users/jgeerling/Documents.

To test the integration and verify that Ansible is working, the following workflow should be implemented:

1. Navigate to the Windows Documents directory:
   cd /mnt/c/Users/jgeerling/Documents

2. Create a new test playbook file:
   touch test.yml

3. Use a text editor like nano to add the following content to test.yml:

   ```yaml

• hosts: localhost
  tasks:
  • debug: msg="Ansible is working!"
    
    ```

4. Execute the playbook:
   ansible-playbook test.yml --connection=local

The use of --connection=local is vital here. Since the user is running the playbook on the same machine they are controlling, this flag tells Ansible to bypass the standard SSH connection attempt and execute the modules directly on the local host. While Ansible might issue a warning regarding the absence of an inventory file, the localhost host will function automatically under this connection method.

Alternative Deployment: Docker for Windows (DfW)

For scenarios where a lightweight, disposable, or highly specific environment is needed, Docker for Windows (DfW) serves as an alternative to WSL. This method utilizes containers to instantiate Ansible, which is particularly advantageous for developers who do not want to permanently alter their host system's configuration.

In professional environments, such as those managing HPE Synergy systems, containers allow for the rapid creation of a controller node. This node can be configured with the specific Python libraries and Ansible modules required to interact with the API endpoint of the OneView Composer. By using Docker, the engineer avoids the need to create a dedicated Linux host manually, as the container provides a pre-configured environment capable of running playbooks and managing the Synergy frame.

Summary of Technical Implementation Methods

Conclusion

The deployment of Ansible on Windows 10 has evolved from a "kludgy" experience involving Cygwin or heavy Virtual Machines to a streamlined process via the Windows Subsystem for Linux and Docker. The WSL approach provides a nearly native Ubuntu experience, allowing for the use of standard Linux tools, SSH key generation, and direct server connectivity. The critical path to success involves enabling Developer Mode, correctly configuring the 64-bit environment, and ensuring that the --user flag is used during pip installation to navigate the unique permission structures of the subsystem.

Furthermore, the ability to mount Windows drives under /mnt bridges the gap between the Windows user interface and the Linux automation engine, enabling a hybrid workflow where files are managed in Windows but executed in Linux. Whether choosing the persistence of WSL or the agility of Docker, Windows 10 is now a fully capable platform for Ansible orchestration, removing the historical barriers that once forced DevOps practitioners to choose between their preferred OS and their required automation tooling.

Sources

1. Using Ansible through Windows 10's Subsystem for Linux
2. Running Ansible on Windows 10