컴퓨터 구성에 대한 PowerShell Desired State Configuration의 동작 변경 사항

시작하기 전에 컴퓨터 구성의 개요를 읽어보는 것이 좋습니다.

이 문서의 동영상 연습 사용 가능.

컴퓨터 구성은 PSDSC(PowerShell Desired State Configuration) 버전 3을 사용하여 컴퓨터를 감사하고 구성합니다. DSC 구성은 컴퓨터가 충족해야 하는 상태를 정의합니다. 컴퓨터 구성에서 DSC를 구현하는 방법에는 중요한 차이점이 많이 있습니다.

컴퓨터 구성은 PowerShell 7 교차 플랫폼을 사용합니다

컴퓨터 구성은 Windows 및 Linux 관리 환경이 일관될 수 있도록 설계되었습니다. 두 운영 체제 환경에서 PowerShell DSC 지식이 있는 사용자는 스크립팅 기술을 사용하여 구성을 만들고 게시할 수 있습니다.

컴퓨터 구성은 PowerShell DSC 버전 3만 사용하며 Linux용 DSC 또는 해당 리포지토리에 포함된 nx* 공급자의 이전 구현에 의존하지 않습니다.

버전 1.26.33부터 컴퓨터 구성은 Windows용 PowerShell 7.1.2 및 Linux용 PowerShell 7.2 미리 보기 6에서 작동합니다. 버전 7.2부터 PSDesiredStateConfiguration 모듈은 PowerShell 설치의 일부에서 이동되어 대신 PowerShell 갤러리의 모듈로 설치됩니다.

여러 구성

컴퓨터 구성은 동일한 컴퓨터에 여러 구성 할당을 지원합니다. 컴퓨터 구성 확장의 운영 체제 내에서 특별한 단계가 필요하지 않습니다. 부분 구성 을 구성할 필요가 없습니다.

종속성은 구성별로 관리됩니다.

사용 가능한 도구를 사용하여 구성을 패키지하면 구성에 필요한 종속성이 .zip 파일에 포함됩니다. 컴퓨터는 각 구성에 대한 고유한 폴더로 콘텐츠를 추출합니다. 컴퓨터 구성 확장이 제공하는 에이전트는 각 구성에 대한 전용 PowerShell 세션을 만듭니다. 자동 모듈 로드를 패키지가 추출된 경로로만 제한하는 $Env:PSModulePath를 사용합니다.

이 변경에는 여러 가지 이점이 있습니다.

• 동일한 컴퓨터에서 각 구성에 대해 서로 다른 모듈 버전을 사용할 수 있습니다.
• 컴퓨터에 구성이 더 이상 필요하지 않으면 에이전트는 구성이 추출된 전체 폴더를 안전하게 삭제합니다. 구성 전반에 걸쳐 공유 종속성을 관리할 필요가 없습니다.
• 중앙 서비스에서 모듈의 여러 버전을 관리할 필요는 없습니다.

아티팩트는 패키지로 관리됩니다.

Azure Automation State Configuration 기능에는 모듈 및 구성 스크립트에 대한 아티팩트 관리가 포함됩니다. 둘 다 서비스에 게시되면 스크립트를 MOF 형식으로 컴파일할 수 있습니다. 마찬가지로 Windows 끌어오기 서버는 웹 서비스 인스턴스에서 구성 및 모듈을 관리해야 했습니다. 이와 대조적으로 DSC 확장에는 모든 아티팩트가 함께 패키지되고 HTTPS 요청을 사용하여 대상 컴퓨터에서 액세스할 수 있는 위치에 저장되는 간략한 모델이 있습니다. Azure Blob Storage는 아티팩트 호스팅에 널리 사용되는 옵션입니다.

컴퓨터 구성은 모든 아티팩트가 함께 패키지되고 HTTPS를 통해 대상 컴퓨터에서 액세스되는 간소화된 모델만 사용합니다. 서비스에서 모듈, 스크립트 또는 컴파일을 게시할 필요가 없습니다. 한 가지 변경 사항은 패키지에 항상 컴파일된 MOF를 포함해야 한다는 것입니다. 패키지에 스크립트 파일을 포함하고 대상 컴퓨터에서 컴파일할 수 없습니다.

사용자 지정 구성 패키지의 최대 크기

Azure Automation State Configuration에서 DSC 구성은 크기가 제한됩니다. 컴퓨터 구성은 압축 전 100MB의 총 패키지 크기를 지원합니다. 패키지 내의 MOF 파일 크기에 대한 구체적인 제한은 없습니다.

구성 모드는 패키지 아티팩트에서 설정됩니다

구성 패키지를 만들 때 다음 옵션을 사용하여 모드가 설정됩니다.

• Audit - 컴퓨터의 준수를 확인합니다. 변경이 발생하지 않습니다.
• AuditandSet - 컴퓨터의 준수 상태를 확인하고 수정합니다. 컴퓨터가 규정을 준수하지 않으면 변경이 발생합니다.

각 구성이 서로 다른 모드로 적용될 수 있으므로 모드는 로컬 Configuration Manager 서비스가 아닌 패키지에서 설정됩니다.

Azure Resource Manager를 통한 매개 변수 지원

컴퓨터 구성 할당의 configurationParameter 속성 배열에 의해 설정된 매개 변수는 파일이 컴퓨터에 저장될 때 구성 MOF 파일 내의 정적 텍스트를 덮어씁니다. 매개 변수를 사용하면 사용자 지정이 가능하며 운영자는 컴퓨터 내에서 명령을 실행할 필요 없이 서비스 API의 변경 내용을 제어할 수 있습니다.

컴퓨터 구성 할당에 값을 전달하는 Azure Policy의 매개 변수는 문자열 형식이어야 합니다. DSC 리소스가 배열을 지원해도 매개 변수를 통해 배열을 전달할 수 없습니다.

외부 컴퓨터에서 트리거 설정

이전 버전의 DSC에서는 WinRM 원격 연결에 의존하지 않고 많은 사용자 지정 코드 없이 대규모로 드리프트를 수정해야 했습니다. 게스트 구성은 이 문제를 해결합니다. 컴퓨터 구성 사용자는 주문형 수정을 통해 드리프트 수정을 제어할 수 있습니다.

시퀀스에는 Get 메서드가 포함됩니다.

컴퓨터 구성이 컴퓨터를 감사하거나 구성하는 경우, Windows 및 Linux 모두 동일한 이벤트 시퀀스가 사용됩니다. 동작의 주목할 만한 변경은 Get 메서드가 머신 상태에 대한 세부 정보를 반환하기 위해 서비스에서 호출되는 것입니다.

1. 에이전트는 먼저 Test를 실행하여 구성이 올바른 상태인지 확인합니다.
2. 패키지가 Audit로 설정된 경우 함수에서 반환된 부울 값은 게스트 할당에 대한 Azure Resource Manager 상태가 Compliant 또는 NonCompliant인지 확인합니다.
3. 패키지가 AuditandSet로 설정된 경우, 부울 값은 Set 메서드를 사용하여 구성을 적용하여 컴퓨터를 수정할지 여부를 결정합니다. Test 메서드가 $false를 반환하면 Set가 실행됩니다. Test가 $true를 반환하면 Set는 실행되지 않습니다.
4. 마지막으로, 공급자는 Get를 실행하여 각 설정의 현재 상태를 반환하므로 컴퓨터가 규정을 준수하지 않는 이유 및 현재 상태가 규정을 준수하는지 확인하기 위한 세부 정보를 사용할 수 있습니다.

Get에 대한 특별 요구 사항

DSC Get 메서드에는 DSC에 필요하지 않은 컴퓨터 구성에 대한 특별한 요구 사항이 있습니다.

• 반환된 해시 테이블에는 Reasons라는 속성이 포함되어야 합니다.
• Reasons 속성은 배열이어야 합니다.
• 배열의 각 항목은 Code 및 Phrase라는 키가 있는 해시 테이블이어야 합니다.
• 해시 테이블 이외의 값은 반환되어서는 안 됩니다.

서비스는 Reasons 속성을 사용하여 준수 정보를 표시하는 방식을 표준화합니다. 이유의 각 항목을 리소스의 규정 준수 여부에 대한 메시지로 생각할 수 있습니다. 두 가지 이상의 이유로 리소스가 규정을 준수하지 않을 수 있으므로 속성은 배열입니다.

Code 및 Phrase 속성이 서비스에 필요합니다. 사용자 지정 리소스를 작성할 때 리소스가 규정을 준수하지 않는 이유를 표시하려는 텍스트를 Phrase 값으로 설정합니다. Code에는 특정 형식 요구 사항이 있으므로 감사를 수행하는 데 사용되는 리소스에 대한 정보를 명확하게 보고할 수 있습니다. 이 솔루션은 게스트 구성을 확장 가능하게 만듭니다. 출력을 Phrase 속성에 대한 문자열 값으로 반환할 수 있는 한 모든 명령을 실행할 수 있습니다.

• Code(문자열): 반복되는 리소스 이름과 이유에 대한 식별자로 공백이 없는 짧은 이름입니다. 이 세 값은 공백 없이 콜론으로 구분되어야 합니다.
  • 예를 들어 registry:registry:keynotpresent입니다.
• Phrase(문자열): 설정이 규정을 준수하지 않는 이유를 설명하는 사람이 읽을 수 있는 텍스트입니다.
  • 예를 들어 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
}

명령줄 도구를 사용하여 Get에서 반환되는 정보를 가져올 때 도구가 예상하지 못한 출력을 반환할 수도 있습니다. PowerShell에서 출력을 캡처하더라도 출력이 표준 오류로 기록되었을 수도 있습니다. 이 문제를 방지하려면 출력을 Null로 리디렉션하는 것이 좋습니다.

Reasons 속성 포함 클래스

스크립트 기반 리소스(Windows만 해당)에서는 Reasons 클래스가 다음과 같이 스키마 MOF 파일에 포함됩니다.

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

클래스 기반 리소스(Windows 및 Linux)에서 Reason 클래스는 다음과 같이 PowerShell 모듈에 포함됩니다. Linux는 대/소문자를 구분하므로 Code의 C와 Phrase의 P는 대문자로 시작해야 합니다.

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

리소스에 필수 속성이 있는 경우, 해당 속성도 Get에 의해 Reason 클래스와 병렬로 반환되어야 합니다. Reason가 포함되지 않으면 서비스는 Get에 대한 값 입력과 Get에서 반환된 값을 비교하는 "catch-all" 동작을 포함하며 Reason와 상세 비교를 제공합니다.

구성 이름

사용자 지정 구성의 이름은 모든 위치에서 일관되어야 합니다. 다음 항목은 이름이 동일해야 합니다.

• 콘텐츠 패키지의 .zip 파일
• MOF 파일의 구성 이름
• Azure Resource Manager 템플릿의 컴퓨터 구성 할당 이름

Windows PowerShell에서 명령 실행

DSC 리소스에서 아래 패턴을 사용하여 PowerShell에서 Windows 모듈을 실행할 수 있습니다. 아래 패턴은 PowerShell 대신 Windows PowerShell을 실행하여 Windows PowerShell에서 사용 가능한 필수 모듈을 발견하도록 임시로 PSModulePath를 설정합니다. 이 샘플은 보안 웹 서버 기본 제공 DSC 리소스에 사용되는 DSC 리소스를 수정한 코드 조각입니다.

이 패턴은 Windows PowerShell에서 실행되도록 PowerShell 실행 경로를 일시적으로 설정하며, 이 경우에는 Get-WindowsFeature인 필수 cmdlet을 검색합니다. 명령의 출력이 반환된 다음, 호환성 요구 사항에 맞게 표준화됩니다. cmdlet이 실행되면 $env:PSModulePath가 원래 경로로 다시 설정됩니다.

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

컴퓨터 구성 공개 미리 보기 중에는 사용할 수 없는 일반적인 DSC 기능

공개 미리 보기 중에는 컴퓨터 구성이 WaitFor* 리소스를 사용한 컴퓨터 간 종속성 지정을 지원하지 않습니다. 한 컴퓨터가 진행되기 전에 다른 컴퓨터가 특정 상태에 도달할 때까지 모니터링하고 기다릴 수는 없습니다.

재부팅 처리는 컴퓨터 구성의 공개 미리 보기 릴리스에서 사용할 수 없으며, $global:DSCMachineStatus에서 사용할 수 없습니다. 구성은 구성 중에 또는 구성이 끝날 때 노드를 재부팅할 수 없습니다.

지원되는 모듈의 알려진 호환성 문제

PowerShell 갤러리의 PsDscResources 모듈과 Windows와 함께 제공되는 PSDesiredStateConfiguration 모듈은 Microsoft에서 지원하며 DSC에 일반적으로 사용되는 리소스 집합입니다. PSDscResources 모듈이 DSCv3용으로 업데이트될 때까지 다음과 같은 알려진 호환성 문제에 유의해야 합니다.

• Windows와 함께 제공되는 PSDesiredStateConfiguration 모듈의 리소스를 사용하지 마세요. 대신 PSDscResources로 전환합니다.
• PsDscResources에서 WindowsFeature, WindowsFeatureSet, WindowsOptionalFeature 및 WindowsOptionalFeatureSet 리소스를 사용하지 마세요. 업데이트가 필요한 Windows Server의 PowerShell 7.1.3에서 DISM 모듈을 로드하는 데 알려진 문제가 있습니다.

Linux용 DSC 리포지토리에 포함된 Linux용 nx* 리소스는 C 언어와 Python의 조합으로 작성되었습니다. Linux의 DSC 경로는 PowerShell을 사용하는 것이므로 기존 nx* 리소스는 DSCv3과 호환되지 않습니다. Linux에 대해 지원되는 리소스를 포함하는 새 모듈을 사용할 수 있게 될 때까지 사용자 지정 리소스를 작성해야 합니다.

DSC 버전 3 및 이전 버전과 공존

컴퓨터 구성의 DSC 버전 3은 Windows 및 Linux에 설치된 이전 버전과 공존할 수 있습니다. 구현은 별개입니다. 그러나 DSC 버전 간에는 충돌이 검색되지 않으므로 동일한 설정을 관리하지 마세요.

다음 단계

• 컴퓨터 구성 개요를 읽습니다.
• 사용자 지정 컴퓨터 구성 패키지를 개발합니다.
• GuestConfiguration 모듈을 사용하여 사용자 환경의 대규모 관리를 위한 Azure Policy 정의를 생성합니다.
• Azure Portal을 사용하여 사용자 지정 정책 정의를 할당합니다.
• 컴퓨터 구성에 대한 규정 준수 세부 정보 정책 할당을 보는 방법을 알아봅니다.