CI/CD 파이프라인에서 DSC의 역할 이해

이 문서에서는 구성 및 리소스를 결합 하는 데 사용할 수 있는 방법의 유형을 설명합니다. 각 시나리오의 목표는 서버 배포 최종 상태에 연결하기 위해 여러 구성을 사용하는 경우 복잡성을 줄이기 위한 것으로 동일합니다. 이에 대한 예제로는 애플리케이션 상태를 유지하는 애플리케이션 소유자 및 보안 기준의 변경을 해제하는 중앙 팀과 같이 서버 배포의 결과에 기여하는 여러 팀이 있습니다. 장점 및 위험을 포함하여 각 접근 방식의 미묘한 차이는 여기에 자세히 설명돼 있습니다.

공동 작업 제작 기술의 유형

이 개념을 사용하기 위해 로컬 Configuration Manager에게 기본 제공된 두 가지 솔루션이 있습니다.

개념	자세한 정보
부분 구성	설명서
복합 리소스	설명서

각 접근 방식의 영향에 대한 이해

서버 배포의 결과를 관리하려면 이러한 솔루션 중 하나를 사용할 수 있습니다. 그러나 각 방법을 사용하는 영향에는 큰 차이가 있습니다.

부분 구성

부분 구성을 사용하는 경우 로컬 Configuration Manager는 여러 구성을 독립적으로 관리하도록 구성됩니다. 구성은 개별적으로 컴파일된 다음, 노드에 할당됩니다. 이렇게 하려면 LCM이 미리 각 구성의 이름으로 구성되어야 합니다.

부분 구성은 종종 커뮤니케이션 또는 협업의 이점 없이 둘 이상의 팀에 서버의 구성에 대한 완벽한 제어를 제공합니다.

고객은 부분 구성이 리소스 충돌, 의도하지 않은 재정의 및 궁극적으로 자산의 참된 구성 제어 손실을 초래할 수 있다는 피드백을 제공했습니다.

또한 이 모델을 사용할 경우 각 제어 팀의 구성 변경이 릴리스 파이프라인을 통해 완벽하게 테스트되지 않아 프로덕션 환경에서 예기치 않은 결과를 초래할 수 있다는 피드백도 제공했습니다.

서버에 릴리스된 모든 변경 내용은 단일 파이프라인을 사용해 평가하는 것이 중요합니다.

아래 그림에서 B 팀은 A 팀에 해당 부분 구성을 릴리스한 다음, A 팀은 두 구성이 모두 적용된 서버에 대해 해당 테스트를 실행합니다. 이 모델에서 하나의 기관에만 프로덕션 환경에서 변경할 권한이 있습니다.

B 팀에서 변경이 필요할 경우 A 팀의 원본 제어 환경에 대해 끌어오기 요청을 제출해야 합니다. 그런 다음, A 팀은 변경이 서버에서 호스팅된 서비스 또는 애플리케이션에서 오류를 일으키지 않을 것이라는 확신이 있는 경우 프로덕션 환경에 대한 릴리스 및 테스트 자동화를 사용하여 변경 내용을 검토합니다.

복합 리소스

복합 리소스는 단순히 리소스로 패키지된 DSC 구성입니다. 복합 리소스를 허용하기 위해 LCM 구성에 대한 특별한 요구 사항은 없습니다. 이 리소스는 하나의 MOF 파일의 새 구성 및 단일 컴파일 결과 내에서 사용됩니다.

복한 리소스에 대한 일반적인 시나리오는 두 개가 있습니다. 첫 번째 시나리오는 복잡성 및 고유한 추상 개념을 줄이는 것입니다. 두 번째는 모든 테스트를 통과한 후 애플리케이션 팀이 해당 릴리스 파이프라인을 통해 프로덕션 환경에 안전하게 배포하도록 패키지된 기준을 허용하는 것입니다.

Configuration Name
{
  File 1
  {
    Ensure = "Present"
    Path = "c:\inetpub\file1.zip"
    Source = "http://uri/file1.zip"
  }
  Service A
  {
    Ensure = "Present"
    Name = "ServiceA"
    Status = "Running"
  }
  SecurityBaseline Settings
  {
    Ensure = "Present"
    Datacenter = "NorthAmerica"
  }
}

복합 리소스는 작업 완성도를 빌드하면서 파이프라인을 사용하여 컴퍼지션 및 협업 둘 다의 수준을 올립니다.

인식하지 않으면서 이미 복합 리소스를 사용할 수 있습니다. 예제는 ServiceSet입니다. 이 리소스는 개별적으로 나열하지 않고 여러 Windows 서비스의 상태를 관리합니다. Name 속성은 각 서비스의 이름을 제공하려면 문자열 배열을 허용합니다. 구성을 컴파일하면 MOF에는 ServiceSet에 전달된 각 Name에 대한 고유한 서비스 섹션이 포함됩니다.

조직에는 모든 서버에 설치해야 하는 "에이전트" 또는 "미들웨어"가 있을 수 있습니다. 복합 리소스는 종속성, 설정 및 이러한 모든 도구 및 유틸리티의 구성을 관리하기 위한 최상의 해결책입니다.

여러 서버에 걸쳐 있는 솔루션의 담당자 또는 담당팀은 해당 요구 사항을 포함하는 구성을 작성합니다. 다음으로, 복합 리소스 설명서에 제공된 지침을 사용하여 구성을 복합 리소스로 패키지합니다. 마지막으로, 애플리케이션 팀이 해당 구성에서 새 복합 리소스를 사용할 수 있는 파일 공유 또는 NuGet 피드와 같은 위치에 해당 복합 리소스를 게시해야 합니다.

팀이 새 버전을 릴리스할 때마다 해당 복합 리소스에 대한 모듈 매니페스트의 버전 번호가 증가하게 됩니다. 애플리케이션 팀은 애플리케이션 종속성을 관리하기 위해 작성하는 구성에 복합 리소스를 포함시킵니다. 운영/보안 팀이 해당 리소스의 새 버전을 릴리스하는 경우 새 변경 내용에 대해 애플리케이션 팀에 알려야 합니다.

애플리케이션 팀은 유일한 변경 내용이 기준이 되는 프로덕션 환경에 대해 릴리스를 트리거할 수 있습니다. 그러나 이렇게 하면 서비스 중단 위험 전에 애플리케이션에 대한 영향을 평가할 기회가 제공됩니다.

참고

참고 - 복합 리소스 사용에 대한 피드백에는 변경하려면 새 MOF의 컴파일 및 릴리스가 필요하다는 비판이 포함되어 있습니다. 이것은 의도적인 것입니다. 각 새 구성 릴리스는 각 리소스의 특정 버전에 대한 정적 참조를 포함해야 하며, 프로덕션 서버 노드에 연결되기 전에 테스트를 통해 유효성이 검사되어야 합니다. 소스 제어에서 변경 내용을 테스트하고 릴리스하는 프로세스를 통해 소규모지만 잦은 일괄 처리로 변경을 릴리스하기 위한 안전한 환경이 만들어집니다.