Sdílet prostřednictvím

Změny chování v Konfiguraci požadovaného stavu PowerShellu pro konfiguraci počítače

  • Článek

Než začnete, je vhodné si přečíst přehled konfigurace počítače.

K dispozici je video s návodem k tomuto dokumentu.

Konfigurace počítače používá k auditování a konfiguraci počítačů powershellovou konfiguraci požadovaného stavu (PSDSC) verze 2. Konfigurace DSC definuje stav, ve který má být počítač. V tom, jak se DSC implementuje v konfiguraci počítače, je mnoho hleitelných rozdílů.

Konfigurace počítače používá PowerShell 7 pro různé platformy

Konfigurace počítače je navržená tak, aby prostředí pro správu Windows a Linuxu bylo konzistentní. V obou prostředích operačního systému může někdo s znalostmi PowerShellU DSC vytvářet a publikovat konfigurace pomocí skriptování.

Konfigurace počítače používá pouze PowerShell DSC verze 3 a nespoléhá na předchozí implementaci DSC pro Linux ani na nx* poskytovatele zahrnuté v daném úložišti.

Od verze 1.26.33 funguje konfigurace počítače v PowerShellu 7.1.2 pro Windows a PowerShell 7.2 Preview 6 pro Linux. Od verze 7.2 se modul PSDesiredStateConfiguration přesunul z instalace PowerShellu a místo toho se nainstaluje jako modul z Galerie prostředí PowerShell.

Více konfigurací

Konfigurace počítače podporuje přiřazování více konfigurací ke stejnému počítači. V rámci operačního systému rozšíření konfigurace počítače nejsou potřeba žádné zvláštní kroky. Není nutné konfigurovat částečné konfigurace.

Závislosti se spravují podle konfigurace.

Pokud je konfigurace zabalená pomocí dostupných nástrojů, jsou požadované závislosti pro konfiguraci zahrnuty do .zip souboru. Počítače extrahují obsah do jedinečné složky pro každou konfiguraci. Agent doručovaný rozšířením konfigurace počítače vytvoří vyhrazenou relaci PowerShellu pro každou konfiguraci. Používá $Env:PSModulePath omezení automatického načítání modulů pouze na cestu, do které se balíček extrahoval.

Tato změna má několik výhod:

  • Pro každou konfiguraci je možné použít různé verze modulů na stejném počítači.
  • Pokud už není na počítači potřeba konfigurace, agent bezpečně odstraní celou složku, ve které se konfigurace extrahovala. Sdílené závislosti mezi konfiguracemi nemusíte spravovat.
  • Není nutné spravovat více verzí jakéhokoli modulu v centrální službě.

Artefakty se spravují jako balíčky.

Funkce Azure Automation State Configuration zahrnuje správu artefaktů pro moduly a konfigurační skripty. Po publikování obou souborů do služby je možné skript zkompilovat do formátu MOF. Podobně systém Windows Pull Server také vyžadoval správu konfigurací a modulů v instanci webové služby. Naproti tomu rozšíření DSC má zjednodušený model, ve kterém jsou všechny artefakty zabalené a uložené v umístění přístupném z cílového počítače pomocí požadavku HTTPS. Azure Blob Storage je oblíbená možnost hostování artefaktů.

Konfigurace počítače používá jenom zjednodušený model, ve kterém jsou všechny artefakty zabalené společně a přístupné z cílového počítače přes PROTOKOL HTTPS. Ve službě není nutné publikovat moduly, skripty ani kompilovat. Jednou z změn je, že balíček by měl vždy obsahovat zkompilovaný soubor MOF. Do balíčku není možné zahrnout soubor skriptu a zkompilovat ho na cílovém počítači.

Maximální velikost vlastního konfiguračního balíčku

Ve službě Azure Automation State Configuration byly konfigurace DSC omezené na velikost. Konfigurace počítače podporuje celkovou velikost balíčku 100 MB před kompresí. Velikost souboru MOF v balíčku není nijak omezena.

Režim konfigurace je nastavený v artefaktu balíčku.

Při vytváření konfiguračního balíčku se režim nastaví pomocí následujících možností:

  • Audit - Ověřuje dodržování předpisů stroje. Neprovedou se žádné změny.
  • AuditandSet – Ověří a opraví stav dodržování předpisů počítače. Pokud počítač nevyhovuje předpisům, provede se změny.

Režim se nastavuje v balíčku místo ve službě Local Configuration Manager , protože každá konfigurace se dá použít v jiném režimu.

Podpora parametrů prostřednictvím Azure Resource Manageru

Parametry nastavené polem vlastností configurationParameter v přiřazeních konfigurace počítače přepíší statický text v konfiguračním souboru MOF, když je soubor uložen na počítači. Parametry umožňují přizpůsobení a operátora k řízení změn z rozhraní API služby, aniž by bylo nutné spouštět příkazy v rámci počítače.

Parametry ve službě Azure Policy, které předávají hodnoty přiřazení konfigurace počítače, musí být typu řetězce . Není možné předávat pole prostřednictvím parametrů, i když prostředek DSC podporuje pole.

Sada aktivačních událostí z vnějšího počítače

V předchozích verzích DSC došlo k opravě posunu ve velkém měřítku bez velkého vlastního kódu a závislosti na vzdálených připojeních WinRM. Konfigurace hosta tento problém řeší. Uživatelé konfigurace počítače mají kontrolu nad opravou posunu prostřednictvím nápravy na vyžádání.

Sequence zahrnuje metodu Get.

Když konfigurace počítače provede audit nebo nakonfiguruje počítač, použije se stejná posloupnost událostí pro Windows i Linux. Zásadní změnou chování je to, že Get metoda je volána službou, aby vrátila podrobnosti o stavu počítače.

  1. Agent se nejprve spustí Test a určí, jestli je konfigurace ve správném stavu.
  2. Pokud je balíček nastavený na Audit, logická hodnota vrácená funkcí určuje, jestli má být Compliant stav Azure Resource Manageru pro přiřazení hosta nebo NonCompliant.
  3. Pokud je balíček nastaven na AuditandSet, logická hodnota určuje, zda se má počítač napravit použitím konfigurace pomocí Set metody. Pokud metoda Test vrátí $false, Set je spuštěna. Pokud Test se vrátí $true, pak Set se nespustí.
  4. Nakonec se poskytovatel spustí Get , aby vrátil aktuální stav každého nastavení, takže jsou k dispozici podrobnosti o tom, proč počítač nedodržuje předpisy, a potvrdit, že aktuální stav vyhovuje.

Zvláštní požadavky pro get

Metoda DSC Get má zvláštní požadavky na konfiguraci počítače, která nebyla pro DSC potřebná.

  • Vrácená tabulka hash by měla obsahovat vlastnost s názvem Důvody.
  • Vlastnost Důvody musí být pole.
  • Každá položka v poli by měla být tabulka hash s klíči s názvem Kód a Fráze.
  • Neměly by se vrátit žádné hodnoty jiné než tabulka hash.

Vlastnost Důvody používá služba ke standardizaci způsobu prezentování informací o dodržování předpisů. Každou položku si můžete představit z důvodů jako zprávu o tom, jak prostředek je nebo nedodržuje předpisy. Vlastnost je pole, protože prostředek může být mimo dodržování předpisů z více důvodů.

Služba očekává vlastnosti Code a Phrase . Při vytváření vlastního prostředku nastavte text, který chcete zobrazit jako důvod, proč prostředek nevyhovuje hodnotě fráze. Kód má specifické požadavky na formátování, takže vytváření sestav může jasně zobrazovat informace o prostředku použitém k provedení auditu. Toto řešení umožňuje rozšiřitelnost konfigurace hosta. Jakýkoli příkaz může být spuštěn, pokud lze výstup vrátit jako řetězcovou hodnotu pro vlastnost Phrase .

  • Kód (řetězec): Název prostředku, opakuje se a pak krátký název bez mezer jako identifikátor z důvodu. Tyto tři hodnoty by měly být oddělené dvojtečky bez mezer.
    • Příkladem by bylo registry:registry:keynotpresent
  • Fráze (řetězec): Text čitelný pro člověka, který vysvětluje, proč nastavení nedodržuje předpisy.
    • Příkladem by bylo The registry key $key isn't present on the machine.
$reasons = @()
$reasons += @{
  Code   = 'Name:Name:ReasonIdentifier'
  Phrase = 'Explain why the setting is not compliant'
}
return @{
    reasons = $reasons
}

Při použití nástrojů příkazového řádku k získání informací, které se vrátí, Getmůžete najít výstup, který jste neočekádali. I když zachytíte výstup v PowerShellu, může být výstup také zapsán do standardní chyby. Pokud se chcete tomuto problému vyhnout, zvažte přesměrování výstupu na hodnotu null.

Vlastnost Reasons embedded – třída

V prostředcích založených na skriptech (pouze Windows) je třída Reasons zahrnuta do souboru MOF schématu následujícím způsobem.

[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[];
};

V prostředcích založených na třídách (Windows a Linux) je třída Reason zahrnutá v modulu PowerShellu následujícím způsobem. V Linuxu se rozlišují malá a velká písmena, proto CCodeP musí být velká a velká Phrase písmena.

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

Pokud má prostředek požadované vlastnosti, měly by být tyto vlastnosti vráceny Get paralelně s reason třídy. Pokud důvod není zahrnutý, služba obsahuje chování "catch-all", které porovnává vstupní Get hodnoty s hodnotami vrácenými Geta poskytuje podrobné porovnání jako důvod.

Názvy konfigurací

Název vlastní konfigurace musí být konzistentní všude. Tyto položky musí mít stejný název:

  • Soubor .zip balíčku obsahu
  • Název konfigurace v souboru MOF
  • Název přiřazení konfigurace počítače v šabloně Azure Resource Manageru

Spouštění příkazů ve Windows PowerShellu

Spouštění modulů Windows v PowerShellu je možné dosáhnout pomocí následujícího vzoru v prostředcích DSC. Následující vzor dočasně nastaví PSModulePath spuštění Windows PowerShellu místo PowerShellu, aby zjistil požadované moduly dostupné ve Windows PowerShellu. Tato ukázka je fragment kódu přizpůsobený z prostředku DSC použitého v integrovaném prostředku DSC zabezpečeného webového serveru .

Tento model dočasně nastaví cestu spuštění PowerShellu z Prostředí Windows PowerShell a zjistí požadovanou rutinu, což je Get-WindowsFeaturev tomto případě . Výstup příkazu se vrátí a pak standardizuje pro požadavky na kompatibilitu. Po spuštění $env:PSModulePath rutiny se nastaví zpět na původní cestu.

# The Get-WindowsFeature cmdlet needs to be run through Windows PowerShell
# rather than through PowerShell, which is what the Policy engine runs.
$null = Invoke-Command -ScriptBlock {
    param ([string]$FileName)

    $InitialPSModulePath   = $env:PSModulePath
    $WindowsPSFolder       = "$env:SystemRoot\System32\WindowsPowershell\v1.0"
    $WindowsPSExe          = "$WindowsPSFolder\powershell.exe"
    $WindowsPSModuleFolder = "$WindowsPSFolder\Modules"
    $GetFeatureScriptBlock = {
        param([string]$FileName)

        if (Get-Command -Name Get-WindowsFeature -ErrorAction SilentlyContinue) {
            Get-WindowsFeature -Name Web-Server |
                ConvertTo-Json |
                Out-File $FileName
        } else {
            Add-Content -Path $FileName -Value 'NotServer'
        }
    }

    try {
        # Set env variable to include Windows Powershell modules so we can find
        # the Get-WindowsFeature cmdlet.
        $env:PSModulePath = $WindowsPSModuleFolder
        # Call Windows PowerShell to get the info about the Web-Server feature
        & $WindowsPSExe -command $WindowsFeatureScriptBlock -args $FileName
    } finally {
        # Reset the env variable even if there's an error.
        $env:PSModulePath = $InitialPSModulePath
    }
}

Běžné funkce DSC nejsou během konfigurace počítače ve verzi Public Preview dostupné

Ve verzi Public Preview konfigurace počítače nepodporuje zadávání závislostí mezi počítači pomocí WaitFor* prostředků. Není možné, aby jeden počítač sledoval a čekal, až se jiný počítač dostane do stavu, než bude pokračovat.

Zpracování restartování není k dispozici ve verzi Public Preview konfigurace počítače, včetně toho, že $global:DSCMachineStatus není k dispozici. Konfigurace nemůžou restartovat uzel během konfigurace ani na konci konfigurace.

Známé problémy s kompatibilitou s podporovanými moduly

Modul PsDscResources v modulu Galerie prostředí PowerShell a modulu PSDesiredStateConfiguration, který se dodává s Windows, podporuje Microsoft a byl běžně používaným souborem prostředků pro DSC. Dokud se modul PSDscResources neaktualizuje pro DSCv3, mějte na paměti následující známé problémy s kompatibilitou.

  • Nepoužívejte prostředky z modulu PSDesiredStateConfiguration , který je dodáván s Windows. Místo toho přepněte na PSDscResources.
  • Nepoužívejte prostředky WindowsFeature, , WindowsFeatureSetWindowsOptionalFeaturea WindowsOptionalFeatureSet prostředky v PsDscResources. Při načítání modulu DISM v PowerShellu 7.1.3 na Windows Serveru je známý problém, který vyžaduje aktualizaci.

Prostředky nx* pro Linux, které byly součástí úložiště DSC pro Linux , byly napsány v kombinaci jazyků C a Pythonu. Vzhledem k tomu, že cesta vpřed pro DSC v Linuxu je použití PowerShellu, stávající nx* prostředky nejsou kompatibilní s DSCv3. Dokud nebude k dispozici nový modul obsahující podporované prostředky pro Linux, bude nutné vytvářet vlastní prostředky.

Koexistence s DSC verze 3 a předchozími verzemi

DSC verze 3 v konfiguraci počítače může existovat společně se staršími verzemi nainstalovanými ve Windows a Linuxu. Tyto implementace jsou oddělené. Ve verzích DSC ale není žádná detekce konfliktů, proto se nepokoušejte spravovat stejná nastavení.

Další kroky