fredag, april 19, 2024
Latest:
Kode

Komme i gang med PowerShell Desired State Configuration (DSC)

Luciano

PowerShell DSC er en fantastisk teknologi å ha i verktøybeltet for å administrere Windows-baserte servere. Dette innlegget er en del av en serie:

Enten du er en stor eller liten organisasjon, bruker skyinfrastruktur eller rackmonterte servere, er det utfordrende å opprettholde tilstanden til en server. Det finnes flere tredjepartsløsninger som Ansible, Chef og Puppet, men de er betalte Linux-baserte produkter. For Windows-folk er det et gratis og Windows-sentrisk alternativ tilgjengelig; PowerShell Desired State Configuration (DSC). I denne PowerShell DSC-opplæringen viser jeg deg hvordan du kommer i gang med PowerShell DSC og gir noen grunnleggende eksempler på hvordan du bruker den.

Hva er PowerShell Desired State Configuration (DSC)

PowerShell DSC er en IaC-teknologi (Infrastructure as Code) som bruker PowerShell til å lage MOF-filer (Managed Object Format), som Windows Management Instrumentation (WMI) kan bruke til å konfigurere en maskin. Med andre ord, PowerShell DSC bruker PowerShell til å programmere konfigurasjon av dine Windows-baserte datamaskiner. I tillegg kan DSC overvåke tilstanden til de konfigurerte ressursene for å sikre at maskinene dine forblir konsistente. Sammen med overvåking kan DSC også automatisk korrigere konfigurasjonen av systemet ditt, slik at det alltid er i ønsket tilstand.

PowerShell != PowerShell DSC

Hvis du noen gang har tatt et kurs i PowerShell, kan instruktøren din ha nevnt PowerShell DSC, men forkastet det og sa at det er noe helt annet eller at det er et annet kurs tilgjengelig for PowerShell DSC. DSC bruker PowerShell-skriptspråket, men likhetene slutter der.

Hvorfor bruke PowerShell DSC

En vanlig metode for å opprettholde konsistens i infrastrukturen din er å lage basis image for de forskjellige typene servere du trenger for å spinne opp. Trenger du en webserver? Bruk webserver image. Trenger du en databaseserver? Bruk databaseserver image. Selv om dette absolutt forkorter tiden det tar å levere ressurser med en kjent/god konfigurasjon, er det noen iboende problemer.

Hva skjer for eksempel når noen endrer de tillatte protokollene til webserverne dine? Du kan fikse basis image og enten gjenopprette alle webserverne dine eller skrive et automatiseringsskript for å bruke den nye sikkerhetskonfigurasjonen til de eksisterende, men å gjenopprette servere eller skrive og deretter teste et oppdateringsskript kan ta en betydelig tid, spesielt hvis du har hundrevis av servere. Hva om de nylig implementerte sikkerhetsstandardene bryter et kvartalsvis grensesnitt med en forretningspartner? Da må du angre alt dette arbeidet.

Med PowerShell DSC kan du definere ønsket tilstand, som alle nye og eksisterende servere deretter kan plukke opp og implementere. Hvis du måtte angre det, endrer du bare ønsket tilstand for å gå tilbake.

Hvordan virker det?

PowerShell DSC tar komponentene som er konfigurert med PowerShell og konverterer dem til MOF-filer som WMI kan bruke til å konfigurere en maskin. Det er to metoder som DSC kan bruke for å bruke konfigurasjonen på maskinen din; Push og Pull. Du kan også lage en slags hybrid tilnærming ved å bruke automatiserte distribusjonsverktøy.

Push metode

Push-metoden er kanskje den enkleste metoden å starte med. Denne metoden krever at brukeren sender ønsket tilstandskonfigurasjon til serveren ved å kalle Start-DscConfiguration cmdleten. Dette har fordelen av å starte umiddelbart med å bruke konfigurasjonen. Når det gjelder automatisering, er ulempen med denne tilnærmingen at hvis serveren er offline, vil den ikke kunne bruke den nye ønskede tilstanden. Det er her pull-metoden kan være en bedre tilnærming.

Pull metode

Som navnet tilsier, når Pull-metoden ut til en server for å trekke den ønskede tilstandskonfigurasjonen ned og bruke den. Dette krever at du har en Pull-server som inneholder konfigurasjonene for serverne dine. Ulempen med denne tilnærmingen er kravet om en ekstra server for å være vert for konfigurasjonen. De konfigurerte serverne må deretter konfigureres til å polle pull-serveren for å finne ut om det er en ny MOF-fil tilgjengelig.

Komme igang

Dette innlegget er designet for noen som er nye til DSC, så vi kommer til å bruke den enklere push-metoden for å komme i gang. For vårt scenario ønsker vi å sørge for at konfigurasjonen av serverne våre inkluderer noen Windows-funksjoner. Vi bruker bare noen få:

  • Web-Server
  • Web-Mgmt-Tools
  • Web-Default-Doc

Hvis du lurer på hvor jeg har fått navnene, bruk Get-WindowsFeature cmdleten for en liste. Du kan også bruke et asterisk for navnet, for eksempel Get-WindowsFeature Web*.

Enkelt konfigurasjonsskript

For DSC bruker vi Configuration nøkkelordet for å definere konfigurasjonen. I dette eksemplet, er det WindowsFeature komponenten vi konfigurerer. Du kan se at vi definerer tre separate forekomster av WindowsFeature komponenten, en for hver komponent vi ønsker å konfigurere. Hver konfigurert forekomst trenger sitt eget unike navn, da navnet brukes som en nøkkel ved konvertering til MOF-filen. Hver komponent du konfigurerer vil ha en Ensure egenskap, som kan ha verdien av enten Present eller Absent. Når du vil forsikre deg om at komponenten eksisterer, angir du Present. Hvis du ikke vil ha komponenten på maskinen, angir du Absent. For dette eksempelet vil vi sørge for at komponentene er installert på serveren, så vi har spesifisert Present for dem alle.

Etter at vi har fullført Configuration, kaller vi det lik en funksjon og gir en OutputPath slik at DSC vet hvor den genererte MOF-filen skal plasseres. For dette eksemplet har vi kalt det WebServerConfiguration. Etter at DSC Configuration er fullført, kaller vi Start-DscConfiguration cmdlet og gir banen til MOF-filen som vi genererte:

Configuration WebServerConfiguration
{  
  Node "localhost"
  {        
    WindowsFeature WebServer
    {
      Name = "Web-Server"
      Ensure = "Present"
    }

    WindowsFeature ManagementTools
    {
      Name = "Web-Mgmt-Tools"
      Ensure = "Present"
    }

    WindowsFeature DefaultDoc
    {
      Name = "Web-Default-Doc"
      Ensure = "Present"
    }
  }
}

WebServerConfiguration -OutputPath "C:\DscConfiguration"

Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"

Etter at konfigurasjonen din har kjørt, bør du se noe utdata som ligner på dette:

Separere nodedata og gjøre skriptet mer dynamisk

Vårt forenklede eksempel er veldig hardkodet og ikke dynamisk i det hele tatt. Med PowerShell DSC har vi muligheten til å skille konfigurasjonsdataene fra selve konfigurasjonen og gjøre skriptet vårt mer dynamisk. Det er tross alt PowerShell😃

En DSC-konfigurasjonsdatafil er bare en haug med Hash-tabeller som kan inneholde andre Hash-tabeller eller Arrays og har vanligvis en psd1-filtype. DSC-konfigurasjonsdata må ha minst én nøkkel kalt AllNodes. Se Microsoft-dokumentasjonen for mer informasjon.

La oss ta vår opprinnelige liste over tre Windows-funksjoner og legge dem inn i en DSC-konfigurasjonsdatafil:

@{
  AllNodes = @(
    @{
      NodeName = $env:COMPUTERNAME
      WindowsFeatures = @(
        @{
          Name = "Web-Server"
          Ensure = "Present"
        },
        @{
          Name = "Web-Mgmt-Tools"
          Ensure = "Present"
        },
        @{
          Name = "Web-Default-Doc"
          Ensure = "Present"
        }
      )
    }
  )
}

Med konfigurasjonsdata atskilt, kan vi forkorte og gjøre DSC PowerShell-skriptet vårt mer generisk:

Configuration WebServerConfiguration
{  
  Node $AllNodes.NodeName
  {        
    # Loop through the defined features
    ForEach($Feature in $Node.WindowsFeatures)
    {
      # Define component
      WindowsFeature $Feature.Name
      {
        Name = $Feature.Name
        Ensure = $Feature.Ensure
      }
    }
  }
}

WebServerConfiguration -OutputPath "C:\DscConfiguration" -ConfigurationData "C:\DscConfiguration\WebServer.psd1"

Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"

Det er to ting å merke seg i det nye skriptet vårt:

  • Oppfordringen til WebServerConfiguration nå har et tilleggsargument ConfigurationData. Dette forteller DSC filen som inneholder konfigurasjonsdataene som skal lastes.
  • Vi kan referere til egenskapene til DSC-konfigurasjonsdatafilen ved å bruke punktnotasjon.

Oppdagelse av endring

Som tidligere nevnt kan DSC oppdage om noe ikke lenger er i ønsket tilstand. Det er viktig å merke seg at DSC bare kan oppdage endringer som den har fått beskjed om å bry seg om. Ved å bruke vårt eksempel, hvis noen hadde installert Web-Ftp-Server Windows-funksjonen, ville ikke vårt DSC PowerShell-skript rapportere noe. Men hvis noen hadde fjernet Web-Default-Doc, ville DSC rapportere at funksjonen ikke lenger var i ønsket tilstand. Når en DSC-konfigurasjon ikke lenger er i ønsket tilstand, vil det være endret.

For å kjøre en test av gjeldende konfigurasjon, kjører du Test-DscConfiguration cmdleten. Hvis konfigurasjonen er i ønsket tilstand, Test-DscConfiguration returnerer True, hvis noe har endret, returnerer den False. Ved -Detailed vil du returnere en liste over ressurser både i og utenfor endringer:

La oss fjerne Web-Default-Doc ved å kjøre:

Uninstall-WindowsFeature Web-Default-Doc

Kjør Test-DscConfiguration -Detailed:

Som du kan se, har maskinen drevet og identifisert [WindowsFeature]DefaultDoc (Web-Default-Doc) som ikke lenger i ønsket tilstand!

Automatisk korrigering av endring

Du kan konfigurere Local Configuration Manager (LCM) til å korrigere konfigurasjonen automatisk når drift oppdages. For å gjøre dette, plasserer vi en LocalConfigurationManager node i vårt DSC PowerShell-skript og setter ConfigurationMode egenskapen. ConfigurationMode kan ha en av tre verdier:

  • ApplyOnly: denne innstillingen instruerer LCM om å bruke konfigurasjonen og ikke gjøre noe annet.
  • ApplyAndMonitor: denne innstillingen instruerer LCM om å bruke konfigurasjonen og regelmessig kjøre en konsistenssjekk (i hovedsak Test-DscConfiguration). Standardfrekvensen for konsistenskontrollen er 15 minutter og kan overstyres ved å angi ConfigurationModeFrequencyMins egenskapen.
  • ApplyAndAutoCorrect: denne innstillingen instruerer LCM om å bruke konfigurasjonen og med jevne mellomrom kjøre en konsistenssjekk. Hvis konsistenskontrollen kommer tilbake false, bruker LCM konfigurasjonen på nytt for å bringe maskinen tilbake til ønsket tilstand.

For å konfigurere LCM til å korrigere drift automatisk, setter vi den til ApplyAndAutoCorrect:

Configuration WebServerConfiguration
{  
  Node $AllNodes.NodeName
  {
    # Configure the LCM
    LocalConfigurationManager
    {
      ConfigurationMode = "ApplyAndAutoCorrect"
    }        

    # Loop through the defined features
    ForEach($Feature in $Node.WindowsFeatures)
    {
      # Define component
      WindowsFeature $Feature.Name
      {
        Name = $Feature.Name
        Ensure = $Feature.Ensure
      }
    }
  }
}

WebServerConfiguration -OutputPath "C:\DscConfiguration" -ConfigurationData "C:\DscConfiguration\WebServer.psd1"

Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"

Nå vil serveren vår automatisk korrigere seg selv når endringer oppdages! Hvis du aktiverer automatisk endrings korreksjon, sørg for at du dokumenterer det; ellers vil du eller noen andre ditt ende opp med å prøve å finne ut hvorfor noe du nettopp har fjernet stadig kommer tilbake!

Sammendrag

Denne opplæringen for blogginnlegg gir deg litt grunnleggende informasjon om hvordan du kommer i gang med PowerShell DSC, samt hvordan du oppdager og eventuelt automatisk korrigerer endringer.

Similar Posts