기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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

프로비저닝 워크플로에 대한 지원

Service Catalog Puppet은 Python Luigi 작업 오케스트레이션 엔진을 사용하여 부트스트래핑 및 프로비저닝 워크플로를 구현합니다. 이러한 워크플로의 모든 단계는 Luigi 워크플로 태스크로 구현됩니다. Luigi에 대한 개요 및 이를 다른 인기 워크플로 도구와 비교하는 방법은 Data Revenue 블로그의 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 워크플로로 자체 프로비저닝을 수행합니다.

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

허브 모드

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

스포크 모드

스포크 모드에서 Service Catalog 허브 계정은 지정된 부트스트래핑된 스포크 계정에서 실행할 Luigi 워크플로를 시작합니다. 스포크 워크플로가 완료되면 허브 계정에 알립니다. 스포크 계정에서 발생한 장애는 허브 계정으로 확대됩니다. 허브 계정은 스포크 계정을 폴링하여 완료 여부를 확인하고 상태를 판단합니다.

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

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

비동기 모드

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

캐싱

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

DevSecOps 수명 주기 지원

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

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

Service Catalog Puppet을 사용하면 여러 팀이 Service Catalog 제품 솔루션의 프로비저닝을 동시에 개발하고 테스트할 수 있습니다. 여러 개발자가 동시에 제품을 변경하지 않는 것이 모범 사례입니다. 대신 별도로 동시에 수정할 수 있도록 제품을 더 세분화된 구성 요소로 나눌 수 있습니다.

Service Catalog Puppet은 정적 및 유닛 테스트 기능을 제공하는 어설션 문을 통해 테스트를 자동화하는 데도 도움이 됩니다. 정책 시뮬레이터를 사용하여 서비스 제어 정책(SCP) 및 IAM 정책을 테스트할 수 있습니다. 기술적으로 포괄적인 테스트이지만 시스템 통합 테스트(SIT) 환경에서 사용할 수 있습니다. 자세한 내용은 Service Catalog Puppet 설명서의 Using policy simulations 및 Applying service control policies를 참조하세요.

성숙도, 완전성 및 지원

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