Automatización avanzada en Windows con PowerShell DSC y Ansible

Informatec Digital » Recursos » Automatización avanzada en Windows con PowerShell DSC y Ansible

Si trabajas con infraestructuras Windows y te suenan términos como PowerShell, DSC, Ansible y automatización, seguramente ya intuyes que combinarlos bien puede cambiar por completo tu forma de administrar servidores. Pasar de los clics manuales en el asistente de Windows a una configuración totalmente declarativa y repetible marca la diferencia entre ir apagando fuegos o tener un entorno bajo control.

En este artículo vamos a profundizar en cómo PowerShell Desired State Configuration (DSC) y Ansible encajan juntos para gestionar Windows (y también Linux) a escala, qué papel juegan tecnologías como WinRM, Azure Automation, Terraform o cloud-init, y cómo puedes apoyarte en los recursos DSC existentes desde Ansible gracias al módulo win_dsc. Verás ejemplos prácticos, casos de uso reales y criterios para decidir cuándo tirar de DSC nativo, de módulos Ansible o de otros enfoques de automatización.

Panorama general: automatización de Windows con PowerShell, DSC y Ansible

PowerShell y Ansible persiguen el mismo objetivo: automatizar la configuración y administración de tus sistemas de forma reproducible. La diferencia está en el enfoque. DSC es la plataforma de gestión de configuración integrada en PowerShell, muy centrada en Windows (aunque puede trabajar con Linux mediante OMI), mientras que Ansible es un motor de automatización multipropósito y multiplataforma, pensado para orquestar desde un único punto infraestructuras híbridas y heterogéneas.

Con Red Hat Ansible Automation Platform puedes automatizar servidores Windows sin instalar agentes adicionales, aprovechando WinRM u OpenSSH como canales de conexión y apoyándote en recursos DSC, módulos de Ansible y scripts de PowerShell. Todo ello se organiza a través de playbooks en YAML, donde defines qué estado debe alcanzar cada host, tanto en Windows como en Linux.

PowerShell Desired State Configuration, por su parte, ofrece cientos de recursos especializados para configurar casi cualquier componente de Windows: servicios, características del sistema, IIS, SQL Server, Active Directory, registro, ficheros, etc. Estos recursos encapsulan la lógica de comprobar y aplicar el estado deseado, de forma que tú solo declaras “cómo quieres que esté” la máquina.

La clave está en que, desde Ansible, puedes utilizar esos recursos DSC de forma directa mediante el módulo ansible.windows.win_dsc, combinando la potencia de orquestación de Ansible con la profundidad de configuración específica de Windows que ofrece DSC. De esta forma consigues lo mejor de ambos mundos sin duplicar esfuerzos.

WinRM y acceso remoto a Windows para Ansible

Para que Ansible pueda gestionar servidores Windows, es fundamental entender cómo funciona WinRM (Windows Remote Management). WinRM es la tecnología integrada de Microsoft para administración remota basada en HTTP/HTTPS, y es el canal habitual que Ansible utiliza para ejecutar tareas en equipos Windows.

El primer paso es configurar WinRM correctamente en los hosts destino y en el nodo de control donde corre Ansible. Esto implica ajustar autenticación, cifrado, permisos y, muy a menudo, lidiar con particularidades como el inicio de sesión no interactivo, donde los comandos se lanzan sin una sesión de usuario activa. Ese contexto sin sesión interactiva complica tareas como actualizaciones de Windows o escenarios de doble salto de autenticación, donde necesitas acceder a un segundo recurso remoto (por ejemplo, un recurso compartido en otro servidor).

La ventaja de usar Red Hat Ansible Automation Platform es que te permite codificar credenciales y mecanismos de autenticación de forma centralizada y segura, de manera que el manejo de estos casos complejos quede abstraído en gran medida. Además, la plataforma también puede usar OpenSSH para acceder a Windows Server, algo cada vez más común con las versiones modernas de Windows.

En la práctica, combinar WinRM, la gestión de credenciales de Ansible y las capacidades de DSC te permite construir flujos de automatización robustos que se ejecutan sin supervisión, incluso en entornos con restricciones de seguridad elevadas.

PowerShell DSC: plataforma de configuración declarativa

PowerShell Desired State Configuration es una plataforma declarativa de gestión de configuración integrada en Windows. Con DSC defines, en código, cómo debe estar configurada una máquina: qué roles y características deben estar instalados, qué servicios activos, qué parámetros de registro, qué ficheros o directorios deben existir, etc.

Las configuraciones DSC describen el estado deseado para un conjunto de nodos. En cada equipo gestionado se ejecuta un LCM (Local Configuration Manager), que es el motor que lee esas configuraciones, comprueba el estado real y aplica los cambios necesarios. Además, puedes montar un servidor de extracción (pull server) que centraliza las configuraciones y desde el cual los nodos se actualizan y reportan cumplimiento.

DSC no se limita a Windows: mediante el servidor de infraestructura de gestión abierta (OMI), también puede trabajar con máquinas Linux. Eso sí, donde brilla con diferencia es en entornos Windows, donde la comunidad ha desarrollado una gran colección de recursos especializados para tareas tan variadas como configurar IIS, SQL Server o Active Directory.

Una de las grandes ventajas de DSC es que se centra en el resultado, no en los pasos. Tú declaras el estado (por ejemplo, “esta característica debe estar presente, este servicio iniciado, este valor de registro configurado”) y el motor se encarga de llegar hasta ahí, comprobando y corrigiendo si algo se desvía con el tiempo.

Cómo encaja Ansible con DSC: módulo win_dsc y orquestación

En teoría podrías usar DSC de forma aislada, pero en la práctica resulta mucho más útil cuando lo combinas con Ansible como capa de orquestación. Ansible se encarga del inventario, la ejecución ordenada de tareas, la coordinación entre sistemas y la integración con pipelines CI/CD, mientras que DSC aporta los recursos concretos para tocar las tripas de Windows.

El módulo ansible.windows.win_dsc es el puente entre ambos mundos. Este módulo invoca una clase de recurso DSC en el host Windows de destino. En el playbook únicamente tienes que definir:

• resource_name: el nombre del recurso DSC que quieres usar (por ejemplo, File, WindowsFeature, Service, Registry, xWebsite, etc.).
• El resto de parámetros, que corresponden directamente con las propiedades del recurso DSC (por ejemplo, DestinationPath, Ensure, Name, State, etc.).

Cuando Ansible ejecuta la tarea, traduce esos parámetros en una configuración DSC temporal, la aplica en el host y recoge el resultado (incluyendo si se han producido cambios o no). De esta forma puedes reutilizar todo el catálogo de recursos DSC sin tener que escribir módulos Ansible específicos para cada caso.

Por debajo, el flujo de ejecución sigue un patrón coherente: Ansible envía la tarea vía WinRM, el sistema Windows genera una configuración DSC en función de los parámetros, el motor DSC llama primero a Test-TargetResource para comprobar el estado actual, y si detecta diferencias ejecuta Set-TargetResource para aplicar los cambios. Ansible recibe un informe de si se ha modificado algo y cualquier mensaje relevante para depuración.

Este acoplamiento es especialmente potente cuando combinas módulos nativos de Ansible para Windows (como win_file, win_service, win_regedit, win_psmodule, etc.) con recursos DSC para aquellas áreas donde DSC ofrece opciones más finas o una cobertura funcional mayor.

Tipos de propiedades DSC y cómo mapearlas en Ansible

Cada recurso DSC define un conjunto de propiedades con un tipo bien especificado (string, booleano, arrays, tipos complejos de PowerShell, etc.). Cuando trabajas desde Ansible, tienes que traducir esas propiedades a sintaxis YAML manteniendo el tipo correcto. El módulo win_dsc hace mucho trabajo de conversión automática, pero conviene conocer algunos casos clave.

Para tipos sencillos como o , el mapeo es directo: cadenas entre comillas y booleanos en minúscula al estilo YAML (true, false), evitando escribir $true o $false como harías en PowerShell. Para propiedades de tipo , lo habitual es usar un formato ISO 8601 (por ejemplo, "2019-02-22T13:57:31Z") y asegurarte de que el valor se serializa como cadena, rodeándolo de comillas.

Las propiedades de tipo son un caso especial. Como este tipo no se puede serializar directamente a JSON, Ansible emplea una convención: defines dos parámetros separados con sufijo _username y _password (por ejemplo, Credential_username y Credential_password). El módulo genera el objeto PSCredential en el host remoto a partir de esos dos valores.

Para tipos , que representan diccionarios basados en una clase personalizada del recurso, en YAML se expresan como un mapa de clave-valor. Debes revisar la documentación del recurso (normalmente en el fichero <nombre_recurso>.schema.mof) para saber qué claves están permitidas y qué tipo tiene cada una. En la práctica se definen como diccionarios anidados dentro del módulo win_dsc.

Finalmente, las propiedades de tipo y los arrays (], ], etc.) se representan como diccionarios o listas YAML. Para los arrays se recomienda usar una lista YAML auténtica y no una cadena con valores separados por comas, porque así se evita parsing manual y se reduce la probabilidad de errores sutiles.

Ejemplos prácticos de uso de DSC desde Ansible

Una vez dominas la estructura básica del módulo win_dsc, puedes combinar recursos para construir playbooks de configuración muy completos. Algunos escenarios habituales que encajan muy bien con DSC son:

• Gestión de ficheros y directorios con el recurso File: creación de estructuras de carpetas, despliegue de ficheros de configuración con contenido concreto, asegurarse de que ciertos elementos existen o se han eliminado.
• Instalación de roles y características de Windows con WindowsFeature: IIS, .NET Framework, Telnet Client, herramientas de administración, etc.
• Control de servicios con el recurso Service: estado (iniciado/detenido), tipo de inicio (automático, manual), cuenta de servicio, etc.
• Configuración del registro con Registry: valores de seguridad, tiempos de espera, parámetros de protocolos, endurecimiento del sistema.
• Configuraciones avanzadas de IIS con módulos como xWebAdministration y recursos xWebsite, xWebAppPool, etc.

En todos estos casos, Ansible se limita a describir los parámetros del recurso DSC, mientras que el motor de DSC se encarga de comprobar y aplicar el estado. Además, a partir de Ansible 2.8 el módulo win_dsc valida automáticamente los parámetros frente a la definición del recurso: si usas un nombre de propiedad incorrecto, te dejas un obligatorio sin rellenar o pasas un valor fuera de rango, la tarea fallará con un error claro.

Si ejecutas Ansible con un nivel de verbosidad alto (por ejemplo, -vvv), la salida incluirá información detallada en invocation.module_args sobre las opciones utilizadas y las que estaban disponibles, lo que resulta muy útil tanto para depurar como para descubrir qué campos puedes configurar en cada recurso.

Ten en cuenta también que puedes usar el parámetro PsDscRunAsCredential para que el recurso DSC se ejecute como otro usuario distinto al sistema. Esto es muy práctico para acceder a la colmena de registro HKEY_CURRENT_USER del usuario con el que se conectó Ansible o para escenarios donde necesitas un contexto de seguridad concreto.

Recursos DSC personalizados y PowerShell Gallery

Los recursos DSC integrados con Windows cubren muchas necesidades, pero la verdadera potencia aparece cuando echas mano de recursos publicados en PowerShell Gallery o de paquetes creados por terceros. Hay módulos para todo: Active Directory, SQL Server, IIS avanzado, políticas de seguridad, etc.

Puedes descubrir recursos disponibles con el cmdlet Find-DscResource o directamente navegando por PowerShell Gallery. Una vez identificado el módulo que te interesa (por ejemplo, xWebAdministration o SqlServerDsc), tienes varias formas de instalarlo en tus hosts:

• Instalación manual con Install-Module desde PowerShell en el servidor objetivo.
• Uso del módulo de Ansible win_psmodule para automatizar la instalación desde PowerShell Gallery.
• Descarga previa y copia a mano a los servidores que no tienen acceso a Internet, guardando el módulo en un directorio incluido en PSModulePath (por ejemplo, C:\Program Files\WindowsPowerShell\Modules).

Cuando trabajas en entornos desconectados, una estrategia común es usar un servidor con salida a Internet para guardar el módulo con Save-Module en una ruta local, y luego copiar ese directorio a los equipos de producción. Después, la configuración de PSModulePath se puede ajustar también con Ansible, por ejemplo, con el módulo win_path, para que PowerShell detecte esos recursos sin intervención manual.

Una vez instalados, el módulo win_dsc puede invocar cualquier recurso de esos paquetes simplemente indicando el nombre en resource_name. Esto te abre la puerta a reutilizar soluciones muy maduras, como los módulos de Active Directory DSC, para tareas como crear usuarios, OU, grupos o configurar políticas, todo ello gestionado desde tus playbooks.

Por si fuera poco, existe incluso un módulo de PowerShell que permite generar automáticamente módulos Ansible a partir de recursos DSC. La idea es inspeccionar el recurso DSC, crear un módulo Ansible que mapee sus parámetros uno a uno y utilizarlo como si fuera un módulo estándar. Estos generadores pueden descargar recursos desde PowerShell Gallery y crear decenas de módulos que amplían todavía más el ecosistema de automatización de Windows con Ansible.

Más allá de DSC y Ansible: otras herramientas de automatización en Azure

Si tu infraestructura corre (o va a correr) en Azure, conviene tener en el radar otras herramientas que complementan a PowerShell DSC y Ansible. No se trata de elegir una sola, sino de entender cómo encajan en la cadena completa: creación de infraestructura, configuración del sistema, despliegue de aplicaciones y operaciones continuas.

En el ámbito de “infraestructura como código”, soluciones como Terraform o los lenguajes nativos de Azure (ARM Templates y Bicep) permiten definir redes, máquinas virtuales, almacenamiento y servicios gestionados con archivos declarativos. Terraform usa su propio lenguaje HCL, mientras que Bicep simplifica la sintaxis de las antiguas plantillas ARM, pero todos ellos se integran bien en pipelines CI/CD y se pueden combinar con Ansible para la configuración de las máquinas una vez creadas.

Para la fase de configuración inicial de máquinas Linux, Azure soporta cloud-init, que ejecuta scripts y configura usuarios, paquetes o archivos de configuración en el primer arranque. Los ficheros #cloud-config, codificados habitualmente en base64, son independientes de la distribución y se apoyan en el gestor de paquetes propio de cada distro sin que tú tengas que preocuparte.

En el terreno de la automatización operativa, Azure Automation juega un papel interesante. Usa runbooks (generalmente scripts de PowerShell o Python) que se pueden ejecutar bajo demanda o según una programación, tanto en recursos de Azure como en entornos on-premise usando Hybrid Runbook Worker. Además, ofrece un servicio de DSC gestionado que permite publicar configuraciones y supervisar el cumplimiento en un conjunto de máquinas.

Por último, herramientas de CI/CD y gestión del ciclo de vida de la aplicación como Azure DevOps, Jenkins, Chef, Puppet o Packer completan el ecosistema. Cada una cubre un trozo del puzzle: desde compilar y testear código hasta generar imágenes de máquina personalizadas o garantizar el cumplimiento normativo mediante tests automatizados.

Actualizaciones de Windows, paquetes y gestión de aplicaciones

Una de las tareas más críticas en cualquier equipo de sistemas es mantener Windows al día con sus parches y actualizaciones. Microsoft ofrece Windows Update y, en muchos entornos corporativos, Microsoft Configuration Manager (SCCM) para gestionar el despliegue. Sin embargo, cuando entran en juego reinicios múltiples, ventanas de mantenimiento ajustadas o requisitos de orquestación complejos, estos mecanismos pueden quedarse cortos o resultar poco fiables.

Ansible Automation Platform facilita la ejecución controlada de actualizaciones, integrándose con Windows Update y gestionando automáticamente los reinicios que hagan falta, de forma que una sola tarea pueda instalar decenas o cientos de parches manteniendo el control sobre el estado final de los nodos.

En cuanto a la instalación de aplicaciones, Windows no dispone de un gestor de paquetes nativo unificado al estilo de las distribuciones Linux. La Microsoft Store no está pensada para automatizar despliegues masivos: carece de herramientas CLI maduras y depende en gran medida de la interfaz gráfica, lo que dificulta su uso en pipelines automatizados.

Para paliar esa carencia, Ansible integra módulos que permiten gestionar paquetes en Windows de forma básica y, sobre todo, se lleva muy bien con soluciones como Chocolatey o winget en Windows, que aporta un enfoque idempotente al estilo de un gestor de paquetes clásico. Combinando Chocolatey, DSC y playbooks de Ansible puedes estandarizar catálogos de software para servidores o VDI con muy poco esfuerzo manual.

Si a esto le sumas el uso de recursos DSC para forzar configuraciones de registro, servicios y políticas relacionadas con esas aplicaciones, consigues una automatización integral del ciclo de vida del software en tus entornos Windows, desde la instalación inicial hasta el endurecimiento de la configuración y las actualizaciones periódicas.

Formación, buenas prácticas y adopción en equipos de Windows

En muchos equipos de TI puramente Windows el punto de partida sigue siendo la administración a base de clics sobre la consola gráfica y asistentes. Es habitual tener decenas o cientos de máquinas virtuales montadas sobre VMware o Hyper-V, donde el proceso de creación de servidores se realiza de forma manual. El salto a la automatización suele venir cuando alguien del equipo se cansa de repetir siempre lo mismo y empieza a montar scripts de PowerShell.

En ese contexto surge la duda razonable: “¿sigo tirando de PowerShell a pelo, doy el paso a DSC, monto Ansible… o todo a la vez?”. La respuesta más pragmática suele ser combinar: aprovechar el conocimiento existente de PowerShell y DSC y, al mismo tiempo, introducir Ansible como capa de orquestación para ir ganando en estandarización y capacidad de integración con otras plataformas.

Existen cursos específicos para administradores de Windows que parten de cero en Ansible y se centran precisamente en esto: cómo configurar sistemas Windows para que se gestionen con Ansible, cómo escribir playbooks eficaces, cómo integrar Ansible Tower o AWX para lanzar las automatizaciones desde una interfaz web centralizada y segura, y cómo reutilizar código DSC desde estos playbooks para no tirar por la borda el trabajo ya hecho.

En la práctica, muchos equipos adoptan una estrategia evolutiva: empezar automatizando tareas sencillas (servicios, roles, instalación de módulos de PowerShell), seguir con recursos DSC para configuraciones repetitivas (IIS, AD, SQL, políticas de seguridad) y, poco a poco, ir integrando la automatización en el pipeline de entrega de aplicaciones y en las tareas recurrentes de operación.

Es importante también definir pautas de estilo, control de código fuente y testing de los playbooks y configuraciones DSC, de forma que la automatización se convierta en “infraestructura como código” de verdad y no en un puñado de scripts sueltos sin control de versiones ni revisiones.

Al combinar PowerShell DSC, módulos Ansible, WinRM, Chocolatey y las herramientas de Azure, se consigue un ecosistema sólido donde la creación de máquinas, su configuración detallada, el despliegue de aplicaciones y su mantenimiento continuo dejan de depender de sesiones RDP manuales. El resultado es un entorno más consistente, auditable y fácil de reproducir, donde los cambios se documentan automáticamente en forma de código y los errores humanos se reducen de manera drástica.