Práticas recomendadas para usar o Deployment Manager

Esta página descreve as práticas recomendadas para a criação de implantações com o Deployment Manager. Ela é destinada a usuários que já estão familiarizados com o Deployment Manager e não ensina 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 Cloud Console ou gcloud, poderá encontrar 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 pode ser modificado usando o Console do Cloud ou 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 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 que você transmita variáveis como zona, tamanho da máquina, número de máquinas, estado do aplicativo (teste, prod, preparo) nos modelos e receba valores de saída como o endereço IP e selfLink para 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 aplicará 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 pertencem 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.

Permissões

Por padrão, o Deployment Manager usa as credenciais da conta de serviço de APIs do Google para conseguir a autenticação em outras APIs. Essa conta foi projetada especificamente para executar os processos internos do Google no seu nome.

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

Use os papéis de IAM para restringir as permissões concedidas a usuários no uso do Deployment Manager.
Se quiser que os usuários consigam acessar os recursos criados pelo Deployment Manager, conceda a eles os papéis necessários para usar esses recursos. No entanto, não conceda as permissões que possibilitam implantar os recursos diretamente.
O membro com o papel de proprietário pode modificar a política de IAM. Portanto, conceda o papel de proprietário somente para os membros 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 de 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 de Administrador de papéis à conta de serviço de APIs do Google.

Para ver uma visão geral da conta de serviço de 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 canal de CI/CD para criar e excluir projetos de teste e de controle de qualidade por completo.
  • Você pode 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 canais de criação. Configurar redes, sub-redes e 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.
  • Usar o 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, exclua as implantações que tenham recursos sem monitoramento de estado, implantados como parte do pipeline.
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 canal de CI/CD, o Deployment Manager permite tratar a configuração de projetos como um código que você pode usar para reproduzir facilmente cópias consistentes do ambiente de produção atual ou, ainda, do ambiente atual com as alterações aplicadas, a fim de testá-lo com confianç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.