Ändringar av beteende i PowerShell Desired State Configuration för gästkonfiguration

  • Artikel
  • 8 minuter för att läsa

Innan du börjar är det en bra idé att läsa översikten över gästkonfigurationen.

En video-genomgång av det här dokumentet finns tillgänglig.

Gästkonfigurationen använder Desired State Configuration (DSC) version 3 för att granska och konfigurera datorer. DSC-konfigurationen definierar det tillstånd som datorn ska vara i. Det finns många viktiga skillnader i hur DSC implementeras i gästkonfigurationen.

Gästkonfigurationen använder PowerShell 7 över flera plattformar

Gästkonfigurationen är utformad så att hanteringen av Windows och Linux kan vara konsekvent. I båda operativsystemmiljöerna kan någon med Kunskap om PowerShell DSC skapa och publicera konfigurationer med hjälp av skriptkunskaper.

Gästkonfigurationen använder endast PowerShell DSC version 3 och förlitar sig inte på den tidigare implementeringen av DSC för Linux eller "nx"-providers som ingår i lagringsplatsen.

Gästkonfigurationen fungerar i PowerShell 7.1.3 för Windows och PowerShell 7.2 förhandsversion 6 för Linux. Från och med version 7.2 har modulen flyttats från att ingå i PowerShell-installationen och installeras i stället som en modul PSDesiredStateConfiguration från PowerShell-galleriet.

Flera konfigurationer

Gästkonfigurationen stöder tilldelning av flera konfigurationer till samma dator. Det krävs inga särskilda steg i operativsystemet för gästkonfigurationstillägget. Du behöver inte konfigurera partiella konfigurationer.

Beroenden hanteras per konfiguration

När en konfiguration paketeras med hjälp avde tillgängliga verktygen inkluderas de nödvändiga beroendena för konfigurationen i en .zip fil. Datorer extraherar innehållet till en unik mapp för varje konfiguration. Agenten som levereras av gästkonfigurationstillägget skapar en dedikerad PowerShell-session för varje konfiguration, med hjälp av en som begränsar automatisk modulläsning till endast den sökväg där paketet $Env:PSModulePath extraherades.

Flera fördelar är resultatet av den här ändringen.

  • Det går att använda olika modulversioner för varje konfiguration på samma dator.
  • När en konfiguration inte längre tas bort på en dator tas hela mappen där den extraherades bort på ett säkert sätt av agenten utan att behöva hantera delade beroenden mellan konfigurationer.
  • Du behöver inte hantera flera versioner av någon modul i en central tjänst.

Artefakter hanteras som paket

Funktionen Azure Automation State Configuration artefakthantering för moduler och konfigurationsskript. När båda har publicerats i tjänsten kan skriptet kompileras till MOF-format. På samma sätt Windows pull-servern också hantera konfigurationer och moduler i webbtjänstinstansen. DSC-tillägget har däremot en förenklad modell där alla artefakter paketeras tillsammans och lagras på en plats som är tillgänglig från måldatorn med hjälp av en HTTPS-begäran (Azure Blob Storage är det populära alternativet).

Gästkonfigurationen använder bara den förenklade modellen där alla artefakter paketeras tillsammans och nås från måldatorn via HTTPS. Du behöver inte publicera moduler, skript eller kompilera i tjänsten. En ändring är att paketet alltid ska innehålla en kompilerad MOF. Det går inte att inkludera en skriptfil i paketet och kompilera på måldatorn.

Maximal storlek för anpassat konfigurationspaket

I Azure Automation-tillståndskonfigurationen var DSC-konfigurationerna begränsade i storlek. Gästkonfigurationen stöder en total paketstorlek på 100 MB (före komprimering). Det finns ingen specifik gräns för storleken på MOF-filen i paketet.

Konfigurationsläget anges i paketartefakten

När du skapar konfigurationspaketet anges läget med följande alternativ:

  • Granska: Verifierar kompatibiliteten för en dator. Inga ändringar görs.
  • AuditandSet: Verifierar och åtgärdar kompatibilitetstillståndet för datorn. Ändringar görs om datorn inte är kompatibel.

Läget anges i paketet i stället för i den lokala tjänsten Konfigurationshanteraren eftersom det kan vara olika per konfiguration när flera konfigurationer tilldelas.

Parameterstöd via Azure Resource Manager

Parametrar som anges av egenskapsmatrisen i gästkonfigurationstilldelningar skriver över den statiska texten i en configurationParameter konfigurations-MOF-fil när filen lagras på en dator. Med parametrar kan anpassning och ändringar styras av en operatör från tjänst-API:et utan att du behöver köra kommandon på datorn.

Parametrar i Azure Policy som skickar värden till gästkonfigurationstilldelningar måste vara strängtyp. Det går inte att skicka matriser via parametrar, även om DSC-resursen stöder matriser.

Utlösaruppsättning från en extern dator

En utmaning i tidigare versioner av DSC har varit att korrigera drift i stor skala utan mycket anpassad kod och beroende av WinRM-fjärranslutningar. Gästkonfigurationen löser det här problemet. Användare av gästkonfiguration har kontroll över felkorrigering via Reparation på begäran.

Sekvensen innehåller Get-metoden

När gästkonfigurationen granskar eller konfigurerar en dator används samma händelsesekvens för både Windows och Linux. Den märkbara beteendeändringen är Get att metoden anropas av tjänsten för att returnera information om datorns tillstånd.

  1. Agenten körs först Test för att avgöra om konfigurationen är i rätt tillstånd.
  2. Om paketet är inställt på avgör det booleska värdet som returneras av funktionen om Azure Resource Manager status för gästtilldelningen ska vara Audit Kompatibel/Ej kompatibel.
  3. Om paketet är inställt på avgör det booleska värdet om datorn ska AuditandSet åtgärdas genom att tillämpa konfigurationen med hjälp av Set metoden . Om metoden Test returnerar False Set körs . Om Test returnerar True Set körs inte .
  4. Till sist kör providern för att returnera det aktuella tillståndet för varje inställning så att information finns tillgänglig både om varför en dator inte är kompatibel och för att bekräfta att det aktuella tillståndet Get är kompatibelt.

Särskilda krav för Get

Funktionsmetoden Get har särskilda krav för Azure Policy gästkonfiguration som inte har behövts för Windows PowerShell Desired State Configuration.

  • Hash-tabellen som returneras ska innehålla en egenskap med namnet Reasons.
  • Egenskapen Reasons måste vara en matris.
  • Varje objekt i matrisen ska vara en hash-tabell med nycklar med namnet Kod och Fras.
  • Inga andra värden än hash-tabellen ska returneras.

Egenskapen Reasons används av tjänsten för att standardisera hur kompatibilitetsinformation visas. Du kan tänka på varje objekt i Orsaker som en "orsak" till att resursen är eller inte är kompatibel. Egenskapen är en matris eftersom en resurs kan vara in compliance av mer än en anledning.

Egenskaperna Kod och Fras förväntas av tjänsten. När du skapar en anpassad resurs anger du texten (vanligtvis stdout) som du vill visa som orsak till att resursen inte är kompatibel som värde för Fras. Kod har särskilda formateringskrav så att rapporteringen tydligt kan visa information om den resurs som används för att göra granskningen. Den här lösningen gör gästkonfigurationen utökningsbar. Alla kommandon kan köras så länge utdata kan returneras som ett strängvärde för egenskapen Phrase.

  • Kod (sträng): Namnet på resursen, upprepas och sedan ett kort namn utan blanksteg som identifierare av orsaken. Dessa tre värden ska vara kolonavgränsade utan blanksteg.
    • Ett exempel är registry:registry:keynotpresent
  • Fras (sträng): Text som kan läsas av människor för att förklara varför inställningen inte är kompatibel.
    • Ett exempel är The registry key $key isn't present on the machine.
$reasons = @()
$reasons += @{
  Code = 'Name:Name:ReasonIdentifer'
  Phrase = 'Explain why the setting is not compliant'
}
return @{
    reasons = $reasons
}

När du använder kommandoradsverktyg för att hämta information som returneras i Hämta kan du hitta verktyget returnerar utdata som du inte förväntade dig. Även om du samlar in utdata i PowerShell kan utdata också ha skrivits till standardfel. Överväg att omdirigera utdata till null för att undvika det här problemet.

Egenskapen Reasons embedded class

I skriptbaserade resurser (endast Windows) ingår klassen Reasons i MOF-schemafilen enligt följande.

[ClassVersion("1.0.0.0")]
class Reason
{
  [Read] String Phrase;
  [Read] String Code;
};

[ClassVersion("1.0.0.0"), FriendlyName("ResourceName")]
class ResourceName : OMI_BaseResource
{
  [Key, Description("Example description")] String Example;
  [Read, EmbeddedInstance("Reason")] String Reasons[];
};

I klassbaserade resurser (Windows och Linux) Reason ingår klassen i PowerShell-modulen enligt följande. Linux är fallkänsligt, så "C" i Kod och "P" i Fras måste vara versaler.

enum ensure {
  Absent
  Present
}

class Reason {
  [DscProperty()]
  [string] $Code

  [DscProperty()]
  [string] $Phrase
}

[DscResource()]
class Example {

  [DscProperty(Key)]
  [ensure] $ensure

  [DscProperty()]
  [Reason[]] $Reasons

  [Example] Get() {
    # return current current state
  }

  [void] Set() {
    # set the state
  }

  [bool] Test() {
    # check whether state is correct
  }
}

Om resursen har obligatoriska egenskaper bör dessa egenskaper också returneras Get parallellt med Reason klassen . Om inte ingår innehåller tjänsten ett Reason "catch-all"-beteende som jämför värdena som matas in med och värdena som returneras av och ger en Get detaljerad jämförelse som Get Reason .

Konfigurationsnamn

Namnet på den anpassade konfigurationen måste vara konsekvent överallt. Namnet på filen för innehållspaketet, konfigurationsnamnet i MOF-filen och gästtilldelningsnamnet i .zip Azure Resource Manager mallen måste vara samma.

Vanliga DSC-funktioner som inte är tillgängliga under den offentliga förhandsversionen av gästkonfigurationen

Under den offentliga förhandsversionen stöder inte gästkonfiguration att ange beroenden mellan olika maskiner med hjälp av "WaitFor*"-resurser. Det är inte möjligt för en dator att övervaka och vänta tills en annan dator har nått ett tillstånd innan den går vidare.

Omstartshantering är inte tillgängligt i den offentliga förhandsversionen av gästkonfigurationen, $global:DSCMachineStatus inklusive, är inte tillgängligt. Konfigurationer kan inte starta om en nod under eller i slutet av en konfiguration.

Kända kompatibilitetsproblem med moduler som stöds

Modulen i den PowerShell-galleriet modulen som levereras med Windows stöds av Microsoft och har varit en vanlig PsDscResources PSDesiredStateConfiguration uppsättning resurser för DSC. Innan modulen PSDscResources har uppdaterats för DSCv3 bör du vara medveten om följande kända kompatibilitetsproblem.

  • Använd inte resurser från modulen PSDesiredStateConfiguration som levereras med Windows. Växla i stället till PSDscResources .
  • Använd inte resurserna WindowsFeature , , och i WindowsFeatureSet WindowsOptionalFeature WindowsOptionalFeatureSet PsDscResources . Det finns ett känt problem med att läsa in modulen i DISM PowerShell 7.1.3 på Windows Server som kräver en uppdatering.

"nx"-resurserna för Linux som ingick i DSC för Linux-lagringsplatsen skrevs i en kombination av språken C och Python. Eftersom sökvägen till DSC i Linux är att använda PowerShell är de befintliga "nx"-resurserna inte kompatibla med DSCv3. Tills en ny modul som innehåller resurser som stöds för Linux är tillgänglig måste du skapa anpassade resurser.

Samexistens med DSC version 3 och tidigare versioner

DSC version 3 i gästkonfigurationen kan samexistera med äldre versioner som är installerade i Windows och Linux. Implementeringarna är separata. Det finns dock ingen konfliktidentifiering i DSC-versioner, så försök inte att hantera samma inställningar.

Nästa steg