Lägga till parametrar i en konfiguration

Artikel
03/09/2024

Precis som Functions kan konfigurationer parametriseras för att tillåta mer dynamiska konfigurationer baserat på användarindata. Stegen liknar de som beskrivs i Funktioner med parametrar.

Det här exemplet börjar med en grundläggande konfiguration som konfigurerar "Spooler"-tjänsten till "Körs".

Configuration TestConfig
{
    # It is best practice to explicitly import any required resources or modules.
    Import-DSCResource -ModuleName PSDesiredStateConfiguration

    Node localhost
    {
        Service 'Spooler'
        {
            Name = 'Spooler'
            State = 'Running'
        }
    }
}

Inbyggda konfigurationsparametrar

Till skillnad från en funktion lägger dock attributet CmdletBinding till inga funktioner. Förutom vanliga parametrar kan konfigurationer också använda följande inbyggda parametrar, utan att du behöver definiera dem.

Parameter	Beskrivning
`-InstanceName`	Används för att definiera sammansatta konfigurationer
`-DependsOn`	Används för att definiera sammansatta konfigurationer
`-PSDSCRunAsCredential`	Används för att definiera sammansatta konfigurationer
`-ConfigurationData`	Används för att skicka in strukturerade konfigurationsdata för användning i konfigurationen.
`-OutputPath`	Används för att ange var filen "<computername.mof>" ska kompileras

Lägga till egna parametrar i Konfigurationer

Förutom de inbyggda parametrarna kan du även lägga till egna parametrar i dina konfigurationer. Parameterblocket hamnar direkt i konfigurationsdeklarationen, precis som en funktion. Ett konfigurationsparameterblock bör ligga utanför noddeklarationer och ovanför eventuella importinstruktioner. Genom att lägga till parametrar kan du göra konfigurationerna mer robusta och dynamiska.

Configuration TestConfig
{
    param
    (

    )

Lägg till en ComputerName-parameter

Den första parametern som du kan lägga till är en -Computername parameter så att du dynamiskt kan kompilera en ".mof"-fil för alla -Computername som du skickar till konfigurationen. Precis som Functions kan du också definiera ett standardvärde, om användaren inte skickar ett värde för -ComputerName

param
(
    [String]
    $ComputerName="localhost"
)

I konfigurationen kan du sedan ange parametern -ComputerName när du definierar nodblocket.

Node $ComputerName
{

}

Anropa konfigurationen med parametrar

När du har lagt till parametrar i konfigurationen kan du använda dem precis som med en cmdlet.

TestConfig -ComputerName "server01"

Kompilera flera .mof-filer

Node-blocket kan också acceptera en kommaavgränsad lista med datornamn och generera ".mof"-filer för varje. Du kan köra följande exempel för att generera ".mof"-filer för alla datorer som skickas till parametern -ComputerName .

Configuration TestConfig
{
    param
    (
        [String[]]
        $ComputerName="localhost"
    )

    # It is best practice to explicitly import any required resources or modules.
    Import-DSCResource -ModuleName PSDesiredStateConfiguration

    Node $ComputerName
    {
        Service 'Spooler'
        {
            Name = 'Spooler'
            State = 'Running'
        }
    }
}

TestConfig -ComputerName "server01", "server02", "server03"

Avancerade parametrar i konfigurationer

Förutom en -ComputerName parameter kan vi lägga till parametrar för tjänstens namn och tillstånd. I följande exempel läggs ett parameterblock till med en -ServiceName parameter och används för att dynamiskt definiera tjänstresursblocket . Den lägger också till en -State parameter för att dynamiskt definiera tillståndet i tjänstresursblocket .

Configuration TestConfig
{
    param
    (
        [String]
        $ServiceName,

        [String]
        $State,

        [String]
        $ComputerName="localhost"
    )

    # It is best practice to explicitly import any required resources or modules.
    Import-DSCResource -ModuleName PSDesiredStateConfiguration

    Node $ComputerName
    {
        Service $ServiceName
        {
            Name = $ServiceName
            State = $State
        }
    }
}

Anteckning

I mer avancerade scenarier kan det vara mer meningsfullt att flytta dynamiska data till strukturerade konfigurationsdata.

Exempelkonfigurationen tar nu en dynamisk $ServiceName, men om en inte har angetts resulterar kompileringen i ett fel. Du kan lägga till ett standardvärde som det här exemplet.

[String]
$ServiceName="Spooler"

I det här fallet är det dock mer meningsfullt att helt enkelt tvinga användaren att ange ett värde för parametern $ServiceName . Med parameter attributet kan du lägga till ytterligare verifierings- och pipelinestöd till konfigurationens parametrar.

Lägg till attributblocket parameter som i exemplet nedan ovanför valfri parameterdeklaration.

[parameter()]
[String]
$ServiceName

Du kan ange argument för varje parameter attribut för att styra aspekter av den definierade parametern. I följande exempel blir parametern $ServiceNameObligatorisk .

[parameter(Mandatory)]
[String]
$ServiceName

För parametern $State vill vi förhindra att användaren anger värden utanför en fördefinierad uppsättning (t.ex. Kör, Stoppad) ValidationSet*attributet hindrar användaren från att ange värden utanför en fördefinierad uppsättning (till exempel Körs, Stoppad). I följande exempel läggs ValidationSet attributet till i parametern $State . Eftersom vi inte vill göra parametern $StateObligatorisk måste vi lägga till ett standardvärde för den.

[ValidateSet("Running", "Stopped")]
[String]
$State="Running"

Anteckning

Du behöver inte ange ett parameter attribut när du använder ett validation attribut.

Du kan läsa mer om valideringsattributen parameter och i about_Functions_Advanced_Parameters.

Fullständigt parametriserad konfiguration

Nu har vi en parametriserad konfiguration som tvingar användaren att ange en -InstanceName, -ServiceNameoch validerar parametern -State .

Configuration TestConfig
{
    param
    (
        [parameter(Mandatory)]
        [String]
        $ServiceName,

        [ValidateSet("Running","Stopped")]
        [String]
        $State="Running",

        [String]
        $ComputerName="localhost"
    )

    # It is best practice to explicitly import any required resources or modules.
    Import-DSCResource -ModuleName PSDesiredStateConfiguration

    Node $ComputerName
    {
        Service $ServiceName
        {
            Name = $ServiceName
            State = $State
        }
    }
}