Automatització avançada a Windows amb PowerShell DSC i Ansible

Informatec Digital » Recursos » Automatització avançada a Windows amb PowerShell DSC i Ansible

Si treballes amb infraestructures Windows i et sonen termes com PowerShell, DSC, Ansible i automatització , segurament ja intueixes que combinar bé pot canviar per complet la teva forma d'administrar servidors. Passar dels clics manuals a l'assistent de Windows a una configuració totalment declarativa i repetible marca la diferència entre anar apagant focs o tenir un entorn sota control.

En aquest article aprofundirem en com PowerShell Desired State Configuration (DSC) i Ansible encaixen junts per gestionar Windows (i també Linux) a escala, quin paper juguen tecnologies com WinRM, Azure Automation, Terraform o cloud-init, i com pots donar suport als recursos DSC existents des d'Ansible gràcies al mòdul win_dsc. Veureu exemples pràctics, casos d'ús reals i criteris per decidir quan estirar DSC nadiu, de mòduls Ansible o d'altres enfocaments d'automatització.

Panorama general: automatització de Windows amb PowerShell, DSC i Ansible

PowerShell i Ansible persegueixen el mateix objectiu : automatitzar la configuració i administració dels teus sistemes de forma reproduïble. La diferència rau en l'enfocament. DSC és la plataforma de gestió de configuració integrada a PowerShell, molt centrada en Windows (encara que pot treballar amb Linux mitjançant OMI), mentre que Ansible és un motor d'automatització multipropòsit i multiplataforma, pensat per orquestrar des d'un únic punt infraestructures híbrides i heterogènies.

Amb Red Hat Ansible Automation Platform pots automatitzar servidors Windows sense instal·lar agents addicionals, aprofitant WinRM o OpenSSH com a canals de connexió i recolzant-te en recursos DSC, mòduls d'Ansible i scripts de PowerShell. Tot això s'organitza a través de playbooks a YAML , on defineixes quin estat ha d'assolir cada host, tant a Windows com a Linux.

PowerShell Desired State Configuration, per la seva banda, ofereix centenars de recursos especialitzats per configurar gairebé qualsevol component de Windows: serveis, característiques del sistema, IIS, SQL Server, Active Directory, registre, fitxers, etc. Aquests recursos encapsulen la lògica de comprovar i aplicar l'estat desitjat, de manera que només declares “com vols que estigui” la màquina.

La clau és que, des d'Ansible, pots utilitzar aquests recursos DSC de forma directa mitjançant el mòdul ansible.windows.win_dsc, combinant la potència d'orquestració d'Ansible amb la profunditat de configuració específica de Windows que ofereix DSC. D'aquesta manera aconsegueixes el millor dels dos mons sense duplicar esforços.

WinRM i accés remot a Windows per a Ansible

Perquè Ansible pugui gestionar servidors Windows, és fonamental entendre com funciona WinRM (Windows Remote Management) . WinRM és la tecnologia integrada de Microsoft per a administració remota basada en HTTP/HTTPS, i és el canal habitual que Ansible utilitza per executar tasques en equips Windows.

El primer pas és configurar WinRM correctament als hosts destinació i al node de control on corre Ansible. Això implica ajustar autenticació, xifrat, permisos i, molt sovint, bregar amb particularitats com l'inici de sessió no interactiu, on les ordres es llancen sense una sessió d'usuari activa. Aquest context sense sessió interactiva complica tasques com ara actualitzacions de Windows o escenaris de doble salt d'autenticació , on necessiteu accedir a un segon recurs remot (per exemple, un recurs compartit en un altre servidor).

L'avantatge d'utilitzar Red Hat Ansible Automation Platform és que us permet codificar credencials i mecanismes d'autenticació de forma centralitzada i segura, de manera que el maneig d'aquests casos complexos quedi abstret en gran mesura. A més, la plataforma també pot utilitzar OpenSSH per accedir a Windows Server , una cosa cada vegada més comuna amb les versions modernes de Windows.

A la pràctica, combinar WinRM, la gestió de credencials d'Ansible i les capacitats de DSC us permet construir fluxos d'automatització robustos que s'executen sense supervisió, fins i tot en entorns amb elevades restriccions de seguretat.

PowerShell DSC: plataforma de configuració declarativa

PowerShell Desired State Configuration és una plataforma declarativa de gestió de configuració integrada al Windows. Amb DSC defineixes, en codi, com ha d'estar configurada una màquina: quins rols i característiques han d'estar instal·lats, quins serveis actius, quins paràmetres de registre, quins fitxers o directoris han d'existir, etc.

Les configuracions DSC descriuen l'estat que voleu per a un conjunt de nodes. A cada equip gestionat s'executa un local Configuration Manager (LCM) , que és el motor que llegeix aquestes configuracions, comprova l'estat real i aplica els canvis necessaris. A més, podeu muntar un servidor d'extracció (pull server) que centralitza les configuracions i des del qual els nodes s'actualitzen i reporten compliment.

DSC no es limita a Windows: mitjançant el servidor d'infraestructura de gestió oberta ( OMI ), també pot treballar amb màquines Linux . Això sí, on brilla amb diferència és en entorns Windows, on la comunitat ha desenvolupat una gran col·lecció de recursos especialitzats per a tasques tan variades com configurar IIS, SQL Server o Active Directory.

Un dels grans avantatges de DSC és que se centra en el resultat, no en els passos . Tu declares l'estat (per exemple, “aquesta característica ha de ser present, aquest servei iniciat, aquest valor de registre configurat”) i el motor s'encarrega d'arribar-hi, comprovant i corregint si es desvia alguna cosa amb el temps.

Com encaixa Ansible amb DSC: mòdul win_dsc i orquestració

En teoria podries fer servir DSC de forma aïllada, però a la pràctica resulta molt més útil quan ho combines amb Ansible com a capa d'orquestració . Ansible s'encarrega de l'inventari, l'execució ordenada de tasques, la coordinació entre sistemes i la integració amb pipelins CI/CD, mentre que DSC aporta els recursos concrets per tocar els budells de Windows.

el mòdul ansible.windows.win_dsc és el pont entre tots dos mons. Aquest mòdul invoca una classe de recurs DSC al host Windows de destinació. Al playbook únicament has de definir:

• resource_name: el nom del recurs DSC que vols utilitzar (per exemple, File, WindowsFeature, Service, Registry, xWebsite, Etc).
• La resta de paràmetres, que corresponen directament amb les propietats del recurs DSC (Per exemple, DestinationPath, Ensure, Name, State, Etc).

Quan Ansible executa la tasca, tradueix aquests paràmetres en una configuració DSC temporal, l'aplica al host i recull el resultat (incloent-hi si s'han produït canvis o no). D'aquesta manera podeu reutilitzar tot el catàleg de recursos DSC sense haver d'escriure mòduls Ansible específics per a cada cas.

Per sota, el flux dexecució segueix un patró coherent: Ansible envia la tasca via WinRM, el sistema Windows genera una configuració DSC en funció dels paràmetres, el motor DSC crida primer a Test-TargetResource per comprovar l'estat actual, i si detecta diferències executa Set-TargetResource per aplicar els canvis. Ansible rep un informe de si s'ha modificat alguna cosa i qualsevol missatge rellevant per a la depuració.

Aquest acoblament és especialment potent quan combines mòduls nadius d'Ansible per a Windows (com win_file, win_service, win_regedit, win_psmodule, etc.) amb recursos DSC per a aquelles àrees on DSC ofereix opcions més fines o una cobertura funcional més gran.

Tipus de propietats DSC i com mapejar-les a Ansible

Cada recurs DSC defineix un conjunt de propietats amb un tipus ben especificat (string, booleà, arrays, tipus complexos de PowerShell, etc.). Quan treballes des d'Ansible, has de traduir aquestes propietats a sintaxi YAML mantenint el tipus correcte. El mòdul win_dsc fa molta feina de conversió automàtica, però convé conèixer alguns casos clau.

Per a tipus senzills com o , el mapeig és directe: cadenes entre cometes i booleans en minúscula a l'estil YAML (true, false), evitant escriure $true o $false com faries a PowerShell. Per a propietats de tipus , l'habitual és fer servir un format ISO 8601 (Per exemple, "2019-02-22T13:57:31Z") i assegurar-te que el valor se serialitza com a cadena, envoltant-lo de cometes.

Les propietats de tipus són un cas especial. Com que aquest tipus no es pot serialitzar directament a JSON, Ansible empra una convenció: defineix dos paràmetres separats amb sufix _username y _password (Per exemple, Credential_username y Credential_password). El mòdul genera l'objecte PSCredential a l'amfitrió remot a partir d'aquests dos valors.

Per a tipus , que representen diccionaris basats en una classe personalitzada del recurs, a YAML s'expressen com un mapa de clau-valor. Has de revisar la documentació del recurs (normalment al fitxer <nombre_recurso>.schema.mof) per saber quines claus estan permeses i quin tipus té cadascuna. A la pràctica es defineixen com diccionaris niats dins del mòdul win_dsc.

Finalment, les propietats de tipus i els arrays (], ], etc.) es representen com a diccionaris o llistes YAML. Per als arrays es recomana fer servir una llista YAML autèntica i no una cadena amb valors separats per comes, perquè així s'evita parsing manual i es redueix la probabilitat d'errors subtils.

Exemples pràctics dús de DSC des dAnssible

Un cop domines l'estructura bàsica del mòdul win_dsc, pots combinar recursos per construir playbooks de configuració molt complets. Alguns escenaris habituals que encaixen molt bé amb DSC són:

• Gestió de fitxers i directoris amb el recurs File: creació d'estructures de carpetes, desplegament de fitxers de configuració amb contingut concret, assegurar-se que certs elements existeixen o s'han eliminat.
• Instal·lació de rols i característiques de Windows amb WindowsFeature: IIS, .NET Framework, Telnet Client, eines d'administració, etc.
• Control de serveis amb el recurs Service: estat (iniciat/detingut), tipus d'inici (automàtic, manual), compte de servei, etc.
• Configuració del registre amb Registry: valors de seguretat, temps d'espera, paràmetres de protocols, enduriment del sistema.
• Configuracions avançades d'IIS amb mòduls com xWebAdministration i recursos xWebsite, xWebAppPool, Etc

En tots aquests casos, Ansible es limita a descriure els paràmetres del recurs DSC, mentre que el motor de DSC s'encarrega de comprovar i aplicar l'estat. A més, a partir d'Ansible 2.8 el mòdul win_dsc valida automàticament els paràmetres davant de la definició del recurs: si fas servir un nom de propietat incorrecte, et deixes un obligatori sense omplir o passes un valor fora de rang, la tasca fallarà amb un error clar.

Si executes Ansible amb un nivell de verbositat alt (per exemple, -vvv), la sortida inclourà informació detallada a invocation.module_args sobre les opcions utilitzades i les que estaven disponibles, cosa que resulta molt útil tant per depurar com per descobrir quins camps pots configurar a cada recurs.

Tingues en compte també que pots fer servir el paràmetre PsDscRunAsCredential perquè el recurs DSC s'executi com un altre usuari diferent del sistema. Això és molt pràctic per accedir al rusc de registre HKEY_CURRENT_USER de l'usuari amb què es va connectar Ansible o per a escenaris on necessites un context de seguretat concret.

Recursos DSC personalitzats i PowerShell Gallery

Els recursos DSC integrats amb Windows cobreixen moltes necessitats, però la veritable potència apareix quan recorres a recursos publicats a PowerShell Gallery o de paquets creats per tercers. Hi ha mòduls per a tot: Active Directory, SQL Server, IIS avançat, polítiques de seguretat, etc.

Pots descobrir recursos disponibles amb el cmdlet Find-DscResource o directament navegant per PowerShell Gallery. Un cop identificat el mòdul que t'interessa (per exemple, xWebAdministration o SqlServerDsc), tens diverses maneres d'instal·lar-lo als teus hosts:

• Instal·lació manual amb Install-Module des de PowerShell al servidor objectiu.
• Ús del mòdul Ansible win_psmodule per automatitzar la instal·lació des de PowerShell Gallery.
• Descàrrega prèvia i còpia a mà als servidors que no tenen accés a Internet, guardant el mòdul en un directori inclòs a PSModulePath (Per exemple, C:\Program Files\WindowsPowerShell\Modules).

Quan treballes en entorns desconnectats, una estratègia comuna és fer servir un servidor amb sortida a Internet per guardar el mòdul amb Save-Module en una ruta local, i després copiar aquest directori als equips de producció. Després, la configuració de PSModulePath es pot ajustar també amb Ansible, per exemple, amb el mòdul win_path, perquè PowerShell detecti aquests recursos sense intervenció manual.

Un cop instal·lats, el mòdul win_dsc podeu invocar qualsevol recurs d'aquests paquets simplement indicant el nom a resource_name. Això us obre la porta a reutilitzar solucions molt madures, com els mòduls d'Active Directory DSC, per a tasques com crear usuaris, OU, grups o configurar polítiques, tot això gestionat des dels teus playbooks.

Per si no n'hi hagués prou, existeix fins i tot un mòdul de PowerShell que permet generar automàticament mòduls Ansible a partir de recursos DSC . La idea és inspeccionar el recurs DSC, crear un mòdul Ansible que mapegi els seus paràmetres un per un i utilitzar-lo com si fos un mòdul estàndard. Aquests generadors poden descarregar recursos des de PowerShell Gallery i crear desenes de mòduls que amplien encara més l'ecosistema d'automatització de Windows amb Ansible.

Més enllà de DSC i Ansible: altres eines d'automatització a Azure

Si la teva infraestructura corre (o correrà) a Azure, convé tenir al radar altres eines que complementen PowerShell DSC i Ansible . No es tracta d'escollir-ne una de sola, sinó d'entendre com encaixen a la cadena completa: creació d'infraestructura, configuració del sistema, desplegament d'aplicacions i operacions contínues.

En l'àmbit d'“infraestructura com a codi”, solucions com Terraform o els llenguatges nadius d'Azure (ARM Templates i Bicep) permeten definir xarxes, màquines virtuals, emmagatzematge i serveis gestionats amb fitxers declaratius. Terraform utilitza el seu propi llenguatge HCL, mentre que Bicep simplifica la sintaxi de les antigues plantilles ARM, però tots s'integren bé en pipelins CI/CD i es poden combinar amb Ansible per a la configuració de les màquines una vegada creades.

Per a la fase de configuració inicial de màquines Linux, Azure suporta núvol-init, que executa scripts i configura usuaris, paquets o fitxers de configuració en la primera arrencada. Els fitxers #cloud-config, codificats habitualment en base64, són independents de la distribució i es recolzen en el gestor de paquets propi de cada distro sense que tu t'hagis de preocupar.

En el terreny de l' automatització operativa , Azure Automation hi juga un paper interessant. Usa runbooks (generalment scripts de PowerShell o Python) que es poden executar sota demanda o segons una programació, tant en recursos d'Azure com en entorns on-premise usant Hybrid Runbook Worker. A més, ofereix un servei de DSC gestionat que permet publicar configuracions i supervisar-ne el compliment en un conjunt de màquines.

Finalment, eines de CI/CD i gestió del cicle de vida de l'aplicació com ara Azure DevOps, Jenkins, Xef, Puppet o Packer completen l'ecosistema. Cadascuna cobreix un tros del puzle: des de compilar i testejar codi fins a generar imatges de màquina personalitzades o garantir el compliment normatiu mitjançant tests automatitzats.

Actualitzacions de Windows, paquets i gestió d'aplicacions

Una de les tasques més crítiques en qualsevol equip de sistemes és mantenir Windows al dia amb els seus pegats i actualitzacions . Microsoft ofereix Windows Update i, en molts entorns corporatius, Microsoft Configuration Manager (SCCM) per gestionar el desplegament. Tot i això, quan entren en joc reinicis múltiples, finestres de manteniment ajustades o requisits d'orquestració complexos, aquests mecanismes poden quedar curts o resultar poc fiables.

Ansible Automation Platform facilita l' execució controlada d'actualitzacions , integrant-se amb Windows Update i gestionant automàticament els reinicis que calguin, de manera que una sola tasca pugui instal·lar desenes o centenars de pegats mantenint el control sobre l'estat final dels nodes.

Quant a la instal·lació d'aplicacions, el Windows no disposa d'un gestor de paquets nadiu unificat a l'estil de les distribucions Linux. La Microsoft Store no està pensada per automatitzar desplegaments massius: no té eines CLI madures i depèn en gran mesura de la interfície gràfica, cosa que en dificulta l'ús en pipelins automatitzats.

Per pal·liar aquesta carència, Ansible integra mòduls que permeten gestionar paquets a Windows de forma bàsica i, sobretot, es porta molt bé amb solucions com Chocolatey o winget a Windows , que aporta un enfocament idempotent a l'estil d'un gestor de paquets clàssic. Combinant Chocolatey, DSC i playbooks d'Ansible pots estandarditzar catàlegs de programari per a servidors o VDI amb molt poc esforç manual.

Si a això us sumes l'ús de recursos DSC per forçar configuracions de registre, serveis i polítiques relacionades amb aquestes aplicacions, aconsegueixes una automatització integral del cicle de vida del programari als teus entorns Windows, des de la instal·lació inicial fins a l'enduriment de la configuració i les actualitzacions periòdiques.

Formació, bones pràctiques i adopció en equips de Windows

En molts equips de TI purament Windows el punt de partida continua sent ladministració a base de clics sobre la consola gràfica i assistents. És habitual tenir desenes o centenars de màquines virtuals muntades sobre VMware o Hyper-V, on el procés de creació de servidors es fa de forma manual. El salt a l'automatització sol venir quan algú de l'equip es cansa de repetir sempre el mateix i comença a muntar scripts de PowerShell.

En aquest context sorgeix el dubte raonable: “continuo tirant de PowerShell a cabells, dono el pas a DSC, suma Ansible… o tot alhora?”. La resposta més pragmàtica sol ser combinar: aprofitar el coneixement existent de PowerShell i DSC i alhora introduir Ansible com a capa d'orquestració per anar guanyant en estandardització i capacitat d'integració amb altres plataformes.

Hi ha cursos específics per a administradors de Windows que parteixen de zero a Ansible i se centren precisament en això: com configurar sistemes Windows perquè es gestionin amb Ansible, com escriure playbooks eficaços, com integrar Ansible Tower o AWX per llançar les automatitzacions des d'una interfície web centralitzada i segura i com reutilitzar codi DSC des d'aquests.

A la pràctica, molts equips adopten una estratègia evolutiva: començar automatitzant tasques senzilles (serveis, rols, instal·lació de mòduls de PowerShell), seguir amb recursos DSC per a configuracions repetitives (IIS, AD, SQL, polítiques de seguretat) i, a poc a poc, anar integrant l'automatització al pipeline de lliurament d'aplicacions ia les tasques recurrents d'operació.

És important també definir pautes d'estil, control de codi font i testing dels playbooks i configuracions DSC, de manera que l'automatització es converteixi en infraestructura com a codi de veritat i no en un grapat de scripts solts sense control de versions ni revisions.

En combinar PowerShell DSC, mòduls Ansible, WinRM, Chocolatey i les eines d'Azure , s'aconsegueix un ecosistema sòlid on la creació de màquines, la configuració detallada, el desplegament d'aplicacions i el manteniment continu deixen de dependre de sessions RDP manuals. El resultat és un entorn més consistent, auditable i fàcil de reproduir, on els canvis es documenten automàticament en forma de codi i els errors humans es redueixen de manera dràstica.