Desired State Configuration-översikt för tekniker

Det här dokumentet är avsett för utvecklar- och driftteam för att förstå fördelarna med PowerShell Desired State Configuration (DSC). En vy på högre nivå av det värde som DSC tillhandahåller finns i Desired State Configuration översikt för beslutsfattare

Fördelar med Desired State Configuration

DSC finns för att:

• Minska komplexiteten för skript i Windows
• Öka iterationens hastighet

Begreppet "kontinuerlig distribution" blir allt viktigare. Kontinuerlig distribution innebär möjligheten att distribuera ofta, potentiellt många gånger per dag. Syftet med dessa distributioner är inte att åtgärda något, utan att få något publicerat snabbt. Genom att få nya funktioner genom utveckling så smidigt och tillförlitligt som möjligt kan du minska tiden till värde för ny affärslogik.

Flytten till molnbaserad databehandling innebär en distributionslösning som använder en "deklarativ" mallmodell, där en sluttillståndsmiljö deklareras som text och publiceras till en distributionsmotor. Den här distributionstekniken möjliggör snabba ändringar i stor skala med motståndskraft mot hot om fel eftersom distributionen när som helst kan upprepas konsekvent för att garantera ett sluttillstånd. Skapandet av verktyg och tjänster som stöder den här typ av åtgärder via automatisering är ett svar på dessa ändringar.

DSC är en plattform som tillhandahåller deklarativ och idempotent (repeterbar) distribution, konfiguration och överensstämmelse. Med DSC-plattformen kan du se till att komponenterna i ditt datacenter har rätt konfiguration, vilket förhindrar fel och förhindrar kostsamma distributionsfel. Genom att behandla DSC-konfigurationer som en del av programkoden möjliggör DSC kontinuerlig distribution. DSC-konfigurationen bör uppdateras som en del av programmet, vilket säkerställer att den kunskap som krävs för att distribuera programmet alltid är uppdaterad och redo att användas.

"Jag har PowerShell, varför behöver jag Desired State Configuration?"

DSC-konfigurationer separerar avsikten, eller "vad jag vill göra", från körning eller "hur jag vill göra det". Det innebär att körningslogiken finns i resurserna. Användarna behöver inte veta hur de implementerar eller distribuerar en funktion när en DSC-resurs för den funktionen är tillgänglig. På så sätt kan användaren fokusera på distributionens struktur.

Till exempel bör PowerShell-skript se ut så här:

# Create a share in Windows Server 8
New-SmbShare -Name MyShare -Path C:\Demo\Temp -FullAccess Alice -ReadAccess Bob

Det här skriptet är enkelt, begripligt och enkelt. Men om du försöker placera skriptet i produktion kommer du att få problem. Vad händer om skriptet körs två gånger i rad? Vad händer om Bob tidigare hade fullständig åtkomst till resursen?

För att kompensera för dessa problem kommer en "verklig" version av skriptet att titta närmare på något som:

# But actually creating a share in an idempotent way would be

$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
    Write-Verbose -Message "Share with name $Name exists"
    $shareExists = $true
}

if ($shareExists -eq $false)
{
    Write-Verbose "Creating share $Name to ensure it is Present"
    New-SmbShare @PSBoundParameters
}
else
{
    # Need to call either Set-SmbShare or *ShareAccess cmdlets
    if ($PSBoundParameters.ContainsKey("ChangeAccess"))
    {
       #...etc, etc, etc
    }
}

Det här skriptet är mer komplext med massor av logik och felhantering. Skriptet är mer komplext eftersom du inte längre anger vad du vill göra, utan hur du gör det.

Med DSC kan du säga vad du vill göra och den underliggande logiken abstraheras bort.

# A configuration is a special kind of PowerShell function
Configuration Sample_Share
{
   Import-DscResource -Module xSmbShare
   # Nodes are the endpoint we wish to configure
   # A Configuration block can have zero or more Node blocks
   Node $NodeName
   {
      # Next, specify one or more resource blocks
      # Resources are simply PowerShell modules that
      # implement the logic of "how" to execute a task
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyShare"
          Path        = "C:\Demo\Temp"
          ReadAccess  = "Bob"
          FullAccess  = "Alice"
          Description = "This is an updated description for this share"
      }
   }
}
#Run the function to compile the configuration
Sample_Share
#Pass the configuration to the nodes we defined and configure them
Start-DscConfiguration Sample_Share

Det här skriptet är korrekt formaterat och enkelt att läsa. Logiksökvägarna och felhanteringen finns fortfarande kvar i resursimplementering, men är osynliga för skriptförfattaren.

Separera miljö från struktur

Ett vanligt mönster i DevOps är att ha flera distributionsmiljöer. Det kan till exempel finnas en "utvecklingsmiljö" som används för att snabbt skapa prototyper av ny kod. Koden från utvecklingsmiljön hamnar i en "testmiljö" där andra personer verifierar de nya funktionerna. Slutligen hamnar koden i produktionsmiljön "prod" eller live-platsen.

DSC-konfigurationer kan hantera den här dev-test-prod-pipelinen med hjälp av konfigurationsdata. Detta abstraherar ytterligare skillnaden mellan konfigurationens struktur från de noder som hanteras. Du kan till exempel definiera en konfiguration som kräver en SQL server, en IIS-server och en server på mellannivå. Oavsett vilka noder som får de olika delarna i den här konfigurationen kommer dessa tre element alltid att finnas. Du kan använda konfigurationsdata för att peka alla tre elementen mot samma dator för en utvecklingsmiljö, separera de tre elementen till tre olika datorer för en testmiljö och slutligen mot alla dina produktionsservrar för prod-miljön. Om du vill distribuera till de olika miljöerna kan du Start-DscConfiguration anropa med rätt konfigurationsdata för den miljö som du vill använda som mål.

Se även

Konfigurationer

Konfigurationsdata

Resurser