컴퍼지션 및 공동 작업에 대한 고급 DSC 작성Advanced DSC Authoring for Composition and Collaboration

이 문서에서는 구성 및 리소스를 결합 하는 데 사용할 수 있는 방법의 유형을 설명합니다.This article describes the types of approaches available for combining configurations and resources. 각 시나리오의 목표는 서버 배포 최종 상태에 연결하기 위해 여러 구성을 사용하는 경우 복잡성을 줄이기 위한 것으로 동일합니다.The goal for each scenario is the same, to reduce complexity when multiple configurations are preferred to reach a server deployment end state. 이에 대한 예제로는 응용 프로그램 상태를 유지하는 응용 프로그램 소유자 및 보안 기준의 변경을 해제하는 중앙 팀과 같이 서버 배포의 결과에 기여하는 여러 팀이 있습니다.An example of this would be multiple teams contributing to the outcome of a server deployment, such as an application owner maintaining the application state and a central team releasing changes to security baselines. 장점 및 위험을 포함하여 각 접근 방식의 미묘한 차이는 여기에 자세히 설명돼 있습니다.The nuances of each approach including the benefits and risks are detailed here.

파이프라인

공동 작업 제작 기술의 유형Types of Collaborative Authoring Techniques

이 개념을 사용하기 위해 로컬 Configuration Manager에게 기본 제공된 두 가지 솔루션이 있습니다.There are two solutions built in to Local Configuration Manager to enable this concept:

개념Concept 자세한 정보Detailed Information
부분 구성Partial Configurations 설명서Documentation
복합 리소스Composite Resources 설명서Documentation

각 접근 방식의 영향에 대한 이해Understanding The Impact of Each Approach

서버 배포의 결과를 관리하려면 이러한 솔루션 중 하나를 사용할 수 있습니다.Either of these solutions can be used to manage the outcome of a server deployment. 그러나 각 방법을 사용하는 영향에는 큰 차이가 있습니다.However, there is significant difference in the impact of using each approach.

부분 구성Partial Configurations

부분 구성을 사용하는 경우 로컬 Configuration Manager는 여러 구성을 독립적으로 관리하도록 구성됩니다.When using Partial Configurations, Local Configuration Manager is configured to manage multiple configurations independently. 구성은 개별적으로 컴파일된 다음, 노드에 할당됩니다.Configurations are compiled independently and then assigned to the node. 이렇게 하려면 LCM이 미리 각 구성의 이름으로 구성되어야 합니다.This requires LCM to be configured in advance with the name of each configuration.

PartialConfiguration

부분 구성은 종종 커뮤니케이션 또는 공동 작업의 이점 없이 둘 이상의 팀에 서버의 구성에 대한 완벽한 제어를 제공합니다.Partial Configurations provide two, or more, teams complete control over configuration of a server, often without the benefit of communication or collaboration.

고객은 부분 구성이 리소스 충돌, 의도하지 않은 재정의 및 궁극적으로 자산의 참된 구성 제어 손실을 초래할 수 있다는 피드백을 제공했습니다.Customers have provided feedback that this can lead to resource conflicts, unintentional overrides, and ultimately loss of true configuration control of the asset.

또한 이 모델을 사용할 경우 각 제어 팀의 구성 변경이 릴리스 파이프라인을 통해 완벽하게 테스트되지 않아 프로덕션 환경에서 예기치 않은 결과를 초래할 수 있다는 피드백도 제공했습니다.Additionally, customers have provided feedback that when using this model, each controlling teams configuration changes are unlikely to be fully tested through a release pipeline, leading to unexpected results in production.

서버에 릴리스된 모든 변경 내용을 평가하는 데 단일 파이프라인을 사용하는 것이 중요합니다.It is critical that a single pipeline be used to evaluate all changes release to servers.

아래 그림에서 B 팀은 A 팀에 해당 부분 구성을 릴리스한 다음, A 팀은 두 구성이 모두 적용된 서버에 대해 해당 테스트를 실행합니다.In the illustration below, Team B releases their partial configuration to Team A. Team A then runs their tests against a server with both configurations applied. 이 모델에서 하나의 기관에만 프로덕션 환경에서 변경할 권한이 있습니다.In this model, only one authority has permission to make changes in production.

PartialSinglePipeline

B 팀에서 변경이 필요할 경우 A 팀의 원본 제어 환경에 대해 끌어오기 요청을 제출해야 합니다.When changes are required from Team B, they should submit a Pull Request against Team A's source control environment. 그런 다음, A 팀은 변경이 서버에서 호스팅된 서비스 또는 응용 프로그램에서 오류를 일으키지 않을 것이라는 확신이 있는 경우 프로덕션 환경에 대한 릴리스 및 테스트 자동화를 사용하여 변경 내용을 검토합니다.Team A would then review the changes using test automation and release to production when there is confidence that the changes will not cause errors in the applications or services hosted by the server.

복합 리소스Composite Resources

복합 리소스는 단순히 리소스로 패키지된 DSC 구성입니다.A composite resource is simply a DSC Configuration packaged as a resource. 복합 리소스를 허용하기 위해 LCM 구성에 대한 특별한 요구 사항은 없습니다.There are no special requirements for configuring LCM to accept composite resources. 이 리소스는 하나의 MOF 파일의 새 구성 및 단일 컴파일 결과 내에서 사용됩니다.The resources are used within a new configuration and a single compilation results in one MOF file.

CompositeResource

복한 리소스에 대한 일반적인 시나리오는 두 개가 있습니다.There are two common scenarios for composite resources. 첫 번째 시나리오는 복잡성 및 고유한 추상 개념을 줄이는 것입니다.The first is to reduce complexity and abstract unique concepts. 두 번째는 모든 테스트를 통과한 후 응용 프로그램 팀이 해당 릴리스 파이프라인을 통해 프로덕션 환경에 안전하게 배포하도록 패키지된 기준을 허용하는 것입니다.The second is to allow baselines to be packaged for an application team to safely deploy through their release pipeline to production after all tests have passed.

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

복합 리소스는 작업 완성도를 빌드하면서 파이프라인을 사용하여 컴퍼지션 및 공동 작업 둘 다의 수준을 올립니다.Composite resources promote both composition and collaboration using a pipeline while building operational maturity

인식하지 않으면서 이미 복합 리소스를 사용할 수 있습니다.You might be already using composite resources without realizing it. 예제는 ServiceSet입니다.An example is ServiceSet. 이 리소스는 개별적으로 나열하지 않고 여러 Windows 서비스의 상태를 관리합니다.This resource manages the state of multiple Windows Services without listing them individually. Name 속성은 각 서비스의 이름을 제공하려면 문자열 배열을 허용합니다.The Name property accepts an array of strings to provide the name of each service. 구성을 컴파일하면 MOF에는 ServiceSet에 전달된 각 Name에 대한 고유한 서비스 섹션이 포함됩니다.When the configuration is compiled, the MOF will contain a unique Service section for each of the Names passed to ServiceSet.

조직에는 모든 서버에 설치해야 하는 "에이전트" 또는 "미들웨어"가 있을 수 있습니다.Organizations might have "agents" or "middleware" that should be installed on every server. 복합 리소스는 종속성, 설정 및 이러한 모든 도구 및 유틸리티의 구성을 관리하기 위한 최상의 해결책입니다.A composite resource is the best answer to managing the dependencies, setup, and configuration of any such tools and utilities.

여러 서버에 걸쳐 있는 솔루션의 담당자 또는 담당팀은 해당 요구 사항을 포함하는 구성을 작성합니다.The person or team responsible for solutions that span multiple servers authors a configuration containing their requirements. 다음으로, 복합 리소스 설명서에 제공된 지침을 사용하여 구성을 복합 리소스로 패키지합니다.Next, the configuration would be packaged as a composite resource using instructions provided in the composite resource documentation. 마지막으로, 응용 프로그램 팀이 해당 구성에서 새 복합 리소스를 사용할 수 있는 파일 공유 또는 NuGet 피드와 같은 위치에 해당 복합 리소스를 게시해야 합니다.Finally, the new composite resource should be published to a location such as a file share or NuGet feed where application teams can consume it in their configurations.

팀이 새 버전을 릴리스할 때마다 해당 복합 리소스에 대한 모듈 매니페스트의 버전 번호가 증가하게 됩니다.Each time the team releases a new version, they would increment the version number in the module manifest for their composite resource. 응용 프로그램 팀은 응용 프로그램 종속성을 관리하기 위해 작성하는 구성에 복합 리소스를 포함시킵니다.The application teams include the composite resource in the configuration they author for managing application dependencies. 운영/보안 팀이 해당 리소스의 새 버전을 릴리스하는 경우 새 변경 내용에 대해 응용 프로그램 팀에 알려야 합니다.When the Operations/Security teams release a new version of their resource, they notify the application teams of a new change.

응용 프로그램 팀은 유일한 변경 내용이 기준이 되는 프로덕션 환경에 대해 릴리스를 트리거할 수 있습니다.The application teams might trigger a release to production where the only change is to baselines. 그러나 이렇게 하면 서비스 중단 위험 전에 응용 프로그램에 대한 영향을 평가할 기회가 제공됩니다.However, this provides an opportunity to evaluate impact to applications before risk of a service outage.

참고 - 복합 리소스 사용에 대한 피드백에는 변경하려면 새 MOF의 컴파일 및 릴리스가 필요하다는 비판이 포함되어 있습니다.Note - Feedback regarding the use of composite resources has included criticism that making changes requires compiling and releasing a new MOF. 이것은 의도적입니다.This is by design. 각 새 구성 릴리스는 각 리소스의 특정 버전에 대한 정적 참조를 포함해야 하며, 프로덕션 서버 노드에 연결되기 전에 테스트를 통해 유효성이 검사되어야 합니다.Each new configuration release should include a static reference to a specific version of each resource, and should be validated by tests before reaching production server nodes. 소스 제어에서 변경 내용을 테스트하고 릴리스하는 프로세스를 통해 소규모지만 잦은 일괄 처리로 변경을 릴리스하기 위한 안전한 환경이 만들어집니다.The process of testing and releasing changes from source control creates a safe environment for releasing change in small but frequent batches.

핵심 인프라를 관리하기 위해 릴리스 파이프라인을 사용하는 방법에 대한 자세한 내용은 릴리스 파이프라인 모델 백서를 참조하세요.For more information about using release pipelines to manage core infrastructure, see the whitepaper: The Release Pipeline Model.