As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Service Catalog Puppet

O Service Catalog Puppet é implementado em Python usando a API Boto3 da AWS. Essa ferramenta oferece vários recursos avançados para configurar e provisionar produtos do Service Catalog. Os desenvolvedores podem configurar as informações de provisionamento de produtos e portfólios do Service Catalog usando modelos YAML que servem como manifestos. Os fluxos de trabalho de provisionamento do Service Catalog Puppet são compatíveis com produtos que exigem processos de implantação mais complexos do que o Service Catalog. Eles também são compatíveis com otimizações de performance para provisionar produtos em grande escala dentro de prazos rígidos.

O Service Catalog Puppet acessa os modelos do Service Catalog CloudFormation para provisionamento de produtos no momento da implantação. Ele chama o CloudFormation diretamente para implantar a pilha de modelos de provisionamento de um produto e ignora as restrições impostas pelo próprio processo de provisionamento do conjunto de pilhas do Service Catalog. Se o modelo de provisionamento usar macros para incluir outros scripts do CloudFormation, ou usar scripts aninhados do CloudFormation, você deverá fornecer acesso a esses scripts na conta de destino na parte de inicialização do fluxo de trabalho de provisionamento.

Para obter mais informações:

O Service Catalog Puppet é bastante fácil para os desenvolvedores aprenderem. Requer familiaridade com o CloudFormation para implementar modelos de provisionamento de produtos e modelos YAML para implementar manifestos. Há bons workshops disponíveis para atualizar novos desenvolvedores, como workshops individualizados.

Suporte para fluxos de trabalho de provisionamento

O Service Catalog Puppet emprega o mecanismo de orquestração de tarefas Python Luigi para implementar fluxos de trabalho de inicialização e provisionamento. Todas as etapas desses fluxos de trabalho são implementadas como tarefas do fluxo de trabalho do Luigi. Para ter uma visão geral do Luigi e como ele se compara a outras ferramentas populares de fluxo de trabalho, consulte Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlow no blog Data Revenue.

O Luigi permite que o Service Catalog Puppet controle o número de operadores associados às tarefas do fluxo de trabalho e outros aspectos dos fluxos de trabalho para melhor escalabilidade e performance. O Service Catalog Puppet também fornece um mecanismo depends_on para gerenciar dependências de produtos e etapas e para orquestrar o provisionamento de produtos. Esse recurso ajuda você a implementar e gerenciar operacionalmente definições refinadas de produtos e dependências complexas.

Modos de provisionamento

O Service Catalog Puppet é compatível com três modos de execução: hub, spoke e async. Todos os três modos provisionam produtos em portfólios que já estão definidos no Service Catalog. Eles contam com o compartilhamento de produtos do Service Catalog com as contas de destino e usam os perfis de administrador e de lançamento do Service Catalog para realizar o provisionamento nesses destinos. O Service Catalog Puppet executa as etapas de inicialização dentro da mesma organização com base nas configurações de perfil fornecidas nos arquivos de configuração YAML. A ferramenta também é compatível com o provisionamento para várias organizações de uma única conta hub. Nesse cenário, a inicialização deve ser executada manualmente nas organizações externas para permitir que o Service Catalog Puppet execute as ações de provisionamento necessárias nas contas da organização externa.

Em todos os modos de provisionamento, o Service Catalog Puppet implementa o provisionamento de produtos diretamente sem chamar o processo de provisionamento do Service Catalog. Você pode configurar um manifesto de provisionamento para usar as especificações do perfil e da conta de destino em uma restrição existente do conjunto de pilhas do Service Catalog. O Service Catalog Puppet usa essas informações para fazer seu próprio provisionamento com os fluxos de trabalho do Luigi.

Você pode definir destinos para o provisionamento do portfólio de produtos com base em uma abordagem de marcação de contas, além de especificar UOs ou contas diretamente. No provisionamento baseado em tags de conta, um produto de portfólio é provisionado para todas as contas que têm todas as tags no conjunto de tags de provisionamento de manifesto especificado. Por exemplo, se você quiser emitir um produto de portfólio para todas as contas de produção institucional nas regiões do Leste dos EUA, você pode especificar as tags type:prod, partition:us-east e scope:institutional-client. Você também pode declarar exclusões de conta e UO para proibir o provisionamento para UOs ou contas que tenham as tags especificadas por você, ou para contas que sejam membros dos destinos especificados pela UO. Para obter mais informações sobre a marcação de contas, consulte a documentação do Service Catalog Tools.

Modo Hub

No modo de provisionamento do hub, todos os fluxos de trabalho do Luigi para as contas spoke são gerenciados da conta hub central designada. A conta do hub assume um perfil do IAM que permite realizar ações em uma conta spoke, mas o gerenciamento das tarefas ocorre de dentro da conta hub. A conta hub espera de forma síncrona até que todas as tarefas de provisionamento da conta spoke sejam concluídas, com ou sem êxito. Em seguida, ela relata o status final. O modo de conta hub é o modo de provisionamento mais antigo e maduro. No entanto, muitos usuários migraram para o modo de provisionamento spoke para obter maior simultaneidade e velocidade de provisionamento.

Modo spoke

No modo spoke, a conta hub do Service Catalog inicia os fluxos de trabalho do Luigi para serem executados nas contas spoke inicializadas designadas. A conta hub é notificada quando os fluxos de trabalho do spoke são concluídos. Falhas em uma conta spoke chegam até a conta hub. A conta hub pesquisa a conta spoke para ver se ela foi concluída e para determinar o status.

É menos provável que o modo spoke exija aumentos de cotas do AWS service (Serviço da AWS) porque quase tudo é executado em contas spoke separadas. O modo spoke também oferece uma simultaneidade muito maior do que o modo hub, mantendo o controle central. Ele pode melhorar a velocidade de provisionamento em 800% em relação ao modo hub. O modo spoke é compatível com o encadeamento de produtos por meio de relacionamentos DependsOn entre produtos, o que garante que um produto do qual depende já tenha sido provisionado. Um produto que inclui produtos encadeados também pode fornecer um produto encadeado de componentes. Você também pode usar chamadas especializadas de função do AWS Lambda para realizar as etapas necessárias. As falhas em um spoke são isoladas de outros spokes.

O modo spoke é usado por empresas que têm mais de 980 contas em até sete regiões. Essas empresas geralmente conseguem provisionar um produto para todas as regiões e contas em sua infraestrutura em até uma hora.

Modo assíncrono

O modo assíncrono inicia fluxos de trabalho de provisionamento em contas spoke, mas não espera nem recebe respostas de conclusão dos spokes.

Armazenamento em cache

Outro mecanismo que o Service Catalog Puppet usa para otimizar a velocidade dos fluxos de trabalho é armazenar em cache tarefas comuns que representam etapas no fluxo de trabalho. Quando uma tarefa em cache é concluída, ela grava a saída no Amazon Simple Storage Service (Amazon S3). Na próxima vez que a tarefa for invocada na mesma sessão com os mesmos parâmetros, o Service Catalog Puppet usará os valores em cache em vez de executar novamente a tarefa. Para obter mais informações, consulte Caching na documentação do Service Catalog Puppet.

Suporte ao ciclo de vida do DevSecOps

O Service Catalog Puppet inclui suporte para o gerenciamento do pipeline de DevSecOps. Você pode usar as ações do Service Catalog Tools (conforme ilustrado na visão geral do Service Catalog Puppet) para automatizar testes e promover produtos em suas contas de ciclo de vida da AWS, incluindo a conta canário recomendada. Para obter mais informações, consulte Managing your environments na documentação do Service Catalog Puppet.

Para garantir que qualquer problema relacionado a uma alteração no produto seja detectado antes do uso generalizado na produção, o Service Catalog Puppet exige pelo menos uma conta canário para a implantação inicial. Depois de testar e ganhar confiança na nova versão, você pode promovê-la para contas de produção que não são canárias. Se você identificar algum problema, poderá reverter a versão e reintroduzi-la quando os problemas forem resolvidos. Quando você usa essa abordagem, problemas de produção poderão ocorrer se você lançar uma versão canária que tenha um problema nas contas de produção. Como abordagem alternativa, você pode executar testes de regressão completos para cada alteração do produto antes de liberar a alteração para a produção. Isso introduz uma sobrecarga adicional no processo de CI/CD, mas ajuda a evitar problemas de produção. É responsabilidade do administrador do DevSecOps determinar os melhores cenários e abordagens de lançamento de recursos para suas equipes de desenvolvimento.

O Service Catalog Puppet permite que várias equipes desenvolvam e testem o provisionamento de soluções de produtos do Service Catalog simultaneamente. Como prática recomendada, um produto não deve ser alterado por vários desenvolvedores ao mesmo tempo. Em vez disso, você pode dividir os produtos em componentes mais refinados para modificações separadas e simultâneas.

O Service Catalog Puppet também ajuda a automatizar os testes por meio de uma declaração de afirmação que fornece recursos de teste estático e unitário. Você pode testar políticas de controle de serviços (SCPs) e políticas do IAM usando simuladores de políticas. São testes tecnicamente de ponta a ponta, mas podem ser usados em ambientes de teste de integração de sistemas (SIT). Para obter mais informações, consulte Using policy simulations e Applying service control policies na documentação do Service Catalog Puppet.

Maturidade, integridade e suporte

Embora o Service Catalog Puppet não seja um AWS service (Serviço da AWS) oficialmente compatível, ele foi amplamente adotado. Essa ferramenta tem sido usada por grandes organizações nos últimos anos para provisionar produtos com sucesso e de forma centralizada para centenas de contas de UO dentro dos prazos de provisionamento desejados. Comprovadamente, ela oferece o provisionamento de produtos em escala com tolerância a falhas. Os usuários que encontrarem problemas com o Service Catalog Puppet podem registrá-los no repositório do GitHub para serem resolvidos pelos colaboradores desta solução do AWS Labs.