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, é possível
erros se você tentar modificar o recurso na implantação original.
Se quiser remover um recurso de uma implantação sem excluí-lo, use as seguintes etapas:
|
|
❑
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: 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 recursos ou menos.
|
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 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 os papéis do IAM para restringir as permissões concedidas aos usuários
para o 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.
|
|
❑
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 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 pipeline de CI/CD para criar e excluir projetos de teste e de controle de qualidade por completo.
|
|
❑
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:
|