Desired State Configuration-översikt för tekniker
Det här dokumentet är avsett för utvecklar- och driftsteam för att förstå fördelarna med PowerShell Desired State Configuration (DSC). En vy på högre nivå över 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 iterationshastigheten
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 i drift så smidigt och tillförlitligt som möjligt kan du minska tiden till värde för ny affärslogik.
Övergången 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 typen av åtgärder genom 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 undviker 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 behö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örningen eller "hur jag vill göra det". Det innebär att logiken för körningen finns i resurserna. Användarna behöver inte veta hur de ska implementera eller distribuera en funktion när en DSC-resurs för den funktionen är tillgänglig. På så sätt kan användaren fokusera på strukturen för distributionen.
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 lägga skriptet i produktion stöter du på flera 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 "riktig" version av skriptet att se närmare ut ungefär så här:
# 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 mycket 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 -ModuleName 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 i resursimplementeringen, men osynliga för skriptförfattaren.
Separera miljö från struktur
Ett vanligt mönster i DevOps är att ha flera miljöer för distribution. Det kan till exempel finnas en "dev"-miljö som används för att snabbt skapa en prototyp av ny kod. Koden från utvecklingsmiljön hamnar i en "testmiljö", där andra verifierar de nya funktionerna. Slutligen hamnar koden i "prod" eller produktionsmiljön för liveplatsen.
DSC-konfigurationer hanterar den här dev-test-prod-pipelinen med hjälp av konfigurationsdata.
Detta sammanfattar vidare 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 mellannivåserver. 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 anropa Start-DscConfiguration med rätt konfigurationsdata för den miljö som du vill rikta in dig på.
