Esta página descreve as práticas recomendadas para criar implementações com o Google Cloud Deployment Manager. Esta página foi concebida para utilizadores que conhecem o Deployment Manager. Esta página não lhe ensina a usar o Deployment Manager.
Se for um utilizador recente do Deployment Manager, experimente o início rápido.
Gerir recursos
|
❑
Depois de criar um recurso como parte de uma implementação, use o Deployment Manager se precisar de modificar o recurso.
Se modificar um recurso sem usar o Deployment Manager, por exemplo, com a consola Google Cloud ou a
gcloud, pode ver erros se tentar modificar o recurso na implementação original.
Se quiser remover um recurso de uma implementação sem o eliminar, siga estes passos:
|
|
❑
Se tiver instâncias do Compute Engine na sua implementação e quiser
associar discos persistentes às instâncias, defina o disco
separadamente da instância para que o possa gerir facilmente. Por exemplo, na implementaçã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 quiser criar e gerir clusters privados 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 ver os requisitos e as considerações adicionais quando cria um cluster privado com o GKE, leia o artigo Configurar um cluster privado. |
Incluir credenciais na sua implementação
|
❑
O Deployment Manager oculta alguns campos relacionados com credenciais de propriedades nas suas configurações YAML. Esta ocultação ocorre com base na chave
da propriedade. O exemplo seguinte demonstra uma dessas ocultações:
# 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 incluir a credencial num modelo Jinja ou Python para a sua implementação, a credencial é ocultada nos ficheiros de configuração expandida e de esquema resultantes, mas continua visível no ficheiro de importação original. Por este motivo, recomendamos vivamente que coloque todas as credenciais que pretende manter secretas na configuração YAML de nível superior. Pode referenciá-los a partir daí usando propriedades de modelos.
|
|
❑
As credenciais incluídas num par de chave-valor num ficheiro YAML ou numa lista de itens não são ocultadas, como no exemplo seguinte. Por este motivo, recomendamos vivamente que não faculte credenciais ao Deployment Manager como pares de chave/valor em ficheiros 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 |
Modelos de edifícios
|
❑
Para acelerar a definição dos seus modelos, pondere começar com os modelos de exemplo prontos para produção do projeto do Cloud Foundation Toolkit.
|
|
❑
Se tiver requisitos de infraestrutura complexos, como a necessidade de criar
vários ambientes, leia o tutorial e os exemplos de
utilização do Deployment Manager em grande escala.
|
|
❑
Use o Python para criar os seus modelos.
Pode usar Python ou Jinja2 para criar modelos. É mais fácil começar a usar o Jinja, mas o Python é mais flexível para implementações complexas em que pode ter muitos recursos divididos em vários ambientes.
|
|
❑
Estruture o ficheiro de configuração (o ficheiro YAML) de modo que use apenas um tipo e use um modelo de nível superior como esse tipo para chamar todos os outros modelos. A adoção desta prática facilita a alteração de um conjunto de modelos num
tipo composto.
|
|
❑
Usar um ficheiro de esquema.
Os esquemas definem um conjunto de regras que um ficheiro de configuração tem de seguir para usar um modelo específico. Ao definir um esquema e incentivar outras pessoas a reverem os requisitos definidos num esquema, os seus utilizadores têm uma forma fácil de compreender que propriedades são configuráveis ou necessárias para o respetivo modelo. Isto
ajuda os utilizadores a consumir a configuração sem terem de investigar os detalhes
dos modelos. No mínimo, defina um ficheiro de esquema para o modelo de nível superior.
|
|
❑
Use propriedades do modelo
e saídas.
A utilização de propriedades e resultados permite-lhe transmitir variáveis, como a zona, o tamanho da máquina, o número de máquinas ou o estado da app (teste, produção, preparação), para os seus modelos e receber valores de resultados, como o endereço IP e o
selfLink para uma instância de VM. As propriedades e as saídas permitem que os seus modelos sejam flexíveis para que possam ser reutilizados sem modificações nos modelos subjacentes.
|
|
❑
Use ficheiros de modelos individuais que importa para o seu ficheiro de configuração principal. Isto oferece-lhe uma forma mais fácil de
trabalhar com configurações.
|
|
❑
Divida as suas configurações em unidades lógicas. Por exemplo, crie configurações separadas para serviços com estado, como bases de dados e contentores, e configurações para serviços mais transitó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 o
selfLink, o endereço IP ou o ID gerado pelo sistema de um recurso. Sem referências, o Deployment Manager cria todos os recursos em paralelo, pelo que não existe garantia de que os recursos dependentes sejam criados pela ordem correta. A utilização de referências aplicaria a ordem pela qual os recursos são criados.
|
|
❑
Pré-visualize
as implementações para avaliar como a realização de uma atualização afeta a sua implementação.
O Deployment Manager não instancia recursos reais quando
pré-visualiza uma configuração, mas expande a configuração completa e cria recursos "shell".
Isto dá-lhe a oportunidade de ver as alterações à sua implementação antes de as confirmar.
|
|
❑
Verifique os métodos da API para um recurso específico para compreender as implicações de
fazer uma atualização. Defina políticas de atualização quando atualiza uma implementação para ajudar a controlar como o Deployment Manager aplica cada atualização.
|
|
❑
Use etiquetas para os seus recursos. Se os recursos que está a definir suportarem etiquetas,
use-as para etiquetar os seus recursos. As etiquetas podem ajudar a categorizar recursos que pertencem a implementações diferentes e também são uma forma de distinguir em que fase os recursos podem estar, como se um recurso está a suportar um ambiente de produção ou de teste.
|
Gerir o tamanho das suas implementações
O Deployment Manager pode operar num grande número de recursos, sujeito a limites de quota. Se quiser reduzir o tempo necessário para criar, atualizar ou eliminar as suas implementações, pode reduzir o número de recursos em cada implementação individual.
|
❑
Se um grupo de recursos não depender de recursos fora desse grupo, pode mover esse grupo de recursos para uma implementação separada. Por exemplo, se a sua implementação contiver vários modelos, pode potencialmente agrupar cada modelo como uma implementação separada.
|
|
❑
Remova recursos desnecessários da sua configuração. Se precisar de mais recursos mais tarde, pode adicioná-los à sua implementação nessa altura.
|
|
❑
Opcionalmente, limite as implementações a 1000 ou menos recursos.
|
Autorizações
Por predefinição, o Deployment Manager usa as credenciais da conta de serviço das APIs Google para fazer a autenticação noutras APIs. A conta de serviço das APIs Google foi concebida especificamente para executar processos internos da Google em seu nome.
Quando quiser conceder a outros utilizadores acesso ao seu projeto do Deployment Manager, tem de conceder ao utilizador uma função do IAM que tenha as autorizações adequadas para usar o Deployment Manager. Existem várias funções de IAM predefinidas que pode usar para determinar o nível de acesso que um utilizador tem para chamar o Deployment Manager.
|
❑
Use funções do IAM para restringir as autorizações concedidas aos utilizadores para usar o Deployment Manager.
|
|
❑
Se quiser que os utilizadores possam aceder a recursos criados pelo
Deployment Manager, conceda-lhes as
funções de que precisam para usar os recursos,
mas não lhes conceda autorizações para implementar recursos diretamente.
|
|
❑
Conceder a função de proprietário a um principal permite-lhe modificar a política de IAM. Por conseguinte, conceda a função de proprietário apenas se o principal tiver um objetivo legítimo para gerir a política de IAM, uma vez que a sua política contém dados confidenciais de controlo de acesso. Ter um conjunto mínimo de utilizadores a gerir a conta simplifica qualquer auditoria que
possa ter de fazer.
|
|
❑
O Deployment Manager usa a conta de serviço das APIs Google para criar e gerir os seus recursos. Se estiver a usar o Deployment Manager para gerir
recursos críticos, como
funções do IAM personalizadas,
tem de atribuir funções do IAM adicionais à conta de serviço
das APIs Google predefinida. Por exemplo, se quiser usar o Deployment Manager para criar e gerir funções IAM personalizadas, tem de adicionar a função de administrador de funções à conta de serviço das APIs Google.
Para uma vista geral da conta de serviço das APIs Google, consulte o artigo Contas de serviço geridas pela Google. Para ver os passos para atribuir funções a uma conta de serviço, consulte o artigo Atribuir funções a contas de serviço. |
Automatização
Considere automatizar a criação de projetos, bem como a criação de recursos contidos nos projetos. Isto permite-lhe adotar uma abordagem de infraestrutura como código para o aprovisionamento de projetos. Esta abordagem oferece muitas vantagens, como a capacidade de:
- Permita a aplicação dos requisitos empresariais quando fornece projetos às equipas que precisam de acesso aos recursos do Google Cloud .
- Fornecer uma série de ambientes de projetos predefinidos que podem ser aprovisionados de forma rápida e fácil.
- Use o controlo de versões para gerir a configuração do projeto base.
- Tenha confiança de que está a implementar configurações de projetos reproduzíveis e consistentes.
- Incorpore a criação de projetos como parte de um processo de aprovisionamento automatizado.
|
❑
Automatize a criação de projetos através dos
modelos disponíveis no GitHub
como ponto de partida.
|
Integração contínua (IC) / implementação contínua (IC)
Use o Deployment Manager como parte do seu pipeline de CI/CD.
|
❑
Não use um pipeline de CI/CD para criar e eliminar projetos de teste e controlo de qualidade completos.
|
|
❑
Use o Deployment Manager para criar as partes com estado do projeto e a configuração de rede, e implemente-as fora do processo de CI/CD como parte da configuração inicial. Após a conclusão dos testes, pode eliminar implementações que contenham apenas recursos sem estado implementados como parte do pipeline.
|
|
❑
Como parte do processo de CI/CD, use uma configuração separada para implementar recursos
nos seus projetos de teste e controlo de qualidade. Depois de terminar os testes, pode usar o Deployment Manager para eliminar os recursos dos seus projetos de teste e controlo de qualidade.
|
| Testar implementações. Com a capacidade de incorporar o aprovisionamento de recursos como parte de um pipeline de CI/CD, o Deployment Manager permite-lhe tratar a configuração do seu projeto como código que pode testar facilmente e reproduzir cópias consistentes do ambiente de produção atual ou do ambiente atual com alterações aplicadas para testar com confiança. |
|
❑
Use o controlo de versões. A utilização de um sistema de controlo de versões como parte do processo de desenvolvimento para as suas implementações permite-lhe:
|