Práticas recomendadas para usar o Deployment Manager

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Esta página descreve as práticas recomendadas para a criação de implantações com o Cloud Deployment Manager do Google. Ela é destinada a usuários que já estão familiarizados com o Deployment Manager. Aqui, não ensinaremos como usar esse produto.

Caso você não esteja familiarizado com o Deployment Manager, consulte o Guia de início rápido.

Como gerenciar recursos

❑  
Depois de criar um recurso como parte de uma implantação, use o Deployment Manager se precisar modificá-lo. Se você modificar um recurso sem usar o Deployment Manager, como com o Console do Google Cloud ou gcloud, poderá ver erros se tentar modificar o recurso na implantação original.

Se quiser remover um recurso de uma implantação sem excluí-lo, use as seguintes etapas:

  1. Na configuração da implantação, exclua a definição desse recurso.
  2. Atualize a implantação e, no seu comando "gcloud", adicione --delete-policy ABANDON. O recurso não está mais associado à implantação, e você pode modificá-lo usando o console do Google Cloud ou o gcloud.
❑  
Se você tiver instâncias do Compute Engine na implantação e quiser anexar discos persistentes a elas, defina o disco separadamente da instância para gerenciá-lo facilmente. Por exemplo, na implantação abaixo, o disco example-disk é definido separadamente da instância example-instance. Para anexar o disco, a configuração tem uma referência ao disco:

    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
    
❑  

Se você quiser criar e gerenciar clusters particulares do Google Kubernetes Engine (GKE) com o Deployment Manager, defina as seguintes opções privateClusterConfig e ipAllocationPolicy na implantação.


     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true
    

Para requisitos e considerações adicionais ao criar um cluster privado com o GKE, leia Configuração de um cluster privado.

Como incluir credenciais na implantação

❑  
O Deployment Manager edita alguns campos relacionados a credenciais de propriedades nas configurações do YAML. Essa edição ocorre com base na chave da propriedade. O exemplo a seguir demonstra uma edição:

    # Config provided to Deployment Manager
    resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: hunter2

   # Config as surfaced by Deployment Manager
   resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: (redacted)
    
❑  
Se você incluir a credencial em um modelo Jinja ou Python na implantação, a credencial será editada dos arquivos de configuração expandida e layout resultantes, mas ainda estará visível no arquivo de importação original. Por esse motivo, recomendamos que você coloque todas as credenciais que pretende manter em segredo na sua configuração YAML de nível superior. É possível referir-se a elas usando propriedades do modelo.
❑  
As credenciais incluídas em um par de chave-valor em um arquivo YAML ou uma lista de itens não serão editadas, como no exemplo a seguir. Por isso, recomendamos não fornecer credenciais ao Deployment Manager como pares de chave-valor em arquivos YAML ou listas de itens.

    # Not a valid instance configuration, used solely for demonstration
    resources:
    - name: example-resource
      type: gcp-types/compute-v1:instances
      properties:
        zone: us-central1-a
        disks:
        - autoDelete: true
          boot: true
    # Will not be redacted
          password: hunter2
    

Como criar modelos

❑  
Para acelerar a definição dos seus modelos, comece com os modelos de amostra prontos para produção do Projeto do Cloud Foundation Toolkit.
❑  
Se você tiver requisitos complexos de infraestrutura, como a necessidade de criar vários ambientes, leia o tutorial e as amostras de como usar o Deployment Manager em escala.
❑  
Use a linguagem Python para criar modelos. É possível usar Python ou Jinja2 para criar modelos. A linguagem Jinja é mais fácil de começar a usar, mas Python é mais flexível para implementações complexas em que você pode ter muitos recursos divididos em vários ambientes.
❑  
Estruture o arquivo de configuração (o arquivo YAML), de modo que ele use somente um tipo. Use um modelo de nível superior como o tipo para chamar todos os outros modelos. Essa prática facilita a alteração de um conjunto de modelos para um tipo composto.
❑  
Use um arquivo de esquema. Os esquemas definem um conjunto de regras que um arquivo de configuração precisa seguir para usar um modelo específico. Ao definir um esquema e encorajar outras pessoas a analisar os requisitos desse esquema, os usuários entenderão mais facilmente quais propriedades são configuráveis ou obrigatórias para o modelo respectivo. Isso ajuda os usuários a consumir a configuração sem precisar investigar os detalhes dos modelos. Pelo menos defina um arquivo de esquema para o modelo de nível superior.
❑  
Use propriedades de modelos e saídas. O uso de propriedades e saídas permite transmitir variáveis como zona, tamanho e número de máquinas ou o estado do aplicativo (teste, produção, preparo) nos modelos e retorna valores de saída, como o endereço o IP e o selfLink de uma instância de VM. As propriedades e saídas tornam os modelos flexíveis, fazendo com que possam ser reutilizados sem modificações nos modelos de base.
❑  
Use arquivos de modelo individuais que podem ser importados para o arquivo de configuração principal. Isso torna o trabalho com configurações mais gerenciável.
❑  
Divida as configurações em unidades lógicas. Por exemplo, crie configurações separadas para serviços com monitoramento de estado, como bancos de dados e buckets e para serviços mais temporários, como instâncias de front-end.
❑  
Use referências. As referências devem ser usadas para valores que não são definidos até que um recurso seja criado, como selfLink do recurso, endereço IP ou ID gerado pelo sistema. Sem referências, o Deployment Manager cria todos os recursos em paralelo, por isso, não há garantia de que os recursos dependentes são criados na ordem correta. Ao usar as referências, você imporá a ordem em que os recursos devem ser criados.
❑  
Visualize as implantações para avaliar como uma atualização as afetará. O Deployment Manager não instancia recursos reais quando você visualiza uma configuração. Em vez disso, ele expande a configuração completa e cria recursos "shell". Assim, você tem a oportunidade de ver as alterações na implantação antes de se comprometer com ela.
❑  
Verifique os métodos da API de um recurso específico para entender as implicações de uma atualização. Defina as políticas de atualização para uma implantação. Isso ajudará a controlar como o Deployment Manager aplica cada atualização.
❑  
Use rótulos nos recursos. É possível marcar os recursos que você está definindo se eles forem compatíveis com marcadores. Eles ajudam a categorizar recursos que pertençam a diferentes implementações. Além disso, são uma maneira de distinguir em que etapa os recursos estão, por exemplo, se um determinado recurso está servindo de suporte para o ambiente de produção ou de teste.

Como gerenciar o tamanho das implantações

O Deployment Manager pode operar em um grande número de recursos, sujeito aos limites de cota. Se você quiser reduzir o tempo necessário para criar, atualizar ou excluir suas implantações, poderá reduzir o número de recursos em cada implantação individual.

❑  
Se um grupo de recursos não depender de nenhum recurso fora desse grupo, será possível mover esse grupo de recursos para uma implantação separada. Por exemplo, se a implantação contiver vários modelos, será possível empacotar cada modelo como uma implantação separada.
❑  
Remova recursos desnecessários da sua configuração. Se precisar de mais recursos posteriormente, você poderá adicionar mais recursos à sua implantação nesse momento.
❑  
Também é possível limitar as implantações a 1.000 ou menos recursos.

Permissões

Por padrão, o Deployment Manager usa as credenciais da conta de serviço das APIs do Google para autenticar em outras APIs. A conta de serviço das APIs do Google foi projetada especificamente para executar processos internos do Google em seu nome.

Para conceder a outros usuários o acesso ao seu projeto no Deployment Manager, você precisa conceder ao usuário um papel do IAM que tenha as permissões apropriadas para usar o Deployment Manager. Há diversos papéis do IAM predefinidos que podem ser usados para determinar o tipo de acesso que um usuário terá para chamar o Deployment Manager.

❑  
Use papéis do IAM para restringir as permissões concedidas aos usuários no uso do Deployment Manager.
❑  
Se você quiser que os usuários acessem os recursos criados pelo Deployment Manager, conceda a eles os papéis necessários para usar recursos, mas não conceda permissões a eles para implantar recursos diretamente.
❑  
Conceder o papel proprietário a um principal permitirá que ele modifique a política do IAM. Portanto, conceda o papel de proprietário somente para os principal que tenham como propósito legítimo gerenciar a política de IAM, porque ela contém dados de controle de acesso confidenciais. Para simplificar as auditorias necessárias, o ideal é ter um grupo mínimo de usuários com permissão para gerenciar a política.
❑  
O Deployment Manager usa as contas de serviço de APIs do Google para criar e gerenciar seus recursos. Se você estiver usando o Deployment Manager para gerenciar recursos críticos, como papéis do IAM personalizados, você precisará atribuir outros papéis de IAM à conta de serviço padrão de APIs do Google. Por exemplo, se você quiser usar o Deployment Manager para criar e gerenciar papéis de IAM personalizados, será preciso adicionar o papel Administrador de papéis à conta de serviço de APIs do Google.

Para ver uma visão geral da conta de serviço das APIs do Google, consulte contas de serviço gerenciadas pelo Google.

Para ver as etapas para atribuir papéis a uma conta de serviço, consulte Como conceder papéis às contas de serviço.

Automação

Cogite automatizar a criação de projetos, bem como a criação dos recursos contidos nos projetos. Dessa forma, você pode adotar uma abordagem de infraestrutura como código para o provisionamento de projetos. Essa abordagem oferece muitos benefícios, como a capacidade de:

  • Permita a aplicação de requisitos corporativos ao fornecer projetos para as equipes que precisam acessar os recursos do Google Cloud.
  • fornecer uma série de ambientes de projeto predefinidos que podem ser provisionados rápida e facilmente;
  • usar o controle de versão para gerenciar a configuração do projeto básico;
  • ter certeza de que a implantação das configurações do projeto são reproduzíveis e consistentes;
  • incorporar a criação de projetos como parte de um processo de provisionamento automatizado.
❑  
Automatize a criação de projetos usando os modelos disponíveis no GitHub como ponto de partida.

Integração contínua/implantação contínua (CI/CD, na sigla em inglês)

Use o Deployment Manager como parte do canal de CI/CD.

❑  
Não use um pipeline de CI/CD para criar e excluir projetos de teste e de controle de qualidade por completo.
  • É possível optar por destruir as instâncias ou os recursos de VM que possam incorrer em custos adicionais. No entanto, não se desfaça dos ativos reutilizáveis que levam tempo para serem recriados, porque a exclusão desses recursos pode afetar negativamente o tempo necessário para concluir os pipelines de criação. Configurar redes, sub-redes ou regras de firewall não incorre em qualquer custo.
  • Lembre-se de que, se você excluir um projeto, ele continuará a fazer parte da sua cota de projetos por alguns dias até ser completamente removido. Isso também significa que não será possível usar o mesmo nome de projeto.
  • O uso do Deployment Manager permite excluir facilmente recursos de um projeto para que você não atinja suas cotas de recursos.
❑  
Use o Deployment Manager para criar itens com monitoramento de estado do projeto e da configuração da rede. Depois, implante esses itens externamente ao processo de CI/CD, como parte da configuração inicial. Após a conclusão dos testes, você pode excluir as implantações que contêm recursos sem monitoramento de estado, implantados como parte do canal.
❑  
Como parte do processo de CI/CD, use uma configuração separada para implantar recursos em projetos de teste e de controle de qualidade. Após concluir os testes, você pode usar o Deployment Manager para excluir os recursos dos projetos de teste e de controle de qualidade.
Teste as implantações. Devido à capacidade de incorporar o provisionamento de recursos ao pipeline de CI/CD, o Deployment Manager permite tratar a configuração de projetos como um código que você pode testar e reproduzir cópias consistentes da produção atual ou do ambiente atual com as alterações aplicadas para testar com segurança.
❑  
Use o controle de versão. O uso de um sistema de controle de versão como parte do processo de desenvolvimento nas implantações permite:
  • retornar à configuração válida anterior;
  • fornecer uma trilha de auditoria para alterações;
  • usar a configuração como parte de um sistema de implantação contínua.