기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Service Catalog
Service Catalog 퍼펫은AWS Boto3 API를 사용하여 파이썬으로 구현됩니다. 이 도구는 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은 개발자가 쉽게 배울 수 있습니다. 매니페스트를 구현하려면 제품 프로비저닝 템플릿과 YAML 템플릿을 구현하는 데 익숙해야 합니다. CloudFormation 자기 주도형 워크숍과 같이 신입 개발자를 빠르게 익힐 수 있는 좋은 워크숍이
프로비저닝 워크플로 Support
Service Catalog Puppet은 Python Luigi 작업 오케스트레이션 엔진을 사용하여 부트스트래핑 및 프로비저닝 워크플로를 구현합니다. 이러한 워크플로의 모든 단계는 Luigi 워크플로우 작업으로 구현됩니다. Luigi에 대한 개요와 다른 인기 있는 워크플로 도구와의 비교는 데이터 수익 블로그에서 Airflow 대 Luigi 대 Argo 대 KubeFlow MLFlow
Luigi를 사용하면 Service Catalog Puppet이 워크플로 작업과 관련된 작업자 수를 제어하고 워크플로의 다른 측면을 제어하여 확장성과 성능을 높일 수 있습니다. 또한 Service Catalog Puppet은 제품 및 단계 종속성을 관리하고 제품 프로비저닝을 조정하기 위한 depends_on 메커니즘을
프로비저닝 모드
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 도구 설명서를 참조하십시오
Hub
허브 프로비저닝 모드에서는 스포크 계정의 모든 Luigi 워크플로가 지정된 중앙 허브 계정에서 관리됩니다. 허브 계정은 스포크 계정에서 작업을 수행할 수 있는 IAM 역할을 맡지만 작업 관리는 허브 계정 내에서 이루어집니다. Hub 계정은 모든 Spoke 계정 프로비저닝 작업이 성공 또는 실패로 완료될 때까지 동기적으로 대기합니다. 그런 다음 최종 상태를 보고합니다. 허브 계정 모드는 가장 오래되고 가장 완성도가 높은 프로비저닝 모드입니다. 그러나 많은 사용자들이 프로비저닝 동시성과 속도를 높이기 위해 스포크 프로비저닝 모드로 전환했습니다.
스포크
스포크 모드에서 Service Catalog 허브 계정은 지정된 부트스트랩된 스포크 계정에서 실행할 Luigi 워크플로를 시작합니다. 스포크 워크플로가 완료되면 hub 계정에 알림이 전송됩니다. 스포크 계정의 오류는 hub 계정으로 올라갑니다. 허브 계정은 스포크 계정을 폴링하여 작업이 완료되었는지 확인하고 상태를 확인합니다.
스포크 모드는 거의 모든 것이 별도의 스포크 계정에서 실행되므로AWS 서비스 할당량 증가가 필요할 가능성이 가장 적습니다. 또한 스포크 모드는 중앙 제어를 유지하면서 허브 모드보다 훨씬 더 큰 동시성을 제공합니다. 허브 모드보다 프로비저닝 속도를 800% 향상시킬 수 있습니다. 스포크 모드는 제품 간DependsOn
관계를 통해 제품 체인을 지원하므로 의존하는 제품이 이미 프로비저닝되었는지 확인할 수 있습니다. 체인 제품을 포함하는 제품은 컴포넌트 체인 제품을 제공할 수도 있습니다. 특수AWS Lambda 함수 호출을 사용하여 필요한 단계를 수행할 수도 있습니다. 한 스포크의 결함은 다른 스포크와 분리됩니다.
스포크 모드는 최대 7개 지역에 980개 이상의 계정을 보유한 기업에서 사용합니다. 이러한 기업은 일반적으로 한 시간 내에 인프라의 모든 지역 및 계정에 제품을 프로비저닝할 수 있습니다.
참고
이러한 결과는 네트워킹 인프라, 워크로드,AWS 조직 허브 및 스포크 계정에 대한 할당량과 같은 요인에 따라 달라질 수 있습니다. 또한 프로비저닝되는 제품 리소스, 고유한 생성 시간 및 다른 리소스와의 종속성에 따라 달라집니다.
비동기
비동기 모드는 스포크 계정에서 프로비저닝 워크플로를 시작하지만 스포크로부터 완료 응답을 기다리거나 수신하지는 않습니다.
캐싱
Service Catalog Puppet이 워크플로의 속도를 최적화하기 위해 사용하는 또 다른 메커니즘은 워크플로의 단계를 나타내는 일반적인 작업을 캐시하는 것입니다. 캐시된 작업이 완료되면 Amazon Simple Storage Service (Amazon S3) 에 작업을 쓰기를 다음에 동일한 매개 변수로 동일한 세션에서 작업을 호출하면 Service Catalog Puppet은 작업을 다시 실행하는 대신 캐시된 값을 사용합니다. 자세한 내용은 Service Calog
DevSecOps 수명
Service Catalog Puppet에는 DevSecOps 파이프라인 관리 지원이 포함되어 있습니다. Service Catalog Puppet 개요에 설명된 대로 Service Catalog
광범위한 프로덕션 환경에서 사용하기 전에 제품 변경과 관련된 문제를 감지하려면 Service Catalog Puppet의 초기 배포를 위해 하나 이상의 카나리아 계정이 필요합니다. 새 릴리스를 테스트하고 확신을 얻은 후에는 카나리아가 아닌 프로덕션 계정으로 새 릴리스를 홍보할 수 있습니다. 문제가 발견되면 릴리스를 롤백하고 문제가 해결되면 다시 도입할 수 있습니다. 이 방법을 사용하는 경우 프로덕션 계정에 문제가 있는 카나리아 버전을 릴리스하면 프로덕션 문제가 발생할 수 있습니다. 다른 방법으로는 변경 사항을 프로덕션 환경에 릴리스하기 전에 각 제품 변경 사항에 대해 전체 회귀 테스트를 실행할 수 있습니다. 이로 인해 CI/CD 프로세스에 추가 오버헤드가 발생하지만 프로덕션 문제를 방지하는 데 도움이 됩니다. 개발팀에 가장 적합한 기능 출시 시나리오와 접근 방식을 결정하는 것은 DevSecOps 관리자의 책임입니다.
Service Catalog Puppet을 사용하면 여러 팀이 Service Catalog 제품 솔루션의 프로비저닝을 동시에 개발하고 테스트할 수 있습니다. 여러 개발자가 동시에 제품을 변경하지 않는 것이 가장 좋습니다. 대신 제품을 세분화된 구성 요소로 분리하여 개별적으로 동시에 수정할 수 있습니다.
또한 Service Catalog Puppet은 정적 및 단위 테스트 기능을 제공하는 어설션 문을 통해 테스트를 자동화하는 데도 도움이 됩니다. 정책 시뮬레이터를 사용하여 서비스 제어 정책 (SCP) 및 IAM 정책을 테스트할 수 있습니다. 기술적으로는 end-to-end 테스트이지만 SIT (시스템 통합 테스트) 환경에서 사용할 수 있습니다. 자세한 내용은 Service Catalog Puppet 설명서의 정책 시뮬레이션 사용
성숙도, 완전성 및 지원
Service Catalog Puppet은 공식적으로AWS 서비스 지원되지는 않지만 널리 채택되었습니다. 이 도구는 지난 몇 년 동안 대규모 조직에서 원하는 프로비저닝 기간 내에 수백 개의 OU 계정에 제품을 중앙에서 성공적으로 프로비저닝하는 데 사용되었습니다. 대규모 내결함성 제품 프로비저닝을 제공하는 것으로 입증되었습니다. Service Catalog Puppet에서 문제가 발생한 사용자는 GitHub 리포지토리에