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 o console do Google Cloud ou o
gcloud, talvez ocorram erros caso tente 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 agilizar 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 references.
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.
|
|
❑
Opcionalmente, limite 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 das APIs do Google para fazer a autenticação em outras APIs. A conta de serviço de 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 quais permissões são concedidas a usuários para usar 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 os recursos, mas não conceda permissões 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.
|
|
❑
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:
|