Vad är Azure Automation State Configuration?

Slutförd

Du kan använda Azure Automation State Configuration för att säkerställa att de virtuella datorerna i ett klusterområde är i ett konsekvent tillstånd, med samma programvara installerad och samma konfigurationer.

I den här lektionen får du lära dig mer om Funktioner och funktioner i Azure Automation, granska den deklarativa modellen för PowerShell Desired State Configuration (DSC) och utforska dess fördelar.

Azure Automation State Configuration är en Azure-tjänst som bygger på PowerShell. Med den kan du konsekvent distribuera, övervaka på ett tillförlitligt sätt och automatiskt uppdatera önskat tillstånd för alla dina resurser. Azure Automation tillhandahåller de verktyg du behöver för att definiera konfigurationer och tillämpa dem på både verkliga och virtuella datorer.

Varför ska jag använda Azure Automation State Configuration?

Det kan vara svårt och felbenäget att manuellt underhålla en korrekt och konsekvent konfiguration för de servrar som kör dina tjänster. Azure Automation State Configuration använder PowerShell DSC för att lösa dessa utmaningar. Det hanterar DSC-artefakter och DSC-processen centralt.

Azure Automation State Configuration har en inbyggd hämtningsserver. Du kan rikta noder så att de automatiskt tar emot konfigurationer från hämtningsservern, följer det önskade tillståndet och rapporterar tillbaka om deras kompatibilitet. Du kan rikta virtuella eller fysiska Windows- eller Linux-datorer i molnet eller lokalt.

Du kan använda Azure Monitor-loggar för att granska nodernas efterlevnad genom att konfigurera Azure Automation State Configuration för att skicka dessa data.

Vad är PowerShell DSC?

PowerShell DSC är en deklarativ hanteringsplattform som används av Azure Automation State Configuration för att konfigurera, distribuera och kontrollera system. Ett deklarativt programmeringsspråk skiljer avsikten (det du vill göra) från körningen (hur du vill göra det). Du anger vad det önskade tillståndet och låter DSC göra jobbet för att nå dit. Du behöver inte känna till hur man implementerar eller distribuerar en funktion när en DSC-resurs är tillgänglig. I stället kan du fokusera på distributionsstrukturen.

Om du redan använder PowerShell undrar du kanske varför du behöver DSC. Betänk följande exempel.

När du vill skapa en resurs på en Windows-server kan du använda följande PowerShell-kommando:

# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2

Det här skriptet är enkelt och lätt att förstå. Men om du använder det här skriptet i produktion får du flera problem. Tänk på vad som kan hända om skriptet körs flera gånger, eller om User2 det redan har fullständig åtkomst i stället för skrivskyddad åtkomst.

Den här metoden är inte idempotent. Idempotens beskriver en åtgärd som ger samma resultat om du kör den en gång eller 10 001 gånger. För att uppnå idempotence i PowerShell måste du lägga till logik och felhantering. Om filresursen inte finns skapar du den. Om resursen finns behöver du inte skapa den. Om User2 finns men sakna läsåtkomst, så lägger du till läsåtkomst.

PowerShell-skriptet skulle då se ut ungefär så här:

$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
    }
}

Andra specialfall som du inte har tänkt på kan komma i dagen först när problemen uppstår. DSC hanterar sådana oväntade fall automatiskt. Med DSC beskriver du resultatet snarare än den process som krävs för att uppnå detta resultat.

Iöljande DSC-kodfragment visas ett exempel på detta:

Configuration Create_Share
{
   Import-DscResource -Module xSmbShare
   # A node describes the VM to be configured

   Node $NodeName
   {
      # A node definition contains one or more resource blocks
      # A resource block describes the resource to be configured on the node
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyFileShare"
          Path        = "C:\Shared"
          ReadAccess  = "User1"
          FullAccess  = "User2"
          Description = "This is an updated description for this share"
      }
   }
}

I föregående exempel används modulen xSmbShare , som talar om för DSC hur du kontrollerar tillståndet för en filresurs. DSC Resource Kit har fler än 100 resursmoduler, inklusive en för att installera en IIS-plats. Du hittar en länk till DSC Resource Kit i sammanfattningsenheten i slutet av den här modulen.

Du får lära dig mer om PowerShell DSC-kodstrukturen i nästa lektion.

Vad är LCM?

Den lokala konfigurationshanteraren (LCM) är en komponent i Windows Management Framework (WMF) på ett Windows-operativsystem. LCM ansvarar för att uppdatera en nods tillstånd, på samma sätt som en virtuell dator, så att det matchar det önskade tillståndet. Varje gång som LCM körs genomförs följande steg:

  1. Hämta: Hämtar nodens aktuella tillstånd.
  2. Test: Jämför aktuellt tillstånd för en nod med önskat tillstånd med hjälp av ett kompilerat DSC-skript (.mof-fil).
  3. Ange: Uppdateringar noden för att matcha önskat tillstånd som beskrivs i .mof-filen.

Du konfigurerar LCM när du registrerar en virtuell dator med Azure Automation.

Push- och pull-arkitekturer i DSC

LCM på varje nod kan köras i två lägen.

  • Push-läge: En administratör skickar eller push-överför konfigurationerna manuellt till en eller flera noder. LCM ser till att varje nods tillstånd matchar det som anges i konfigurationen.

    Diagram som visar en push-arkitektur i DSC.

  • Pull-läge: En pull-server innehåller konfigurationsinformationen. LCM på varje nod avsöker pull-servern med jämna mellanrum – som standard var 15:e minut – för att få den senaste konfigurationsinformationen. Dessa begäranden betecknas som steg 1 i följande diagram. I steg 2 skickar pull-servern information om eventuella konfigurationsändringar tillbaka till varje nod.

    I pull-läge måste varje nod registreras med pull-tjänsten.

    Diagram som visar en pull-arkitektur i DSC.

Båda lägena har sina fördelar:

  • Push-läget är enkelt att konfigurera. Det behöver inte någon egen dedikerad infrastruktur och kan köras på en bärbar dator. Push-läget är praktiskt när du vill testa funktionerna i DSC. Du kan också använda push-läget för att få en nyligen avbildad dator till önskat grundläggande tillstånd.
  • Pull-läget är användbart i en företagsdistribution som omfattar ett stort antal datorer. LCM avsöker regelbundet pull-servern och säkerställer att noderna är i önskat tillstånd. Eventuella snabbkorrigeringar som används av externa verktyg eller team och som resulterar i konfigurationsavvikelse på enskilda datorer, kommer snabbt att återställas i enlighet med den konfiguration som du har angett. Den här processen kan hjälpa dig att uppnå ett tillstånd av kontinuerlig kompatibilitet för dina säkerhets- och regleringsskyldigheter.

Plattformar och operativsystem som stöds

Azure Automation DSC stöds av Azure Cloud Services och andra molnleverantörer, din lokala infrastruktur eller en hybrid av alla dessa miljöer.

Azure Automation DSC stöder följande operativsystem:

  • Windows
    • Server 2022
    • Server 2019
    • Server 2016
    • Server 2012 R2
    • Server 2012
    • Server 2008 R2 SP1
    • 11
    • 10
    • 8.1
    • 7
  • Linux
    • DSC Linux-tillägget stöder alla Linux-distributioner som anges i PowerShell DSC-dokumentationen.

PowerShell DSC är installerat på alla Linux-datorer som Azure Automation DSC stöder.

DSC-krav för Windows

För Windows-datorer använder vm-tillägget Azure Desired State Configuration (DSC) WMF för att hantera Windows-funktionsversioner som Windows PowerShell DSC och Windows Remote Management (WinRM). Azure DSC stöder WMF 4.0 och senare, så Windows-datorer måste köra Windows Server 2008 R2 SP1, Windows 7 eller senare.

Första gången som Azure DSC-tillägget anropas installerar det en version av WMF som är kompatibel med operativsystemet på alla Windows-versioner förutom Windows Server 2016 och senare. Den senaste versionen av WMF är redan installerad på Windows Server 2016 och senare versioner. När WMF har installerats måste datorn startas om.

WinRM är aktiverat på datornoder som kör Windows Server 2012 eller senare och Windows 7 eller senare.

Proxy-stöd för DSC-agenten finns i Windows-version 1809 och senare. Proxystöd är inte tillgängligt i DSC för tidigare Windows-versioner.

Övriga DSC-krav

Om noderna finns i ett privat nätverk behöver DSC följande port och URL:er för att kunna kommunicera med Automation:

  • Port: Endast TCP 443 krävs för utgående internetåtkomst
  • Global URL – *.azure-automation.net
  • Global URL för US Gov, Virginia: –*.azure-automation.us
  • Agenttjänst: https://<workspaceId>.agentsvc.azure-automation.net

Kontrollera dina kunskaper

1.

Vad är Azure Automation State Configuration?

2.

Ett PowerShell DSC-skript ______________.

3.

Varför ska du använda pull-läge i stället för push-läge för DSC?