서비스 카탈로그 Puppet

Service Catalog Puppet은 AWS Boto3 API를 사용하여 Python에서 구현됩니다. 이 도구는 Service Catalog 제품을 구성하고 프로비저닝하기 위한 몇 가지 강력한 기능을 제공합니다. 개발자는 매니페스트 역할을 하는 YAML 템플릿을 사용하여 Service Catalog 제품 및 포트폴리오 프로비저닝 정보를 구성할 수 있습니다. Service Catalog Puppet 프로비저닝 워크플로는 Service Catalog보다 더 복잡한 배포 프로세스가 필요한 제품을 지원합니다. 또한 성능 최적화를 지원하여 적극적인 기간 내에 대규모로 제품을 프로비저닝합니다.

Service Catalog Puppet은 배포 시 제품 프로비저닝을 위해 Service Catalog CloudFormation 템플릿에 액세스합니다. CloudFormation을 직접 호출하여 제품의 프로비저닝 템플릿 스택을 배포하고 Service Catalog의 자체 스택 세트 프로비저닝 프로세스에서 부과하는 제한을 우회합니다. 프로비저닝 템플릿이 매크로를 사용하여 다른 CloudFormation 스크립트를 포함하거나 중첩된 CloudFormation 스크립트를 사용하는 경우 프로비저닝 워크플로의 부트스트래핑 부분에 있는 대상 계정의 해당 스크립트에 대한 액세스를 제공해야 합니다.

자세한 내용:

• Service Catalog Puppet 설명서 및 GitHub 리포지토리를 참조하세요.

• Service Catalog Puppet SDK를 사용하여 프로그래밍 방식으로 도구와 상호 작용하여 제품 및 포트폴리오 프로비저닝을 시작하려면 SDK 설명서를 참조하세요.

• GitOps는 Service Catalog Puppet 환경을 관리하기 위한 기본 메커니즘입니다.

Service Catalog Puppet은 개발자가 매우 쉽게 배울 수 있습니다. 제품 프로비저닝 템플릿을 구현하려면 CloudFormation에 익숙하고 매니페스트를 구현하려면 YAML 템플릿에 익숙해야 합니다. 자기 주도형 워크숍과 같이 새로운 개발자를 속도를 높이는 데 사용할 수 있는 좋은 워크숍이 있습니다.

프로비저닝 워크플로 지원

Service Catalog Puppet은 Python Luigi 작업 오케스트레이션 엔진을 사용하여 부트스트래핑 및 프로비저닝 워크플로를 구현합니다. 이러한 워크플로의 모든 단계는 Luigi 워크플로 작업으로 구현됩니다. Luigi에 대한 개요 및 다른 인기 워크플로 도구와 비교하는 방법은 데이터 수익 블로그의 Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlow를 참조하세요.

Luigi를 사용하면 Service Catalog Puppet이 워크플로 작업과 관련된 작업자 수를 제어하고 워크플로의 다른 측면을 제어하여 규모 조정 및 성능을 개선할 수 있습니다. Service Catalog Puppet은 제품 및 단계 종속성을 관리하고 제품 프로비저닝을 오케스트레이션하기 위한 depends_on 메커니즘도 제공합니다. 이 기능을 사용하면 세분화된 제품 정의와 복잡한 종속성을 구현하고 운영적으로 관리할 수 있습니다.

프로비저닝 모드

Service Catalog Puppet은 허브, 스포크 및 비동기라는 세 가지 실행 모드를 지원합니다. 세 가지 모드 모두 Service Catalog에 이미 정의된 포트폴리오 내에 제품을 프로비저닝합니다. 이들은 대상 계정에 대한 Service Catalog 제품 공유에 의존하고 Service Catalog 관리자 및 시작 역할을 사용하여 해당 대상에서 프로비저닝을 실현합니다. Service Catalog Puppet은 YAML 구성 파일에 제공된 역할 구성을 기반으로 동일한 조직 내에서 부트스트래핑 단계를 수행합니다. 또한이 도구는 단일 허브 계정에서 여러 조직에 대한 프로비저닝을 지원합니다. 이 시나리오에서는 Service Catalog Puppet이 외부 조직의 계정에서 필요한 프로비저닝 작업을 수행할 수 있도록 외부 조직에서 부트스트래핑을 수동으로 수행해야 합니다.

모든 프로비저닝 모드에서 Service Catalog Puppet은 Service Catalog의 프로비저닝 프로세스를 호출하지 않고 제품 프로비저닝을 직접 구현합니다. 기존 Service Catalog 스택 세트 제약 조건의 역할 및 대상 계정 사양을 사용하도록 프로비저닝 매니페스트를 구성할 수 있습니다. Service Catalog Puppet은이 정보를 사용하여 Luigi 워크플로로 자체 프로비저닝을 수행합니다.

OUs 또는 계정을 직접 지정하는 것 외에도 계정 태그 지정 접근 방식을 기반으로 제품 포트폴리오 프로비저닝 대상을 정의할 수 있습니다. 계정 태그 기반 프로비저닝에서는 포트폴리오 제품이 지정된 매니페스트 프로비저닝 태그 세트의 모든 태그가 있는 모든 계정에 프로비저닝됩니다. 예를 들어 미국 동부 리전의 모든 기관 프로덕션 계정에 포트폴리오 제품을 발급하려면 태그 , partition:us-east및 type:prod를 지정할 수 있습니다scope:institutional-client. 또한 계정 및 OU 제외를 선언하여 지정한 태그가 있는 OUs 또는 계정 또는 OU 지정 대상의 멤버인 계정에 대한 프로비저닝을 금지할 수 있습니다. 계정 태그 지정에 대한 자세한 내용은 Service Catalog Tools 설명서를 참조하세요.

허브 모드

허브 프로비저닝 모드에서 스포크 계정에 대한 모든 Luigi 워크플로는 지정된 중앙 허브 계정에서 관리됩니다. 허브 계정은 스포크 계정에서 작업을 수행할 수 있도록 허용하는 IAM 역할을 수임하지만 작업 관리는 허브 계정 내에서 이루어집니다. 허브 계정은 모든 스포크 계정 프로비저닝 작업이 성공적으로 또는 성공적으로 완료될 때까지 동기식으로 대기합니다. 그런 다음 최종 상태를 보고합니다. 허브 계정 모드는 가장 오래되고 가장 성숙한 프로비저닝 모드입니다. 그러나 많은 사용자가 더 큰 프로비저닝 동시성과 속도를 달성하기 위해 스포크 프로비저닝 모드로 전환했습니다.

스포크 모드

스포크 모드에서 Service Catalog 허브 계정은 지정된 부트스트랩된 스포크 계정에서 실행하기 위해 Luigi 워크플로를 시작합니다. 스포크 워크플로가 완료되면 허브 계정에 알림이 전송됩니다. 스포크 계정의 장애가 허브 계정으로 증가합니다. 허브 계정은 스포크 계정을 폴링하여 완료 여부를 확인하고 상태를 결정합니다.

거의 모든 것이 별도의 AWS 서비스 스포크 계정에서 실행되므로 스포크 모드는 할당량 증가가 필요할 가능성이 가장 낮습니다. 또한 스포크 모드는 중앙 제어를 유지하면서 허브 모드보다 훨씬 더 큰 동시성을 제공합니다. 허브 모드보다 프로비저닝 속도를 800% 높일 수 있습니다. 스포크 모드는 제품 간 DependsOn 관계를 통한 제품 체인화를 지원하므로에 종속된 제품이 이미 프로비저닝되어 있습니다. 체인 제품으로 구성된 제품은 구성 요소 체인 제품을 프로비저닝할 수도 있습니다. 특수 AWS Lambda 함수 호출을 사용하여 필요한 단계를 수행할 수도 있습니다. 한 스포크의 결함은 다른 스포크와 격리됩니다.

스포크 모드는 최대 7개 리전에 980개 이상의 계정이 있는 기업에서 사용됩니다. 이러한 기업은 일반적으로 1시간 이내에 인프라의 모든 리전 및 계정에 제품을 프로비저닝할 수 있습니다.

참고

이러한 결과는 네트워킹 인프라, 워크로드, AWS 조직 허브 및 스포크 계정에 적용되는 할당량과 같은 요인에 따라 달라질 수 있습니다. 또한 프로비저닝되는 제품 리소스, 고유한 생성 시간 및 다른 리소스에 대한 종속성에 따라 달라집니다.

Aysnc 모드

비동기 모드는 스포크 계정에서 프로비저닝 워크플로를 시작하지만 스포크에서 완료 응답을 기다리거나 받지 않습니다.

캐싱

Service Catalog Puppet이 워크플로 속도를 최적화하는 데 사용하는 또 다른 메커니즘은 워크플로의 단계를 나타내는 일반적인 작업을 캐싱하는 것입니다. 캐시된 작업이 완료되면 Amazon Simple Storage Service(Amazon S3)에 출력을 기록합니다. 다음에 동일한 파라미터로 동일한 세션에서 작업이 호출될 때 Service Catalog Puppet은 작업을 다시 실행하는 대신 캐시된 값을 사용합니다. 자세한 내용은 Service Catalog Puppet 설명서의 캐싱을 참조하세요.

DevSecOps 수명 주기 지원

Service Catalog Puppet에는 DevSecOps 파이프라인 관리에 대한 지원이 포함되어 있습니다. Service Catalog Tools 작업(Service Catalog Puppet 개요에 설명된 대로)을 사용하여 테스트를 자동화하고 권장 canary 계정을 포함하여 AWS 수명 주기 계정 전체에서 제품을 홍보할 수 있습니다. 자세한 내용은 Service Catalog Puppet 설명서의 환경 관리를 참조하세요.

광범위한 프로덕션 사용 전에 제품 변경과 관련된 문제를 감지하려면 Service Catalog Puppet에 초기 배포를 위한 canary 계정이 하나 이상 필요합니다. 새 릴리스를 테스트하고 확신을 얻은 후 비canary 프로덕션 계정으로 승격할 수 있습니다. 문제가 식별되면 릴리스를 롤백하고 문제가 해결되면 다시 소개할 수 있습니다. 이 접근 방식을 사용하면 프로덕션 계정에 문제가 있는 canary 버전을 릴리스하면 프로덕션 문제가 발생할 수 있습니다. 대안으로, 변경 사항을 프로덕션으로 릴리스하기 전에 각 제품 변경에 대해 전체 회귀 테스트를 실행할 수 있습니다. 이로 인해 CI/CD 프로세스에 추가 오버헤드가 발생하지만 프로덕션 문제를 방지하는 데 도움이 됩니다. 개발 팀에 가장 적합한 기능 릴리스 시나리오와 접근 방식을 결정하는 것은 DevSecOps 관리자의 책임입니다.

Service Catalog Puppet을 사용하면 여러 팀이 Service Catalog 제품 솔루션의 프로비저닝을 동시에 개발하고 테스트할 수 있습니다. 여러 개발자가 동시에 제품을 변경해서는 안 되는 것이 가장 좋습니다. 대신 제품을 더 세분화된 구성 요소로 분할하여 별도의 동시 수정을 수행할 수 있습니다.

Service Catalog Puppet은 정적 및 단위 테스트 기능을 제공하는 어설션 문을 통해 테스트를 자동화하는 데도 도움이 됩니다. 정책 시뮬레이터를 사용하여 서비스 제어 정책(SCPs) 및 IAM 정책을 테스트할 수 있습니다. 이는 기술적으로 end-to-end 테스트이지만 시스템 통합 테스트(SIT) 환경에서 사용할 수 있습니다. 자세한 내용은 Service Catalog Puppet 설명서의 정책 시뮬레이션 사용 및 서비스 제어 정책 적용을 참조하세요.

성숙도, 완전성 및 지원

Service Catalog Puppet은 공식적으로 지원되지 않지만 널리 채택 AWS 서비스되었습니다. 이 도구는 지난 몇 년 동안 대규모 조직에서 원하는 프로비저닝 기간 내에 수백 개의 OU 계정에 제품을 성공적으로 중앙에서 프로비저닝하는 데 사용되었습니다. 대규모로 내결함성 제품 프로비저닝을 제공하는 것으로 증명되었습니다. Service Catalog Puppet에 문제가 발생하는 사용자는이 AWS Labs 솔루션의 기여자가 해결할 수 있도록 GitHub 리포지토리에 기록할 수 있습니다.