Напредна аутоматизација у Windows-у са PowerShell DSC-ом и Ansible-ом

Информатек Дигитал » Средства » Напредна аутоматизација у Windows-у са PowerShell DSC-ом и Ansible-ом

Ако радите са Windows инфраструктурама и терминима као што су PowerShell, DSC, Ansible и аутоматизацијаВероватно већ сумњате да њихово ефикасно комбиновање може потпуно променити начин на који управљате серверима. Прелазак са ручних кликова у Windows чаробњаку на потпуно декларативну и понављајућу конфигурацију прави сву разлику између сталног гашења пожара и потпуно контролисаног окружења.

У овом чланку ћемо детаљније размотрити како Конфигурација жељеног стања PowerShell-а (DSC) и Ansible се уклапају заједно Да бисте управљали Windows-ом (и Linux-ом) у великим размерама, какву улогу играју технологије попут WinRM-а, Azure Automation-а, Terraform-а или cloud-init-а и како можете искористити постојеће DSC ресурсе из Ansible-а захваљујући модулу? win_dscВидећете практичне примере, случајеве употребе из стварног света и критеријуме за одлучивање када користити нативни DSC, Ansible модуле или друге приступе аутоматизацији.

Преглед: Аутоматизација Windows-а помоћу PowerShell-а, DSC-а и Ansible-а

PowerShell и Ansible теже истом циљуАутоматизација конфигурације и администрирања ваших система на поновљив начин. Разлика лежи у приступу. DSC је платформа за управљање конфигурацијом интегрисана у PowerShell, у великој мери фокусирана на Windows (иако може да ради са Linux-ом преко OMI-ја), док је Ansible вишенаменски, кросплатформски механизам за аутоматизацију дизајниран за оркестрирање хибридних и хетерогених инфраструктура са једне тачке.

са Ред Хат Ансибле Аутоматион Платформ Можете аутоматизовати Windows сервере без инсталирања додатних агената, користећи WinRM или OpenSSH као што су канали за повезивање и коришћењем DSC ресурса, Ansible модула и PowerShell скрипти. Све је ово организовано кроз YAML приручницигде дефинишете које стање сваки хост треба да достигне, како у Windows-у тако и у Linux-у.

Конфигурација жељеног стања PowerShell-а, са своје стране, нуди стотине специјализованих ресурса да конфигуришете скоро сваку Windows компоненту: сервисе, системске функције, IIS, SQL Server, Active Directory, регистар, датотеке итд. Ови ресурси обухватају логику провере и примене жељеног стања, тако да ви само декларишете „како желите да машина буде“.

Кључно је то што из Ansible-а можете користити те DSC ресурсе директно кроз модул ansible.windows.win_dscКомбиновањем снаге оркестрације коју нуди Ansible са дубином конфигурације специфичном за Windows коју нуди DSC. На овај начин постижете Најбоље од оба света без дуплирања напора.

WinRM и удаљени приступ Windows-у за Ansible

Да би Ansible могао да управља Windows серверима, неопходно је разумети како функционише WinRM (Удаљено управљање Windows-ом)ВинРМ је Мајкрософтова уграђена технологија за даљинско администрирање засновано на ХТТП/ХТТПС протоколу и то је уобичајени канал који Ансибле користи за покретање задатака на Виндоус машинама.

Први корак је Правилно конфигуришите WinRM на циљним хостовима и у контролном чвору где се покреће Ansible. Ово укључује подешавање аутентификације, шифровања, дозвола и, врло често, бављење особеностима као што је неинтерактивно пријављивање, где се команде покрећу без активне корисничке сесије. Овај неинтерактивни контекст сесије компликује задатке као што су Ажурирања за Windows или сценарији двоструке аутентификације, где вам је потребан приступ другом удаљеном ресурсу (на пример, дељеном ресурсу на другом серверу).

Предност коришћења Red Hat Ansible Automation Platform је у томе што вам омогућава да кодирање акредитива и механизми за аутентификацију централизовано и безбедно, тако да је обрада ових сложених случајева у великој мери апстрахована. Штавише, платформа може да користи и OpenSSH за приступ Windows Server-у, нешто што постаје све чешће са модерним верзијама оперативног система Windows.

У пракси, комбиновање WinRM-а, Ansible-овог управљања акредитивима и DSC могућности вам омогућава да изградите робусни аутоматизовани токови рада који раде без надзора, чак и у окружењима са високим безбедносним ограничењима.

PowerShell DSC: Декларативна платформа за конфигурацију

Конфигурација жељеног стања PowerShell-а је декларативна платформа за управљање конфигурацијом Интегрисано у Windows. Помоћу DSC-а дефинишете, у коду, како машина треба да буде конфигурисана: које улоге и функције треба да буду инсталиране, које услуге треба да буду активне, који параметри регистра, које датотеке или директоријуми треба да постоје итд.

Тхе DSC конфигурације описују жељено стање за скуп чворова. На сваком управљаном уређају, LCM (Локални менаџер конфигурације)што је механизам који чита те конфигурације, проверава стварно стање и примењује потребне измене. Поред тога, можете монтирати повлачење сервера који централизује конфигурације и из којег чворови ажурирају и извештавају о усклађености.

DSC није ограничен само на Windows: путем отвореног сервера инфраструктуре за управљање (ОМИ), такође може да ради са Линукс машинеМеђутим, тамо где заиста сија јесте у Windows окружењима, где је заједница развила велику колекцију специјализованих ресурса за задатке разноврсне као што су конфигуришите IIS, SQL Server или Active Directory.

Једна од великих предности DSC-а је то што Фокусира се на резултат, а не на кораке.Декларишете стање (на пример, „ова функција мора бити присутна, ова услуга мора бити покренута, ова вредност регистра конфигурисана“) и механизам се брине да стигне до њега, проверавајући и исправљајући ако нешто одступа током времена.

Како се Ansible уклапа са DSC-ом: win_dsc модул и оркестрација

У теорији бисте могли користити DSC изоловано, али у пракси је много кориснији када се комбинује са Ansible као слој за оркестрацијуAnsible се бави инвентаром, уредним извршавањем задатака, координацијом између система и интеграцијом са CI/CD цевоводима, док DSC пружа специфични ресурси за упознавање са утробом Windows-а.

Модул ansible.windows.win_dsc То је мост између два света. Овај модул позива DSC класа ресурса на циљном Windows хосту. У приручнику, потребно је само да дефинишете:

• име_ресурса: име DSC ресурса који желите да користите (на пример, File, WindowsFeature, Service, Registry, xWebsite, Итд).
• Преостали параметри, који директно одговарају својства DSC ресурса (на пример, DestinationPath, Ensure, Name, State, Итд).

Када Ansible изврши задатак, он преводи те параметре у привремену DSC конфигурацију, примењује је на хост и сакупи резултат (укључујући и да ли је дошло до било каквих промена). На овај начин можете поново користите цео DSC каталог ресурса без потребе за писањем посебних Ansible модула за сваки случај.

У наставку, ток извршавања прати доследан образац: Ansible шаље задатак преко WinRM-а, Windows систем генерише DSC конфигурацију на основу параметара, DSC механизам прво позива Test-TargetResource да провери тренутни статус и, ако открије разлике, извршава Set-TargetResource да би се примениле промене. Ansible прима извештај који показује да ли је нешто измењено и све релевантне поруке за отклањање грешака.

Ова спрега је посебно снажна када се комбинује Ansible нативни модули за Windows (као што су win_file, win_service, win_regedit, win_psmoduleитд.) са DSC ресурсима за она подручја где DSC нуди финије опције или већу функционалну покривеност.

Врсте DSC својстава и како их мапирати у Ansible-у

Сваки DSC ресурс дефинише скуп својстава са добро дефинисан тип (стрингови, булове вредности, низови, сложени PowerShell типови итд.). Када радите из Ansible-а, морате да преведете та својства у YAML синтакса Одржавање исправног типа. Модул win_dsc Ради доста аутоматске конверзије, али вреди знати неке кључне случајеве.

За једноставне типове као што су o , мапирање је једноставно: низови под наводницима и мали логички изрази у YAML стилу (true, false), избегавајући писање $true o $false као што бисте то урадили у PowerShell-у. За својства типа , уобичајена ствар је да се користи ISO 8601 формат (на пример, "2019-02-22T13:57:31Z") и уверите се да је вредност серијализована као стринг, тако што ћете је ставити под наводнике.

Својства типа Они су посебан случај. Пошто се овај тип не може директно серијализовати у JSON, Ansible користи конвенцију: дефинишете два параметра одвојена суфиксом. _username y _password (на пример, Credential_username y Credential_passwordМодул генерише објекат. PSCredential на удаљеном хосту на основу те две вредности.

За типове Они представљају речнике засноване на прилагођеној класи ресурса; у YAML-у су изражени као мапа кључ-вредност. Требало би да прегледате документацију ресурса (обично у датотеци). <nombre_recurso>.schema.mof) да би се знало који су кључеви дозвољени и ког је типа сваки од њих. У пракси су дефинисани као угнежђени речници унутар модула win_dsc.

Коначно, својства типа и низови (], ]итд.) су представљени као речници или YAML листе. За низове се препоручује коришћење аутентична YAML листа а не стринг са вредностима раздвојеним зарезима, јер се тиме избегава ручно парсирање и смањује вероватноћа суптилних грешака.

Практични примери коришћења DSC-а из Ansible-а

Када савладате основну структуру модула win_dscМожете комбиновати ресурсе за изградњу веома свеобухватне приручнике за конфигурацијуНеки уобичајени сценарији који добро функционишу са DSC-ом су:

• Управљање датотекама и директоријумима са ресурсом File: креирање структура фолдера, распоређивање конфигурационих датотека са одређеним садржајем, осигуравање да одређени елементи постоје или су уклоњени.
• Инсталирање Windows улога и функција са WindowsFeatureIIS, .NET Framework, Telnet клијент, алати за администрацију итд.
• Контрола услуга са ресурсом Service: статус (покренуто/заустављено), тип покретања (аутоматско, ручно), налог сервиса итд.
• Подешавања регистра са Registryбезбедносне вредности, времена чекања, параметри протокола, јачање система.
• Напредна подешавања IIS-а са модулима као што су xWebAdministration и ресурса xWebsite, xWebAppPool, Итд

У свим овим случајевима, Ansible једноставно описује параметре DSC ресурса, док DSC мотор је одговоран за проверу и примену држава. Штавише, почевши од Ansible 2.8, модул win_dsc Аутоматски валидира параметре у односу на дефиницију ресурса: ако користите погрешно име својства, оставите обавезно поље празно или проследите вредност ван опсега, задатак ће неуспешно завршити са јасном грешком.

Ако покренете Ansible са висок ниво говорљивости (на пример, -vvv)Излаз ће садржати детаљне информације у invocation.module_args о коришћеним опцијама и онима које су биле доступне, што је веома корисно и за дебаговање и за откривање која поља можете конфигурисати у сваком ресурсу.

Такође имајте на уму да можете користити параметар PsDscRunAsCredential Ово омогућава DSC ресурсу да се покреће као други корисник у односу на систем. Ово је веома корисно за приступ регистрационом саћу. HKEY_CURRENT_USER корисника са којим је Ansible повезан или за сценарије где вам је потребан одређени безбедносни контекст.

Прилагођени DSC ресурси и PowerShell галерија

DSC ресурси интегрисани са Windows-ом покривају многе потребе, али права моћ се јавља када користите Ресурси објављени у PowerShell галерији или из пакета трећих страна. Постоје модули за све: Active Directory, SQL Server, напредни IIS, безбедносне политике итд.

Можете открити доступне ресурсе помоћу командлета Find-DscResource или директним прегледањем PowerShell галерије. Када идентификујете модул који вас занима (на пример, xWebAdministration o SqlServerDsc), имате неколико начина да га инсталирате на своје хостове:

• Ручна инсталација са Install-Module из PowerShell-а на циљном серверу.
• Коришћење Ansible модула win_psmodule да аутоматизујете инсталацију из PowerShell галерије.
• Преузмите унапред и копирајте ручно на сервере који немају приступ интернету, чувајући модул у директоријуму који је укључен у PSModulePath (на пример, C:\Program Files\WindowsPowerShell\Modules).

Приликом рада у неповезаним окружењима, уобичајена стратегија је коришћење сервера са приступом интернету сачувајте модул са Save-Module у локалној путањи, а затим копирајте тај директоријум на производне машине. Након тога, конфигуришите PSModulePath Такође се може подесити помоћу Ansible-а, на пример, помоћу модула win_pathтако да PowerShell може да детектује те ресурсе без ручне интервенције.

Једном инсталиран, модул win_dsc може позвати било који ресурс из тих пакета једноставно навођење имена у resource_nameОво отвара врата за поновну употребу добро успостављених решења, као што су DSC модули Active Directory-ја, за задатке као што су креирајте кориснике, организацијске јединице, групе или конфигуришите политикесве се управља из ваших сценарија.

Као да то није довољно, постоји чак и PowerShell модул који то омогућава Аутоматски генеришите Ansible модуле из DSC ресурсаИдеја је да се прегледа DSC ресурс, креира Ansible модул који мапира његове параметре један-на-један и користи га као да је стандардни модул. Ови генератори могу да преузму ресурсе из PowerShell галерије и креирају десетине модула који додатно проширују Windows екосистем аутоматизације помоћу Ansible-а.

Поред DSC-а и Ansible-а: други алати за аутоматизацију у Azure-у

Ако ваша инфраструктура ради (или ће радити) на Azure-у, вреди обратити пажњу на друге алате који је допуњују. PowerShell DSC и AnsibleНе ради се о избору само једног, већ о разумевању како се они уклапају у цео ланац: креирање инфраструктуре, конфигурација система, имплементација апликација и текуће операције.

У области „инфраструктуре као кода“, решења као што су Терраформ или изворни језици Azure-а (ARM шаблони и Bicep) дозвољавају дефинишите мреже, виртуелне машине, складиште и управљане сервисе са декларативним датотекама. Terraform користи сопствени HCL језик, док Bicep поједностављује синтаксу старијих ARM шаблона, али сви се добро интегришу у CI/CD цевоводе и могу се комбиновати са Ansible-ом за конфигурисање машина након што се креирају.

За фазу почетна конфигурација Linux машинаAzure подржава цлоуд-иниткоји извршава скрипте и конфигурише кориснике, пакете или конфигурационе датотеке при првом покретању. Датотеке #cloud-config, обично кодирани у base64, независни су од дистрибуције и ослањају се на сопствени менаџер пакета сваке дистрибуције без потребе да бринете.

У области оперативна аутоматизацијаAzure Automation игра занимљиву улогу. Користи књиге задатака (углавном PowerShell или Python скрипте) које се могу покретати на захтев или према распореду, како у Azure ресурсима, тако и у локалним окружењима користећи Hybrid Runbook Worker. Такође нуди услугу за управљани DSC што омогућава објављивање конфигурација и праћење усклађености на више машина.

Коначно, CI/CD и алати за управљање животним циклусом апликација као што су Azure DevOps, Jenkins, Chef, Puppet или Packer Они употпуњују екосистем. Сваки од њих покрива део слагалице: од компајлирања и тестирања кода до генерисања прилагођених слика машина или обезбеђивања усклађености са прописима путем аутоматизованих тестова.

Управљање ажурирањима, пакетима и апликацијама за Windows

Један од најкритичнијих задатака у сваком системском тиму је Одржавајте Windows ажурираним помоћу закрпа и исправкиМајкрософт нуди Windows Update и, у многим корпоративним окружењима, Microsoft Configuration Manager (SCCM) за управљање имплементацијом. Међутим, када се појаве вишеструка поновна покретања, кратки рокови за одржавање или сложени захтеви за оркестрацију, ови механизми могу бити неефикасни или непоуздани.

Ансибл платформа за аутоматизацију олакшава контролисано извршавање ажурирањаинтеграција са Windows Update-ом и аутоматско управљање свим потребним поновним покретањима, тако да један задатак може да инсталира десетине или стотине закрпа одржавање контроле над коначним стањем чворова.

Што се тиче инсталације апликација, Windows нема обједињени менаџер нативних пакета У стилу Линук дистрибуција, Мајкрософт продавница није дизајнирана за аутоматизацију масовних имплементација: недостају јој зрели CLI алати и у великој мери се ослања на графички интерфејс, што отежава употребу у аутоматизованим цевоводима.

Да би се решио овај недостатак, Ansible интегрише модуле који омогућавају Управљање пакетима у оперативном систему Windows На основни начин, и пре свега, веома добро функционише са решењима као што су Чоколадни или крило на Windows-ушто доноси идемпотентни приступ стилу класичног менаџера пакета. Комбиновањем плејбукова Chocolatey, DSC и Ansible, можете стандардизовати каталози серверског или VDI софтвера уз врло мало ручног напора.

Ако овоме додате коришћење DSC ресурса за принудно наметање конфигурација регистра, услуга и политика везаних за те апликације, добијате свеобухватна аутоматизација животног циклуса софтвера у вашим Windows окружењима, од почетне инсталације до конфигурација заштите и редовних ажурирања.

Обука, најбоље праксе и усвајање у Windows тимовима

У многим искључиво Windows ИТ тимовима, почетна тачка остаје администрација заснована на кликовима о графичкој конзоли и чаробњацима. Уобичајено је да десетине или стотине виртуелних машина раде на VMware-у или Hyper-V-у, где се процес креирања сервера обавља ручно. Прелазак на аутоматизацију обично долази када се неко у тиму умори од понављања исте ствари и почне да подешава сопствене виртуелне машине. поверсхелл скрипте.

У овом контексту, поставља се разумно питање: „Да ли да наставим да користим само PowerShell, да пређем на DSC, да подесим Ansible… или да урадим све одједном?“ Најпрагматичнији одговор је обично комбиновање: искористите постојеће знање о PowerShell-у и DSC-у и, истовремено, увести Ansible као слој оркестрације како би се стекле могућности стандардизације и интеграције са другим платформама.

Тамо посебни курсеви за Windows администраторе који почињу од нуле у Ansible-у и фокусирају се управо на ово: како конфигурисати Windows системе за управљање помоћу Ansible-а, како писати ефикасне плејбукове, како интегрисати Ансибл Тауер или AWX покретање аутоматизација са централизованог и безбедног веб интерфејса и како поново користити DSC код из ових приручника како се не би бацио већ обављени посао.

У пракси, многи тимови усвајају еволутивну стратегију: почевши од аутоматизације једноставних задатака (сервиси, улоге, инсталација PowerShell модула), настављајући са DSC ресурсима за понављајуће конфигурације (IIS, AD, SQL, безбедносне политике) и постепено интегришући аутоматизацију у процес испоруке апликација и понављајуће оперативне задатке.

Такође је важно дефинисати смернице за стил, контрола изворног кода и тестирање DSC сценарија и конфигурација, тако да аутоматизација постане права „инфраструктура као код“, а не само шачица лабавих скрипти без контроле верзија или ревизија.

комбиновањем PowerShell DSC, Ansible модули, WinRM, Chocolatey и Azure алатиОво резултира робусним екосистемом где креирање машина, детаљна конфигурација, имплементација апликација и текуће одржавање више не зависе од ручних RDP сесија. Резултат је конзистентније, ревидираније и репродуцибилније окружење где се промене аутоматски документују у коду, а људске грешке су драстично смањене.