Los desarrolladores pueden acceder a la potencia de Windows y Linux al mismo tiempo en una máquina Windows. Subsistema de Windows para Linux (WSL) permite a los desarrolladores instalar una distribución de Linux (como Ubuntu, Debian, etc.) y usar aplicaciones, utilidades y herramientas de línea de comandos de Bash directamente en Windows, sin modificar, sin la sobrecarga de una máquina virtual tradicional o una configuración de arranque dual.
en PowerShell se debe ejecutar el siguiente comando
PS C:\Users\Hector> wsl --install
Para verificar el resultado, ejecutar lo siguiente
PS C:\Users\Hector> wsl -l -v
Verificamos la versión de PowerShell instalada en Windows, se espera una respuesta al comando [Get-Host | Select-Object Version] similar a la siguiente
PS C:\User\Hector> Get-Host | Select-Object Version
Version
-------
5.1.19041.1237
Verificamos la versión .NET instalada en Windows, se espera una respuesta al comando [Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version] similar a la siguiente
PS C:\User\Hector> Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version
>>
PSChildName Version
----------- -------
Client      4.8.04084
Full        4.8.04084
Client      4.0.0.0
Verificamos si tiene WINRM instalado, se espera una respuesta al comando [winrm get winrm/config/Service] similar a la siguiente
PS C:\User\Hector> winrm get winrm/config/Service
WSManFault
    Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
PS C:\Users\vagrant> winrm get winrm/config/Winrs
WSManFault
    Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
PS C:\Users\vagrant> winrm enumerate winrm/config/Listener
WSManFault
    Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Si se confirma que no tenemos WINRM instalado en nuestro equipo, bajamos un script desarrollado por el equipo de Ansible para habilitarlo con todo lo necesario para realizar pruebas
https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
Verificamos que WINRM esté correctamente instalado en nuestro equipo
PS C:\User\Hector> winrm get winrm/config/Service
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true
Creamos un usuario con privilegios de Administrador para que Ansible se ejecute correctamente.

Luego, ingresamos al usuario en el grupo de Administradores locales

Entramos a la terminal de Ubuntu, creamos el usuario y realizamos todo el proceso inicial de Ubuntu, luego se actualiza
hector@localhost:~$ sudo apt update
Instalamos Ansible en Ubuntu (WSL2)
hector@localhost:~$ sudo apt install ansible
Verificamos la versión de Ansible instalada
hector@localhost:~$ ansible --version
creamos el archivo inventory e ingresamos lo siguiente, reemplazando la IP por la IP local del equipo, en mi caso es la 192.168.X.X, el nombre de usuario y contraseña de la cuenta que creamos para Ansible previamente, lo demás queda igual
[win]
thinkpad ansible_host=192.168.X.X
[win:vars]
ansible_user=Ansible
ansible_password=qwerty
ansible_port=5986
ansible_connection=winrm
ansible_winrm_transport=basic
ansible_winrm_server_cert_validation=ignore
A modo de prueba, te dejo este playbook para crear archivo vacío, en la ruta C:\ con el nombre pruebaAnsible.txt, al cual llamaremos playbook-touch.yml
---
- hosts: win
  tasks:
    - name: Crear archivo vacío, en la ruta C:\ con el nombre pruebaAnsible.txt
      win_file:
        path: C:\pruebaAnsible.txt
        state: touch
Si todo sale bien, tendrás Ansible instalado en tu WSL2 con Ubuntu y pudiendo hacer cosas con tu Windows de forma local
hector@localhost:~$ ansible-playbook -i inventory playbook-touch.yml
PLAY [win] *************************************************************************************************************
TASK [Gathering Facts] *************************************************************************************************
ok: [thinkpad]
TASK [Crear archivo vacío, en la ruta C:\ con el nombre pruebaAnsible.txt] *******************************************
changed: [thinkpad]
PLAY RECAP *************************************************************************************************************
thinkpad                   : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
hector@localhost:~$
