Service Catalog Puppet

O Service Catalog Puppet é implementado em Python usando AWS a API Boto3. Essa ferramenta oferece vários recursos poderosos 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 oferecem suporte a produtos que exigem processos de implantação mais complexos do que o Service Catalog. Eles também oferecem suporte a otimizações de desempenho para provisionar produtos em grande escala dentro de prazos agressivos.

O Service Catalog Puppet acessa os CloudFormation modelos do Service Catalog para provisionamento de produtos no momento da implantação. Ele solicita CloudFormation diretamente a implantação da 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 CloudFormation scripts ou usar scripts aninhados, você deverá fornecer acesso a esses CloudFormation scripts na conta de destino na parte de inicialização do fluxo de trabalho de provisionamento.

Para obter mais informações:

• Consulte a documentação e o GitHubrepositório do Service Catalog Puppet.

• Se você quiser usar o Service Catalog Puppet SDK para interagir com a ferramenta de forma programática para iniciar o provisionamento de produtos e portfólios, consulte a documentação do SDK.

• GitOpsé o mecanismo padrão para gerenciar o ambiente Service Catalog Puppet.

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

Support 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 de Luigi. Para uma visão geral de Luigi e como ela se compara a outras ferramentas populares de fluxo de trabalho, consulte Airflow versus Luigi versus Argo vs. MLFlow no blog Data Revenue. KubeFlow

Luigi permite que o Service Catalog Puppet controle o número de trabalhadores associados às tarefas do fluxo de trabalho e controle outros aspectos dos fluxos de trabalho, para melhor escalabilidade e desempenho. 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 de produtos refinadas e dependências complexas.

Modos de provisionamento

O Service Catalog Puppet suporta 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 confiam no compartilhamento de produtos do Service Catalog com as contas de destino e usam as funções 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 função fornecidas nos arquivos de configuração YAML. A ferramenta também oferece suporte ao provisionamento para várias organizações a partir de uma única conta de 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 da função 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 metas para o provisionamento do portfólio de produtos com base em uma abordagem de marcação de contas, além de especificar OUs nossas 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, scope:institutional-client e. Você também pode declarar exclusões de conta e UO para proibir o provisionamento para OUs contas que tenham as tags especificadas por você ou contas que sejam membros das metas especificadas pela OU. 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 a partir da conta do hub central designada. A conta do hub assume uma função do IAM que permite realizar ações em uma conta spoke, mas o gerenciamento das tarefas ocorre de dentro da conta do 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 sucesso. Em seguida, ele 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 de fala

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 do 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 central 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 AWS service (Serviço da AWS) cota porque quase tudo é executado em contas de fala separadas. O modo Spoke também oferece uma concorrência 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 oferece suporte ao encadeamento de produtos por meio de DependsOn relacionamentos 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 de AWS Lambda função especializadas para realizar as etapas necessárias. As falhas em um raio são isoladas de outros raios.

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

nota

Esses resultados podem variar com base em fatores como a infraestrutura de rede, a carga de trabalho e as cotas em vigor para as contas hub e spoke AWS da organização. Eles também dependem dos recursos do produto que estão sendo provisionados, de seus tempos de criação inerentes e de suas dependências de outros recursos.

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 sua saída no Amazon Simple Storage Service (Amazon S3). Na próxima vez que a tarefa for chamada 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.

DevSecOps suporte ao ciclo de vida

O Service Catalog Puppet inclui suporte para gerenciar o DevSecOps pipeline. 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 AWS ciclo de vida, incluindo a conta canary recomendada. Para obter mais informações, consulte Gerenciando seus ambientes 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 canary 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 nã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 podem 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 DevSecOps administrador 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 as políticas de controle de serviço (SCPs) e as políticas do IAM usando simuladores de políticas. Esses são end-to-end testes técnicos, mas podem ser usados em ambientes de teste de integração de sistemas (SIT). Para obter mais informações, consulte Usando simulações de políticas e Aplicando políticas de controle de serviço na documentação do Service Catalog Puppet.

Maturidade, integridade e suporte

Embora o Service Catalog Puppet não tenha suporte oficial AWS service (Serviço da AWS), 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 OU dentro dos prazos de provisionamento desejados. Ele provou fornecer provisionamento de produtos tolerante a falhas em grande escala. Os usuários que encontrarem problemas com o Service Catalog Puppet podem registrá-los no GitHub repositório para serem resolvidos pelos colaboradores desta AWS solução do Labs.