Edistynyt automaatio Windowsissa PowerShell DSC:n ja Ansiblen avulla

Informatec Digital » Resurssit » Edistynyt automaatio Windowsissa PowerShell DSC:n ja Ansiblen avulla

Jos työskentelet Windows-infrastruktuurin parissa ja termit kuten PowerShell, DSC, Ansible ja automaatio kuulostavat tutuilta , tiedät luultavasti jo, että niiden tehokas yhdistäminen voi mullistaa palvelimien hallinnan täysin. Siirtyminen Windowsin ohjatun toiminnon manuaalisista napsautuksista täysin deklaratiiviseen ja toistettavaan kokoonpanoon tekee ratkaisevan eron palojen jatkuvan sammuttamisen ja täysin kontrolloidun ympäristön välillä.

Tässä artikkelissa perehdymme tarkemmin siihen, miten PowerShellin halutun tilan konfiguraatio (DSC) ja Ansible sopivat yhteen Miten WinRM, Azure Automation, Terraform tai pilvipohjainen init -teknologiat toimivat Windowsin (ja Linuxin) skaalautuvassa hallinnassa ja miten moduulin avulla voidaan hyödyntää Ansiblen olemassa olevia DSC-resursseja? win_dscNäet käytännön esimerkkejä, tosielämän käyttötapauksia ja kriteerejä sen päättämiseksi, milloin käyttää natiivia DSC:tä, Ansible-moduuleja tai muita automaatiomenetelmiä.

Yleiskatsaus: Windows-automaatio PowerShellin, DSC:n ja Ansiblen avulla

PowerShellillä ja Ansiblella on sama tavoite : automatisoida järjestelmiesi konfigurointi ja hallinta toistettavalla tavalla. Ero on niiden lähestymistavassa. DSC on PowerShelliin integroitu konfiguroinnin hallinta-alusta, joka on vahvasti keskittynyt Windowsiin (vaikka se voi toimia Linuxin kanssa OMI:n kautta), kun taas Ansible on monikäyttöinen, alustojen välinen automaatiomoottori, joka on suunniteltu hybridi- ja heterogeenisten infrastruktuurien orkestroimiseen yhdestä pisteestä.

Red Hat Ansible Automation Platformin avulla voit automatisoida Windows-palvelimia asentamatta lisäagentteja, hyödyntäen WinRM:ää tai OpenSSH: ta yhteyskanavina ja hyödyntäen DSC-resursseja, Ansible-moduuleja ja PowerShell-skriptejä. Kaikki tämä on järjestetty YAML-playbookien avulla , joissa määrität tilan, johon jokaisen isännän tulisi päästä sekä Windowsissa että Linuxissa.

PowerShellin halutun tilan määritys puolestaan ​​tarjoaa satoja erikoistuneita resursseja lähes minkä tahansa Windows-komponentin konfigurointiin: palvelut, järjestelmäominaisuudet, IIS, SQL Server, Active Directory, rekisteri, tiedostot jne. Nämä resurssit sisältävät halutun tilan tarkistamisen ja soveltamisen logiikan, joten sinun tarvitsee vain ilmoittaa, "millaisena haluat koneen olevan".

Olennaista on, että Ansiblesta käsin voit käyttää näitä DSC-resursseja suoraan moduulin kautta. ansible.windows.win_dscYhdistämällä Ansiblen orkestrointitehon DSC:n tarjoamaan Windows-kohtaiseen konfigurointisyvyyteen. Näin saavutat Parhaat puolet eri vaihtoehdoista ilman päällekkäisiä ponnisteluja.

WinRM ja etäkäyttö Windowsiin Ansiblea varten

Jotta Ansible voi hallita Windows-palvelimia, on tärkeää ymmärtää, miten WinRM (Windows Remote Management) toimii . WinRM on Microsoftin sisäänrakennettu HTTP/HTTPS-pohjainen etähallintateknologia, ja se on Ansiblen standardikanava tehtävien suorittamiseen Windows-koneissa.

Ensimmäinen vaihe on WinRM:n konfigurointi oikein kohdepalvelimissa ja ohjaussolmussa, jossa Ansible suoritetaan. Tämä edellyttää todennuksen, salauksen ja käyttöoikeuksien säätämistä sekä usein myös sellaisten ominaisuuksien käsittelyä kuin ei-vuorovaikutteinen kirjautuminen, jossa komentoja annetaan ilman aktiivista käyttäjäistuntoa. Tämä ei-vuorovaikutteinen istuntoympäristö monimutkaistaa tehtäviä, kuten Windows-päivityksiä tai kaksisuuntaista todennusskenaarioita , joissa on käytettävä toista etäresurssia (esimerkiksi jaettua resurssia toisella palvelimella).

Red Hat Ansible Automation Platformin käytön etuna on, että se mahdollistaa tunnistetietojen ja todennusmekanismien keskitetyn ja turvallisen koodaamisen, mikä abstraktoi näiden monimutkaisten tapausten käsittelyn. Lisäksi alusta voi käyttää myös OpenSSH:ta Windows Serverin käyttämiseen , mikä on yleistymässä nykyaikaisissa Windows-versioissa.

Käytännössä WinRM:n, Ansiblen tunnistetietojen hallinnan ja DSC-ominaisuuksien yhdistäminen mahdollistaa vankkojen automaatiovirtojen rakentamisen , jotka toimivat valvomatta jopa ympäristöissä, joissa on tiukat turvallisuusrajoitukset.

PowerShell DSC: Deklaratiivisen konfiguroinnin alusta

PowerShell Desired State Configuration on Windowsiin integroitu deklaratiivinen konfiguraationhallintajärjestelmä . DSC:n avulla voit määrittää koodilla, miten kone tulisi konfiguroida: mitkä roolit ja ominaisuudet tulisi asentaa, mitkä palvelut tulisi olla aktiivisia, mitkä rekisteriparametrit tulisi olla, mitkä tiedostot tai hakemistot tulisi olla olemassa ja niin edelleen.

DSC -konfiguraatiot kuvaavat joukon solmuja halutun tilan . Jokainen hallittu kone suorittaa paikallisen konfiguraatiohallinnan (LCM) , joka lukee nämä konfiguraatiot, tarkistaa todellisen tilan ja tekee tarvittavat muutokset. Lisäksi voit määrittää pull-palvelimen , joka keskittää konfiguraatiot ja josta solmut päivittävät ja raportoivat vaatimustenmukaisuudesta.

DSC ei rajoitu Windowsiin: Open Management Infrastructure ( OMI ) -palvelimen kautta se voi toimia myös Linux-koneissa . Se loistaa kuitenkin todella Windows-ympäristöissä, joissa yhteisö on kehittänyt laajan kokoelman erikoistuneita resursseja niin erilaisiin tehtäviin kuin IIS:n, SQL Serverin tai Active Directoryn konfigurointiin.

Yksi DSC:n suurista eduista on, että se keskittyy tulokseen, ei vaiheisiin . Sinä määrittelet tilan (esimerkiksi "tämän ominaisuuden on oltava läsnä, tämän palvelun on oltava käynnissä, tämän rekisteriarvon on oltava konfiguroitu") ja moottori huolehtii tilanteen saavuttamisesta, tarkistaen ja korjaten, jos jokin poikkeaa ajan myötä.

Miten Ansible sopii yhteen DSC:n kanssa: win_dsc-moduuli ja orkestrointi

Teoriassa DSC:tä voisi käyttää erikseen, mutta käytännössä se on paljon hyödyllisempi yhdistettynä Ansibleen orkestrointikerroksena . Ansible hoitaa inventaarion, tehtävien hallitun suorittamisen, järjestelmien välisen koordinoinnin ja integroinnin CI/CD-putkiin, kun taas DSC tarjoaa erityiset resurssit Windowsin sisäisen toiminnan manipulointiin.

Moduuli ansible.windows.win_dsc Se on silta kahden maailman välillä. Tämä moduuli käynnistää DSC-resurssiluokka kohde-Windows-isännässä. Pelikirjassa sinun tarvitsee määrittää vain:

• resurssin_nimi: käytettävän DSC-resurssin nimi (esimerkiksi File, WindowsFeature, Service, Registry, xWebsite, Jne.).
• Loput parametrit, jotka vastaavat suoraan DSC-resurssin ominaisuudet (esimerkiksi DestinationPath, Ensure, Name, State, Jne.).

Kun Ansible suorittaa tehtävän, se muuntaa nämä parametrit väliaikaiseksi DSC-kokoonpanoksi, ottaa sen käyttöön isännässä ja kerää tuloksen (mukaan lukien tiedot siitä, tapahtuiko muutoksia). Näin voit käyttää koko DSC-resurssiluetteloa uudelleen ilman, että sinun tarvitsee kirjoittaa erillisiä Ansible-moduuleja jokaista tapausta varten.

Suorituskulku noudattaa alla johdonmukaista kaavaa: Ansible lähettää tehtävän WinRM:n kautta, Windows-järjestelmä luo DSC-kokoonpanon parametrien perusteella, DSC-moottori kutsuu ensin Test-TargetResource tarkistaa nykyisen tilan ja jos se havaitsee eroja, se suorittaa Set-TargetResource ottaa muutokset käyttöön. Ansible vastaanottaa raportin, jossa ilmoitetaan, onko jotain muutettu, ja mahdolliset virheenkorjaukseen liittyvät viestit.

Tämä kytkentä on erityisen tehokas, kun yhdistät Ansiblen natiivit moduulit Windowsille (kuten win_file, win_service, win_regedit, win_psmodulejne.) DSC:n resurssien avulla niillä alueilla, joilla DSC tarjoaa parempia vaihtoehtoja tai laajemman toiminnallisen kattavuuden.

DSC-ominaisuuksien tyypit ja niiden yhdistäminen Ansibleen

Jokainen DSC-resurssi määrittää joukon ominaisuuksia, joilla on tarkkaan määritelty tyyppi (merkkijonot, totuusarvot, taulukot, monimutkaiset PowerShell-tyypit jne.). Kun työskentelet Ansiblessa, sinun on käännettävä nämä ominaisuudet muotoon YAML-syntaksi Oikean tyypin ylläpitäminen. Moduuli win_dsc Se tekee paljon automaattista muunnostyötä, mutta on syytä tietää joitakin keskeisiä tapauksia.

Yksinkertaisille tyypeille, kuten o , kartoitus on suoraviivainen: lainausmerkeissä olevat merkkijonot ja pienet totuusarvot YAML-tyyliin (true, false), välttäen kirjoittamista $true o $false kuten PowerShellissä. Tyypin ominaisuuksille , tavallista on käyttää ISO 8601 -muoto (esimerkiksi "2019-02-22T13:57:31Z") ja varmista, että arvo on sarjoitettu merkkijonona ympäröimällä se lainausmerkeillä.

Tyypin ominaisuudet Ne ovat erikoistapaus. Koska tätä tyyppiä ei voida suoraan sarjoittaa JSON-muotoon, Ansible käyttää käytäntöä: määrität kaksi parametria, jotka on erotettu toisistaan ​​päätteellä. _username y _password (esimerkiksi Credential_username y Credential_passwordModuuli luo objektin. PSCredential etäkoneessa näiden kahden arvon perusteella.

Tyypeille Nämä edustavat mukautettuun resurssiluokkaan perustuvia sanakirjoja; YAML:ssä ne ilmaistaan ​​avain-arvo-karttana. Sinun tulisi tarkistaa resurssin dokumentaatio (yleensä tiedostossa). <nombre_recurso>.schema.mof) tietääkseen, mitkä avaimet ovat sallittuja ja minkä tyyppisiä ne ovat. Käytännössä ne määritellään seuraavasti sisäkkäiset sanakirjat moduulin sisällä win_dsc.

Lopuksi, tyypin ominaisuudet ja taulukot (], ]jne.) esitetään sanakirjoina tai YAML-listoina. Taulukoiden kohdalla on suositeltavaa käyttää aito YAML-lista eikä pilkulla erotettuja arvoja sisältävää merkkijonoa, koska tämä välttää manuaalisen jäsentämisen ja vähentää hienovaraisten virheiden todennäköisyyttä.

Käytännön esimerkkejä Ansiblen DSC:n käytöstä

Kun olet hallinnut moduulin perusrakenteen win_dscVoit yhdistää resursseja rakentaaksesi erittäin kattavat konfigurointioppaatJoitakin yleisiä tilanteita, jotka toimivat hyvin DSC:n kanssa, ovat:

• Tiedosto- ja hakemistohallinta resurssin kanssa File: kansiorakenteiden luominen, tietyn sisällön sisältävien määritystiedostojen käyttöönotto, tiettyjen elementtien olemassaolon tai poistamisen varmistaminen.
• Windows-roolien ja -ominaisuuksien asentaminen kanssa WindowsFeatureIIS, .NET Framework, Telnet-asiakasohjelma, hallintatyökalut jne.
• Palvelun hallinta resurssin kanssa Servicetila (käynnistetty/pysäytetty), käynnistystyyppi (automaattinen, manuaalinen), huoltotili jne.
• Rekisteriasetukset kanssa Registry: turvallisuusarvot, odotusajat, protokollaparametrit, järjestelmän koventaminen.
• IIS-lisäasetukset moduuleilla, kuten xWebAdministration ja resursseja xWebsite, xWebAppPool, Jne

Kaikissa näissä tapauksissa Ansible yksinkertaisesti kuvaa DSC-resurssin parametrit, kun taas DSC-moottori vastaa tarkistamisesta ja soveltamisesta tila. Lisäksi Ansible 2.8:sta alkaen moduuli win_dsc Se tarkistaa parametrit automaattisesti resurssin määritelmää vasten: jos käytät virheellistä ominaisuuden nimeä, jätät pakollisen kentän tyhjäksi tai annat alueen ulkopuolisen arvon, tehtävä epäonnistuu selkeällä virheellä.

Jos käytät Ansiblea korkea sanallisuustaso (esim. -vvv)Tuloste sisältää yksityiskohtaisia ​​tietoja invocation.module_args käytetyistä ja käytettävissä olevista vaihtoehdoista, mikä on erittäin hyödyllistä sekä virheenkorjauksessa että sen selvittämisessä, mitä kenttiä voit määrittää kussakin resurssissa.

Huomaa myös, että voit käyttää parametria PsDscRunAsCredential Tämä sallii DSC-resurssin suorittamisen eri käyttäjänä kuin järjestelmä. Tämä on erittäin hyödyllistä rekisteröintirakenteen käyttämisessä. HKEY_CURRENT_USER käyttäjälle, johon Ansible on yhteydessä, tai tilanteissa, joissa tarvitset tietyn suojauskontekstin.

Mukautetut DSC-resurssit ja PowerShell-galleria

Windowsiin integroidut DSC-resurssit kattavat monia tarpeita, mutta todellinen teho tulee esiin, kun käytät PowerShell-galleriassa tai kolmannen osapuolen paketeissa julkaistuja resursseja. Tarjolla on moduuleja kaikkeen: Active Directory, SQL Server, edistynyt IIS, suojauskäytännöt ja paljon muuta.

Voit etsiä käytettävissä olevia resursseja cmdlet-komennolla Find-DscResource tai selaamalla suoraan PowerShell-galleriaa. Kun olet tunnistanut haluamasi moduulin (esimerkiksi xWebAdministration o SqlServerDsc), voit asentaa sen isäntäkoneillesi useilla tavoilla:

• Manuaalinen asennus Install-Module kohdepalvelimen PowerShellistä.
• Ansible-moduulin käyttö win_psmodule automatisoidaksesi asennuksen PowerShell-galleriasta.
• Lataa etukäteen ja kopioi käsin palvelimille, joilla ei ole internetyhteyttä, tallentamalla moduulin hakemistoon, joka sisältyy PSModulePath (esimerkiksi C:\Program Files\WindowsPowerShell\Modules).

Kun työskennellään erillisissä ympäristöissä, yleinen strategia on käyttää palvelinta, jolla on internetyhteys. tallenna moduuli käyttämällä Save-Module paikallisessa polussa ja kopioi sitten kyseinen hakemisto tuotantokoneisiin. Sen jälkeen määritä PSModulePath Sitä voidaan säätää myös esimerkiksi Ansiblella moduulin avulla win_pathjotta PowerShell voi havaita kyseiset resurssit ilman manuaalisia toimia.

Kun moduuli on asennettu, win_dsc voi kutsua mitä tahansa resurssia näistä paketeista yksinkertaisesti mainitsemalla nimen resource_nameTämä avaa oven vakiintuneiden ratkaisujen, kuten Active Directory DSC -moduulien, uudelleenkäytölle esimerkiksi seuraavissa tehtävissä: luo käyttäjiä, organisaatioyksiköitä tai ryhmiä tai määritä käytäntöjäkaikki hallitaan omien peliohjeidesi mukaan.

Lisäksi on jopa PowerShell-moduuli, jonka avulla voit automaattisesti luoda Ansible-moduuleja DSC-resursseista . Ajatuksena on tarkastella DSC-resurssia, luoda Ansible-moduuli, joka kuvaa sen parametrit yksi kerrallaan, ja käyttää sitä ikään kuin se olisi vakiomoduuli. Nämä generaattorit voivat ladata resursseja PowerShell-galleriasta ja luoda kymmeniä moduuleja, jotka laajentavat Windowsin automaatioekosysteemiä Ansiblen avulla.

DSC:n ja Ansiblen tuolla puolen: muita automaatiotyökaluja Azuressa

Jos infrastruktuurisi toimii (tai tulee toimimaan) Azuressa, kannattaa pitää silmällä muita työkaluja, jotka täydentävät PowerShell DSC:tä ja Ansiblea . Kyse ei ole vain yhden valitsemisesta, vaan sen ymmärtämisestä, miten ne sopivat kokonaisketjuun: infrastruktuurin luomiseen, järjestelmän konfigurointiin, sovellusten käyttöönottoon ja jatkuviin toimintoihin.

”Infrastruktuuri koodina” -alueella ratkaisut, kuten Terraform tai Azuren natiivit kielet (ARM Templates ja Bicep), mahdollistavat verkkojen, virtuaalikoneiden, tallennustilan ja hallittujen palveluiden määrittämisen deklaratiivisten tiedostojen avulla. Terraform käyttää omaa HCL-kieltä, kun taas Bicep yksinkertaistaa vanhempien ARM-mallien syntaksia, mutta ne kaikki integroituvat hyvin CI/CD-putkiin ja ne voidaan yhdistää Ansibleen virtuaalikoneiden konfiguroimiseksi niiden luomisen jälkeen.

Vaiheelle Linux-koneiden alkuasetuksetAzure tukee pilvi-initjoka suorittaa skriptejä ja määrittää käyttäjiä, paketteja tai asetustiedostoja ensimmäisen käynnistyksen yhteydessä. Tiedostot #cloud-config, jotka yleensä on koodattu base64-koodauksella, ovat jakelusta riippumattomia ja käyttävät kunkin jakelun omaa paketinhallintaa ilman, että sinun tarvitsee huolehtia siitä.

Operatiivisen automatisoinnin alueella Azure Automationilla on mielenkiintoinen rooli. Se käyttää runbookeja (yleensä PowerShell- tai Python-skriptejä), joita voidaan suorittaa tarvittaessa tai aikataulun mukaisesti sekä Azure-resursseissa että paikallisissa ympäristöissä Hybrid Runbook Workerin avulla. Lisäksi se tarjoaa hallitun DSC- palvelun , jonka avulla voit julkaista konfiguraatioita ja valvoa vaatimustenmukaisuutta useissa koneissa.

Lopuksi ekosysteemiä täydentävät CI/CD- ja sovellusten elinkaaren hallintatyökalut, kuten Azure DevOps, Jenkins, Chef, Puppet ja Packer . Jokainen niistä kattaa oman palapelinsä: koodin kääntämisestä ja testaamisesta mukautettujen laitekuvien luomiseen tai määräystenmukaisuuden varmistamiseen automatisoidun testauksen avulla.

Windows-päivitykset, paketit ja sovellusten hallinta

Yksi järjestelmätiimin kriittisimmistä tehtävistä on pitää Windows ajan tasalla korjaustiedostoilla ja päivityksillä . Microsoft tarjoaa Windows Updaten ja monissa yritysympäristöissä Microsoft Configuration Managerin (SCCM) käyttöönoton hallintaan. Useiden uudelleenkäynnistysten, tiukkojen huoltovälien tai monimutkaisten orkestrointivaatimusten johdosta nämä mekanismit voivat kuitenkin epäonnistua tai osoittautua epäluotettaviksi.

Ansible Automation Platform helpottaa päivitysten hallittua suorittamista , integroituu Windows Updateen ja hallitsee automaattisesti tarvittavia uudelleenkäynnistyksiä, jotta yksi tehtävä voi asentaa kymmeniä tai satoja korjauksia säilyttäen samalla solmujen lopullisen tilan hallinnan.

Sovellusten asennuksen osalta Windowsista puuttuu yhtenäinen natiivi paketinhallintajärjestelmä , kuten Linux-jakeluissa. Microsoft Storea ei ole suunniteltu automatisoituihin massakäyttöönottoihin: siitä puuttuvat kypsät komentorivityökalut ja se on vahvasti riippuvainen graafisesta käyttöliittymästä, mikä tekee sen käytöstä automatisoiduissa asennusputkissa vaikeaa.

Tämän rajoituksen ratkaisemiseksi Ansible integroi moduuleja, jotka mahdollistavat peruspaketinhallinnan Windowsissa , ja ennen kaikkea se toimii erittäin hyvin ratkaisujen, kuten Chocolateyn tai Wingetin, kanssa Windowsissa , tarjoten idempotentin lähestymistavan, joka on samanlainen kuin klassinen paketinhallinta. Yhdistämällä Chocolateyn, DSC:n ja Ansiblen käyttöoppaat voit standardoida palvelimien tai VDI:n ohjelmistoluetteloita hyvin vähällä manuaalisella vaivalla.

Jos tähän lisätään DSC-resurssien käyttö näihin sovelluksiin liittyvien rekisterimääritysten, palveluiden ja käytäntöjen valvomiseen, saavutat kattavan automatisoinnin ohjelmistojen elinkaarelle Windows-ympäristöissäsi aina alkuperäisestä asennuksesta määritysten vahvistamiseen ja säännöllisiin päivityksiin.

Koulutus, parhaat käytännöt ja käyttöönotto Windows-tiimeissä

Monissa puhtaasti Windows-pohjaisissa IT-tiimeissä lähtökohtana on edelleen graafisen konsolin ja ohjattujen toimintojen klikkauksiin perustuva hallinta . On yleistä, että kymmeniä tai satoja virtuaalikoneita on käynnissä VMware- tai Hyper-V-ympäristössä, jossa palvelimen luontiprosessi tehdään manuaalisesti. Siirtyminen automaatioon tapahtuu yleensä, kun joku tiimissä kyllästyy toistamaan samoja tehtäviä ja alkaa kirjoittaa PowerShell-skriptejä.

Tässä yhteydessä herää kohtuullinen kysymys: ”Jatkanko PowerShellin käyttöä yksinään, vai vaihdanko DSC:hen, asennan Ansiblen… vai teenkö kaiken kerralla?” Käytännöllisin vastaus on yleensä yhdistää ne: hyödyntää olemassa olevaa PowerShellin ja DSC:n tietämystä ja samalla ottaa Ansible käyttöön orkestrointikerroksena standardoinnin ja integrointimahdollisuuksien parantamiseksi muiden alustojen kanssa.

Windows-järjestelmänvalvojille on olemassa erityisiä kursseja , jotka aloittavat Ansiblen käytöstä tyhjästä ja keskittyvät juuri tähän: miten konfiguroida Windows-järjestelmät Ansiblella hallittaviksi, miten kirjoittaa tehokkaita peliohjeita, miten integroida Ansible Tower tai AWX automaatioiden käynnistämiseksi keskitetystä ja turvallisesta web-käyttöliittymästä, ja miten käyttää uudelleen näiden peliohjeiden DSC-koodia, jotta jo tehtyä työtä ei heitetä hukkaan.

Käytännössä monet tiimit omaksuvat evolutiivisen strategian: aloittaen automatisoimalla yksinkertaisia ​​tehtäviä (palvelut, roolit, PowerShell-moduulin asennus), jatkaen DSC-resurssien käyttämistä toistuviin konfiguraatioihin (IIS, AD, SQL, suojauskäytännöt) ja integroimalla automaation vähitellen sovellusten toimitusputkeen ja toistuviin operatiivisiin tehtäviin.

On myös tärkeää määritellä tyyliohjeet, lähdekoodin hallinta sekä peliohjeiden ja DSC-konfiguraatioiden testaus, jotta automaatiosta tulee aitoa "infrastruktuuria koodina" eikä vain kourallista irrallisia skriptejä ilman versionhallintaa tai revisioita.

Yhdistämällä PowerShell DSC:n, Ansible-moduulit, WinRM:n, Chocolateyn ja Azure-työkalut luodaan vankka ekosysteemi, jossa koneellinen luonti, yksityiskohtainen konfigurointi, sovellusten käyttöönotto ja jatkuva ylläpito eivät enää ole riippuvaisia ​​manuaalisista RDP-istunnoista. Tuloksena on johdonmukaisempi, auditoitavampi ja toistettavissa oleva ympäristö, jossa muutokset dokumentoidaan automaattisesti koodiin ja inhimilliset virheet vähenevät merkittävästi.