시연: MOF 파일을 실행하는 연결 생성 - AWS Systems Manager
Amazon S3를 사용하여 아티팩트 저장MOF 파일에서 자격 증명 확인MOF 파일에서 토큰 사용사전 조건MOF 파일을 실행하는 연결 생성문제 해결DSC 리소스 규정 준수 세부 정보 보기

시연: MOF 파일을 실행하는 연결 생성

MOF(Management Object Format) 파일을 실행하여 AWS-ApplyDSCMofs SSM 문서를 사용해 AWS Systems Manager의 기능인 State Manager에서 Windows Server 관리형 노드에 대해 원하는 상태를 적용할 수 있습니다. AWS-ApplyDSCMofs 문서에는 2가지 실행 모드가 있습니다. 첫 번째 모드에서는 관리형 노드가 지정된 MOF 파일에 정의된 원하는 상태인지 검사해 보고하도록 연결을 구성할 수 있습니다. 두 번째 모드에서는 MOF 파일에 정의된 리소스와 그 값을 기반으로 MOF 파일을 실행하고 노드의 구성을 변경할 수 있습니다. AWS-ApplyDSCMofs 문서를 사용하면 로컬 공유인 Amazon Simple Storage Service(Amazon S3) 또는 HTTPS 도메인을 사용하는 안전한 웹 사이트에서 MOF 구성 파일을 다운로드하고 실행할 수 있습니다.

State Manager는 각 연결 실행 중 개별 MOF 파일의 상태를 기록 및 보고합니다. State Manager는 또한 각 MOF 파일 실행의 출력도 규정 준수 이벤트로 보고하며, 이러한 내용은 AWS Systems Manager 규정 준수 페이지에서 확인할 수 있습니다.

MOF 파일 실행은 PowerShell DSC(Windows PowerShell Desired State Configuration)에서 빌드됩니다. PowerShell DSC는 Windows 시스템 구성, 배포 및 관리에 사용되는 서술식 플랫폼입니다. PowerShell DSC를 사용해 관리자는 DSC 구성이라는 간단한 텍스트 문서의 형식으로 서버 구성 방식을 설명할 수 있습니다. PowerShell DSC 구성은 할 일이 명시된 특수화된 PowerShell 스크립트이지만 여기에는 할 일 수행 방식은 나와 있지 않습니다. 구성을 실행하면 MOF 파일이 생성됩니다. MOF 파일은 하나 이상의 서버에 적용해 해당 서버에 대해 원하는 구성을 얻을 수 있습니다. PowerShell DSC 리소스는 구성 적용의 실제 작업을 수행합니다. 자세한 내용은 Windows PowerShell Desired State Configuration 개요를 참조하십시오.

Amazon S3를 사용하여 아티팩트 저장

Amazon S3를 사용하여 PowerShell 모듈, MOF 파일, 규정 준수 보고서 또는 상태 보고서를 저장하는 경우 AWS Systems Manager SSM Agent에서 사용하는 AWS Identity and Access Management(IAM) 역할에는 버킷에 대한 GetObject 및 ListBucket 권한이 있어야 합니다. 이러한 권한을 제공하지 않으면 시스템에서는 액세스 거부됨 오류가 반환됩니다. 다음은 Amazon S3에 아티팩트 저장에 대한 중요 정보입니다.

  • 버킷이 다른 AWS 계정에 있는 경우 해당 계정(또는 IAM 역할)에 GetObject 및 ListBucket 권한을 부여하는 버킷 리소스 정책을 생성합니다.

  • 사용자 정의 DSC 리소스를 사용하려는 경우 Amazon S3 버킷에서 이러한 리소스를 다운로드할 수 있습니다. 또한 PowerShell 갤러리에서 자동으로 설치할 수도 있습니다.

  • Amazon S3를 모듈 소스로 사용하는 경우 다음 대/소문자를 구분하는 ModuleName_ModuleVersion.zip 형식의 Zip 파일로 모듈을 업로드해야 합니다. 예: MyModule_1.0.0.zip.

  • 모든 파일이 버킷 루트에 있어야 합니다. 폴더 구조는 지원되지 않습니다.

MOF 파일에서 자격 증명 확인

자격 증명은 AWS Secrets Manager 또는 AWS Systems Manager Parameter Store를 사용하여 확인합니다. 그러면 자동 자격 증명 교체를 설정할 수 있습니다. 또한 덕분에 DSC가 MOF를 다시 배포하지 않고 서버에 자격 증명을 자동으로 전파할 수 있습니다.

구성에 AWS Secrets Manager 암호를 사용하려면 사용자 이름이 자격 증명을 포함한 암호의 SecretId 또는 SecretARN인 PSCredential 객체를 생성합니다. 암호에 대해 모든 값을 지정할 수 있습니다. 이 값은 무시됩니다. 다음은 한 예입니다.

Configuration MyConfig
{
   $ss = ConvertTo-SecureString -String 'a_string' -AsPlaintext -Force
   $credential = New-Object PSCredential('a_secret_or_ARN', $ss)

    Node localhost
    {
       File file_name
       {
           DestinationPath = 'C:\MyFile.txt'
           SourcePath = '\\FileServer\Share\MyFile.txt'
           Credential = $credential
       }
    }
}

구성 데이터의 PsAllowPlaintextPassword 설정을 사용하여 MOF를 컴파일합니다. 자격 증명에는 레이블만 포함되기 때문에 괜찮습니다.

Secrets Manager에서 노드가 IAM Managed 관리형 정책과 선택적으로 암호 리소스 정책(있는 경우)에 GetSecretValue 액세스를 가지고 있는지 확인합니다. DSC 작업을 수행하려면 암호가 다음과 같은 형식이어야 합니다.

{ 'Username': 'a_name', 'Password': 'a_password' }

암호에는 다른 속성(예: 교체에 사용되는 속성)이 있을 수 있지만 최소한 사용자 이름 및 암호 속성은 있어야 합니다.

두 개의 다른 사용자 및 암호가 있고 교체 AWS Lambda 함수가 이러한 사용자 및 암호 간에 전환하는 다중 사용자 교체 방법을 사용하는 것이 좋습니다. 이 방법을 사용하면 활성 계정을 여러 개 가질 수 있고, 교체 중 사용자를 잠글 위험이 사라집니다.

MOF 파일에서 토큰 사용

토큰은 MOF 파일 컴파일 후 리소스 속성 값을 수정할 수 있는 기능을 제공합니다. 따라서 유사한 구성이 필요한 여러 서버에서 공통 MOF 파일을 다시 사용할 수 있습니다.

토큰 대체는 유형 String의 리소스 속성에 대해서만 작동합니다. 그러나 리소스에 중첩된 CIM 노드 속성이 있는 경우 해당 CIM 노드의 String 속성에서 토큰을 확인합니다. 숫자 또는 배열에는 토큰 대체를 사용할 수 없습니다.

예를 들어, xComputerManagement 리소스를 사용하고 DSC를 사용하여 컴퓨터의 이름을 바꾸려고 하는 시나리오에 대해 생각해 보십시오. 일반적으로 해당 컴퓨터 전용 MOF 파일이 필요합니다. 그러나 토큰 지원을 통해 단일 MOF 파일을 생성해 모든 노드에 적용할 수 있습니다. MOF에 컴퓨터 이름을 하드 코딩하는 대신 ComputerName 속성에서 인스턴스 태그 유형 토큰을 사용할 수 있습니다. 이 값은 MOF 구문 분석 중 확인됩니다. 다음 예를 참조하세요.

Configuration MyConfig
{
    xComputer Computer
    {
        ComputerName = '{tag:ComputerName}'
    }
}

그런 다음 Systems Manager 콘솔에서 관리형 노드에 태그를 설정하거나 Amazon EC2 콘솔에서 Amazon Elastic Compute Cloud(Amazon EC2) 태그를 설정합니다. 문서를 실행할 때 스크립트가 인스턴스 태그의 값에 대한 {tag:ComputerName} 토큰을 대체합니다.

또한 다음 예와 같이 여러 태그를 단일 속성으로 통합할 수도 있습니다.

Configuration MyConfig
{
    File MyFile
    {
        DestinationPath = '{env:TMP}\{tag:ComputerName}'
        Type = 'Directory'
    }
}

사용 가능한 다음과 같은 5가지 다른 유형의 토큰이 있습니다.

  • tag: Amazon EC2 또는 관리형 노드 태그입니다.

  • tagb64: tag와 동일하지만 시스템에서 값을 디코딩하는 데 base64를 사용합니다. 따라서 태그 값에 특수 문자를 사용할 수 있습니다.

  • env: 환경 변수를 확인합니다.

  • ssm: Parameter Store 값입니다. String 및 Secure String 유형만 지원됩니다.

  • tagssm: tag와 동일하지만 tag가 노드에 대해 설정되지 않은 경우 시스템에서는 이름이 동일한 Systems Manager 파라미터에서 값을 확인하려고 합니다. 이는 '기본 전역 값'이 필요하지만 단일 노드에서 이 값을 재정의하길 원하는 경우 유용합니다(예: 단일 시스템 배포).

다음은 ssm 토큰 유형을 사용하는 Parameter Store 예입니다.

File MyFile
{
    DestinationPath = "C:\ProgramData\ConnectionData.txt"
    Content = "{ssm:%servicePath%/ConnectionData}"
}

토큰은 MOF 파일을 일반적이고 재사용 가능하게 만들어 중복 코드를 줄이는 데 중요한 역할을 합니다. 서버별 MOF 파일을 피할 수 있는 경우 MOF 구축 서비스가 필요 없습니다. MOF 컴파일 시 빌드 서버에 다른 모듈 버전이 설치되므로 MOF 구축 서비스를 사용하면 비용이 증가하고, 프로비저닝 시간이 늘어나고, 그룹화된 노드 간에 구성 편차 가능성이 커집니다.

사전 조건

MOF 파일을 실행하는 연결을 생성하기 전에 관리형 노드에 다음 사전 조건이 설치되어 있는지 확인합니다.

MOF 파일을 실행하는 연결 생성

MOF 파일을 실행하는 연결을 생성하려면

  1. AWS Systems Manager 콘솔(https://console.aws.amazon.com/systems-manager/)을 엽니다.

  2. 탐색 창에서 State Manager를 선택합니다.

  3. [State Manager]를 선택하고 [연결 생성(Create association)]을 선택합니다.

  4. 이름(Name) 필드에 이름을 지정합니다. 이는 선택 사항이며, 권장 사항은 아닙니다. 이 이름으로 연결 생성 시 연결의 용도를 파악할 수 있습니다. 공백은 이름에 사용할 수 없습니다.

  5. [문서(Document)] 목록에서 AWS-ApplyDSCMofs를 선택합니다.

  6. 파라미터 섹션에서 필요한 선택적 입력 파라미터를 지정합니다.

    1. Mofs To Apply(적용할 MOF): 연결 실행 시 실행할 MOF 파일을 하나 이상 지정합니다. 쉼표를 사용해 MOF 파일 목록을 구분합니다. MOF 파일을 찾기 위해 다음 옵션을 지정할 수 있습니다.

      • Amazon S3 버킷 이름입니다. 버킷 이름은 소문자여야 합니다. 다음 형식을 사용하여 이 정보를 지정합니다.

        s3:amzn-s3-demo-bucket:MOF_file_name.mof

        AWS 리전을 지정하려면 다음 형식을 사용합니다.

        s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof

      • 안전한 웹 사이트 다음 형식을 사용하여 이 정보를 지정합니다.

        https://domain_name/MOF_file_name.mof

        다음 예를 참고하세요

        https://www.example.com/TestMOF.mof

      • 로컬 공유의 파일 시스템. 다음 형식을 사용하여 이 정보를 지정합니다.

        \server_name\shared_folder_name\MOF_file_name.mof

        다음 예를 참고하세요

        \StateManagerAssociationsBox\MOFs_folder\MyMof.mof

    2. [서비스 경로(Service Path)]: (옵션) 서비스 경로는 보고서 및 상태 정보를 작성하려는 Amazon S3 버킷 접두사이거나 Parameter Store 파라미터 기반 태그의 경로입니다. 파라미터 기반 태그를 확인할 때 시스템에서는 {ssm:%servicePath%/parameter_name을 사용하여 파라미터 이름에 servicePath 값을 삽입합니다. 예를 들어, 서비스 경로가 "WebServers/Production"인 경우 시스템에서는 이 파라미터를 WebServers/Production/parameter_name으로 확인합니다. 이는 동일한 계정에서 여러 환경을 실행하는 경우 유용합니다.

    3. [보고서 버킷 이름(Report Bucket Name)]: (옵션) 규정 준수 데이터를 쓰려는 Amazon S3 버킷의 이름을 입력합니다. 보고서는 이 버킷에 JSON 형식으로 저장됩니다.

      참고

      버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예: us-west-2:MyMOFBucket. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.

    4. [Mof 작업 모드(Mof Operation Mode)]: AWS-ApplyDSCMofs 연결을 실행할 때 State Manager 동작을 선택합니다.

      • 적용: 규정을 준수하지 않는 노드 구성을 수정합니다.

      • ReportOnly: 노드 구성은 수정하지 않지만 대신 모든 규정 준수 데이터를 로깅하고 규정을 준수하지 않는 노드를 보고합니다.

    5. [상태 버킷 이름(Status Bucket Name)]: (옵션) MOF 실행 상태 정보를 쓰려는 Amazon S3 버킷의 이름을 입력합니다. 이러한 상태 보고서는 노드의 최신 규정 준수 실행의 singleton 요약입니다. 즉, 이 보고서는 다음에 연결이 MOF 파일을 실행할 때 덮어씁니다.

      참고

      버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예를 들면 us-west-2:amzn-s3-demo-bucket입니다. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.

    6. [모듈 소스 버킷 이름(Module Source Bucket Name)]: (옵션) PowerShell 모듈 파일이 포함된 Amazon S3 버킷의 이름을 입력합니다. [없음(None)]을 지정하는 경우 [PS 갤러리 모듈 소스 허용(Allow PS Gallery Module Source)] 옵션에 대해 [True]를 선택합니다.

      참고

      버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예를 들면 us-west-2:amzn-s3-demo-bucket입니다. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.

    7. [PS 갤러리 모듈 소스 허용(Allow PS Gallery Module Source)]: (옵션) https://www.powershellgallery.com/에서 PowerShell 모듈을 다운로드하려면 True를 선택합니다. [False]를 선택하는 경우 이전 옵션인 ModuleSourceBucketName에 대해 소스를 지정합니다.

    8. Proxy Uri(프록시 Uri): (선택 사항) 프록시 서버에서 MOF 파일을 다운로드하려면 이 옵션을 사용합니다.

    9. Reboot Behavior(재부팅 동작): (선택 사항) MOF 파일을 실행하려면 재부팅해야 하는 경우 다음 재부팅 동작 중 하나를 지정합니다.

      • AfterMof: 모든 MOF 실행이 완료되면 노드를 재부팅합니다. 여러 MOF 실행 요청이 재부팅되더라도 시스템에서는 모든 MOF 실행이 재부팅을 완료할 때까지 대기합니다.

      • 즉시(Immediately): MOF 실행 시 요청할 때마다 노드를 재부팅합니다. 재부팅을 요청하는 MOF 파일을 여러 개 실행하는 경우 노드가 여러 번 재부팅됩니다.

      • 안 함(Never): MOF 실행이 명시적으로 재부팅을 요청하더라도 노드가 재부팅되지 않습니다.

    10. [보고에 컴퓨터 이름 사용(Use Computer Name For Reporting)]: (옵션) 규정 준수 정보를 보고할 때 컴퓨터의 이름을 사용하려면 이 옵션을 설정합니다. 기본값은 false로, 규정 준수 정보를 보고할 때 시스템에서 노드 ID를 사용함을 의미합니다.

    11. [상세 정보 로깅 활성화(Enable Verbose Logging)]: (옵션) 처음으로 MOF 파일을 배포하는 경우 상세 정보 로깅을 설정하는 것이 좋습니다.

      중요

      허용되면 상세 정보 로깅은 표준 연결 실행 로깅보다 Amazon S3 버킷에 더 많은 데이터를 씁니다. 이로 인해 성능이 저하되고 Amazon S3에 대한 스토리지 비용이 높아질 수 있습니다. 스토리지 크기 문제를 완화하기 위해 Amazon S3 버킷에 대해 수명 주기 정책을 설정하는 것이 좋습니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요? 섹션을 참조하세요.

    12. [Enable Debug Logging(디버그 로깅 설정)]: (옵션) MOF 실패 문제를 해결하려면 디버그 로깅을 설정하는 것이 좋습니다. 또한 일반적인 사용에는 이 옵션을 비활성화하는 것이 좋습니다.

      중요

      허용되면 디버그 로깅은 표준 연결 실행 로깅보다 Amazon S3 버킷에 더 많은 데이터를 씁니다. 이로 인해 성능이 저하되고 Amazon S3에 대한 스토리지 비용이 높아질 수 있습니다. 스토리지 크기 문제를 완화하기 위해 Amazon S3 버킷에 대해 수명 주기 정책을 설정하는 것이 좋습니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요? 섹션을 참조하세요.

    13. 규정 준수 유형: (선택 사항) 규정 준수 정보를 보고할 때 사용할 규정 준수 유형을 지정합니다. 기본 규정 준수 유형은 Custom:DSC입니다. MOF 파일을 실행하는 연결을 여러 개 생성하는 경우 각 연결에 대해 규정 준수 유형을 다르게 지정해야 합니다. 그렇지 않은 경우 Custom:DSC를 사용하는 각각의 추가 연결이 기존 규정 준수 데이터를 덮어씁니다.

    14. Pre Reboot Script(재부팅 전 스크립트): (선택 사항) 구성에 재부팅이 필요하다고 표시된 경우 실행할 스크립트를 지정합니다. 이 스크립트는 재부팅 전에 실행됩니다. 이 스크립트는 한 줄이어야 합니다. 세미콜론을 사용하여 추가 행을 구분합니다.

  7. 대상 섹션에서 태그 지정 또는 수동으로 인스턴스 선택을 선택합니다. 태그를 사용하여 리소스를 대상으로 지정하기로 한 경우 태그 키와 태그 값을 제공된 필드에 입력합니다. 태그 사용에 대한 자세한 내용은 State Manager 연결에서의 대상 및 속도 제어 정보 섹션을 참조하세요.

  8. 일정 지정 섹션에서 On Schedule(일정이 있을 때) 또는 No schedule(일정이 없을 때)을 선택합니다. On Schedule(일정이 있을 때)을 선택한 경우 제공된 버튼을 사용하여 연결에 대한 cron 또는 rate 일정을 생성합니다.

  9. 고급 옵션 섹션에서:

    • 규정 준수 심각도에서 연결에 대한 심각도를 선택합니다. 규정 준수 보고는 여기서 지정한 심각도 수준과 함께 연결 상태가 준수인지 아니면 미준수인지를 나타냅니다. 자세한 내용은 State Manager 연결 규정 준수 정보 단원을 참조하십시오.

  10. 속도 제어(Rate control) 섹션에서 관리형 노드 플릿 간에 State Manager 연결을 실행하기 위한 옵션을 구성합니다. 이러한 옵션에 대한 자세한 내용은 State Manager 연결에서의 대상 및 속도 제어 정보 섹션을 참조하세요.

    동시성 섹션에서 옵션을 선택합니다.

    • 대상을 선택하여 연결을 동시에 실행할 수 있는 대상 수(절대 개수)를 입력합니다.

    • 백분율을 선택하여 연결을 동시에 실행할 수 있는 대상의 백분율을 입력합니다.

    오류 임계값 섹션에서 옵션을 선택합니다.

    • 오류를 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 절대 오류 수를 입력합니다.

    • 백분율을 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 오류 비율을 입력합니다.

  11. (선택 사항) 출력 옵션에서 명령 출력을 파일에 저장하려면 S3 버킷에 쓰기 활성화 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.

    참고

    데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 Systems Manager에 필요한 인스턴스 권한 구성이나 하이브리드 환경을 위한 IAM 서비스 역할 생성을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.

  12. 연결 생성을 선택합니다.

State Manager는 지정된 노드 또는 대상에 대해 연결을 생성하고 즉시 실행합니다. 최초 실행 후 연결은 정의한 일정에 따른 간격으로 다음 규칙에 따라 실행됩니다.

  • State Manager는 간격이 시작될 때 온라인 상태인 노드에서 연결을 실행하고 오프라인 노드를 건너뜁니다.

  • State Manager에서는 간격 중 구성된 모든 노드에 대해 연결을 실행하려고 합니다.

  • (예를 들어, 동시성 값이 한 번에 연결을 처리할 수 있는 노드 수를 제한했기 때문에) 간격 동안 연결이 실행되지 않은 경우 State Manager에서는 다음 간격 중 해당 연결을 실행하려고 합니다.

  • State Manager는 건너 뛴 모든 간격을 기록합니다. 이러한 기록은 실행 내역 탭에서 확인할 수 있습니다.

참고

AWS-ApplyDSCMofs는 Systems Manager Command 문서입니다. 즉, AWS Systems Manager의 기능인 Run Command를 사용하여 이 문서를 실행할 수도 있습니다. 자세한 내용은 AWS Systems Manager Run Command 단원을 참조하십시오.

문제 해결

이 단원에는 MOF 파일을 실행하는 연결 생성과 관련된 문제를 해결하기 위한 정보가 포함되어 있습니다.

향상된 로깅 설정

문제 해결의 첫 번째 단계로, 고급 로깅을 설정합니다. 보다 구체적으로 다음을 수행하십시오.

  1. Amazon S3 또는 Amazon CloudWatch Logs(CloudWatch)에 명령 출력을 쓰도록 연결이 구성되었는지 확인합니다.

  2. Enable Verbose Logging(상세 정보 로깅 활성화) 파라미터를 True로 설정합니다.

  3. Enable Debug Logging(디버그 로깅 활성화) 파라미터를 True로 설정합니다.

상세 정보 및 디버그 로깅이 설정되면 Stdout 출력 파일에 스크립트 실행에 대한 세부 정보가 포함됩니다. 이 출력 파일은 스크립트가 실패한 위치를 식별하는 데 유용할 수 있습니다. Stderr 출력 파일에는 스크립트 실행 중 발생한 오류가 포함됩니다.

공통 문제

이 단원에는 MOF 파일을 실행하는 연결 생성 시 발생할 수 있는 일반적인 문제에 대한 정보와 이러한 문제 해결 단계가 나와 있습니다.

내 MOF가 적용되지 않음

State Manager에서 노드에 연결을 적용하지 못하면 Stderr 출력 파일을 검토하는 것으로 시작합니다. 이 파일은 문제의 근본 원인을 파악하는 데 도움이 될 수 있습니다. 또한 다음을 확인합니다.

  • 노드에는 모든 MOF 관련 Amazon S3 버킷에 필요한 액세스 권한이 있습니다. 구체적으로 설명하면 다음과 같습니다.

    • s3:GetObject 권한: 프라이빗 Amazon S3 버킷의 MOF 파일과 Amazon S3 버킷의 사용자 정의 모듈에 필요합니다.

    • s3:PutObject 권한: Amazon S3 버킷에 규정 준수 보고서 및 규정 준수 상태를 쓰려면 필요합니다.

  • 태그를 사용하는 경우 노드에 필요한 IAM 정책이 있는지 확인합니다. 태그를 사용하려면 정책이 ec2:DescribeInstances 및 ssm:ListTagsForResource 작업을 허용하도록 하기 위해 인스턴스 IAM 역할이 필요합니다.

  • 노드에 예상한 태그가 있거나 SSM 파라미터가 할당되어 있는지 확인합니다.

  • 태그 또는 SSM 파라미터에 오탈자가 없는지 확인합니다.

  • MOF 파일 자체와 관련된 문제가 없는지 확인하기 위해 노드에서 MOF를 로컬로 적용해 보세요.

내 MOF가 실패한 것 같지만 Systems Manager 실행에는 성공함

AWS-ApplyDSCMofs 문서가 성공적으로 실행되면 Systems Manager 실행 상태에 [성공(Success)]이라고 표시됩니다. 이 상태는 MOF 파일의 구성 요구 사항을 기준으로 한 노드의 규정 준수 상태를 반영하지 않습니다. 노드의 규정 준수 상태를 확인하려면 규정 준수 보고서를 확인합니다. JSON 보고서는 Amazon S3 보고서 버킷에서 볼 수 있습니다. 이 내용은 Run Command 및 State Manager 실행에 적용됩니다. 또한 State Manager의 경우 Systems Manager Compliance 페이지에서 규정 준수 세부 정보를 확인할 수 있습니다.

Stderr 상태: 서비스 연결 시도 시 이름 확인 실패

이 오류는 스크립트가 원격 서비스에 연결할 수 없음을 나타냅니다. 이 스크립트는 Amazon S3에 연결하지 못할 가능성이 매우 큽니다. 대부분 이 문제는 스크립트가 문서 파라미터에 제공된 Amazon S3 버킷에 규정 준수 보고서 또는 규정 준수 상태를 쓰려고 할 때 발생합니다. 일반적으로 이 오류는 컴퓨팅 환경이 방화벽 또는 허용 목록을 포함한 투명한 프록시를 사용하는 경우 발생합니다. 이 문제를 해결하려면:

  • 모든 Amazon S3 버킷 파라미터에 대해 리전별 버킷 구문을 사용합니다. 예를 들어, Mofs to Apply(적용할 Mof) 파라미터의 형식은 다음과 같아야 합니다.

    s3:bucket-region:bucket-name:mof-file-name.mof.

    예: s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof

    보고서, 상태 및 모듈 소스 버킷 이름의 형식은 다음과 같아야 합니다.

    bucket-region:bucket-name. 단순 예시: us-west-1:amzn-s3-demo-bucket;

  • 리전별 구문으로 문제가 해결되지 않으면 대상 노드가 원하는 리전에서 Amazon S3에 액세스할 수 있는지 확인합니다. 이를 확인하려면 다음을 수행합니다.

    1. 적절한 Amazon S3 리전에서 Amazon S3의 엔드포인트 이름을 찾습니다. 자세한 내용은 Amazon Web Services 일반 참조의 Amazon S3 서비스 엔드포인트를 참조하세요.

    2. 대상 노드에 로그온해 다음 ping 명령을 실행합니다.

      ping s3.s3-region.amazonaws.com

      ping에 실패하면 이는 Amazon S3이 다운되었거나, 방화벽/투명한 프록시가 Amazon S3 리전에 대한 액세스를 차단했거나, 노드가 인터넷에 액세스할 수 없는 것입니다.

DSC 리소스 규정 준수 세부 정보 보기

Systems Manager는 AWS-ApplyDSCMofs 문서를 실행했을 때 지정한 Amazon S3 [상태 버킷(Status Bucket)]에서 DSC 리소스 실패에 대한 규정 준수 정보를 수집합니다. Amazon S3 버킷에서 DSC 리소스 실패에 대한 정보를 검색하는 데는 시간이 많이 걸릴 수 있습니다. 대신, Systems Manager [Compliance] 페이지에서 이 정보를 볼 수 있습니다.

규정 준수 리소스 요약 섹션에 실패한 리소스의 수가 표시됩니다. 다음 예에서 ComplianceType은 Custom:DSC이고 한 개의 리소스가 규정 미준수입니다.

참고

Custom:DSC는 AWS-ApplyDSCMofs 문서에서 기본 [ComplianceType] 값입니다. 이 값은 사용자 지정 가능합니다.

[Compliance] 페이지의 [Compliance 리소스 요약(Compliance resources summary)] 섹션에서 개수 보기.

[리소스에 대한 세부 정보 개요(Details overview for resources)] 섹션에는 규정 미준수 DSC 리소스가 있는 AWS 리소스에 대한 정보가 표시됩니다. 이 섹션에는 또한 MOF 이름, 스크립트 실행 단계, 및 세부 상태 정보를 볼 수 있는 출력 보기 링크(적용되는 경우)도 포함됩니다.

MOF 실행 리소스 실패에 대한 규정 준수 세부 정보 보기

[출력 보기(View output)] 링크는 세부 상태의 마지막 4,000자를 표시합니다. Systems Manager는 첫 번째 요소로 예외를 시작한 다음 자세한 메시지를 다시 검사하고 4,000자 할당량에 도달할 때까지 가능한 한 많이 추가합니다. 이 프로세스는 예외가 발생되기 전에 출력된 긴 메시지(문제 해결을 위해 가장 관련성이 높은 메시지)를 표시합니다.

MOF 리소스 규정 준수 문제에 대한 자세한 출력 보기

규정 준수 정보를 보는 방법에 대한 자세한 내용은 AWS Systems Manager Compliance 섹션을 참조하세요.

규정 준수 보고에 영향을 미치는 상황

State Manager 연결이 실패한 경우에는 규정 준수 데이터가 보고되지 않습니다. 보다 구체적으로, MOF가 처리되지 못한다면 연결이 실패하기 때문에 Systems Manager가 어떤 규정 준수 항목도 보고하지 않습니다. 예를 들어, Systems Manager가 노드에 액세스할 권한이 없는 Amazon S3 버킷에서 MOF를 다운로드하려고 시도하면 연결이 실패하고 어떠한 규정 준수 데이터도 보고되지 않습니다.

두 번째 MOF의 리소스가 실패하면 Systems Manager가 규정 준수 데이터를 보고합니다. 예를 들어 MOF가 존재하지 않는 드라이브에서 파일을 생성하려고 하면 AWS-ApplyDSCMofs 문서가 완전히 처리될 수 있기 때문에(즉, 연결이 성공적으로 실행될 수 있기 때문에) Systems Manager가 규정 준수를 보고합니다.