Estes são os componentes fundamentais do Deployment Manager.
Configuração
A configuração descreve todos os recursos escolhidos para uma única implantação.
Além disso, ela é um arquivo escrito em sintaxe YAML que lista todos os recursos que você quer criar e as respectivas propriedades de cada recurso. Uma configuração precisa conter uma seção resources:
seguida pela lista de recursos a serem criados.
Cada recurso precisa conter três componentes:
name
: uma string definida pelo usuário para identificar esse recurso, comomy-vm
,project-data-disk
,the-test-network
.type
: o tipo do recurso que está sendo implantado, comocompute.v1.instance
,compute.v1.disk
. Os tipos de recursos básicos são descritos e listados na documentação Tipos de recurso compatíveis.properties
: os parâmetros para este tipo de recurso. Eles precisam corresponder às propriedades do tipo, comozone: asia-east1-a
,boot: true
.
Esta é uma configuração de exemplo:
resources:
- name: the-first-vm
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/f1-micro
disks:
- deviceName: boot
type: PERSISTENT
boot: true
autoDelete: true
initializeParams:
sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150423
networkInterfaces:
- network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NAT
Modelos
Uma configuração pode conter modelos, que, essencialmente, são partes do arquivo de configuração resumidas em unidades básicas individuais. Após criar um modelo, você poderá reutilizá-lo em todas as implementações, conforme necessário. Da mesma forma, se você reescrever configurações que compartilham propriedades muito parecidas, poderá resumir as partes compartilhadas em modelos. Os modelos são muito mais flexíveis do que os arquivos de configuração individuais e servem para facilitar a portabilidade entre implementações.
Um modelo é um arquivo escrito em Python ou Jinja2. O sistema do Deployment Manager interpreta cada modelo de maneira recursiva e mantém os resultados inline dentro do arquivo de configuração. Sendo assim, a interpretação de cada modelo resulta, eventualmente, na mesma sintaxe YAML para os recursos definidos acima e para o próprio arquivo de configuração.
Para criar um modelo simples, leia Como criar um modelo básico.
As configurações são descritas como totalmente expandidas ou não expandidas. Uma configuração totalmente expandida descreve todos os recursos e propriedades da implantação, incluindo qualquer conteúdo de arquivos de modelo importados. Por exemplo, ao fornecer uma configuração não expandida que usa o seguinte modelo:
imports:
- path: vm_template.jinja
resources:
- name: vm-instance
type: vm_template.jinja
properties:
zone: us-central1-a
project: myproject
Uma vez expandido, o arquivo de configuração terá os conteúdos de todos os modelos:
resources:
- name: the-first-vm
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/f1-micro
disks:
- deviceName: boot
type: PERSISTENT
boot: true
autoDelete: true
initializeParams:
sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150423
networkInterfaces:
- network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NAT
Recurso
Cada recurso de API é único. Ele pode ser um recurso de API fornecido por um tipo básico gerenciado pelo Google ou por um provedor de tipos. Por exemplo, uma instância do Compute Engine é um recurso único, uma instância do Cloud SQL também e assim por diante.
Para especificar um recurso, é necessário fornecer um tipo para ele. Veja a seção "Tipos", abaixo, para saber mais.
Tipos
Para criar um recurso no Deployment Manager, você precisa especificar um type
. Um tipo pode representar um único recurso de API, conhecido como tipo base, ou um grupo de recursos, conhecido como tipo composto, criado como parte da implantação.
Por exemplo, para criar uma instância de VM do Compute Engine, especifique o tipo base correspondente na configuração do seguinte modo:
resources:
- name: the-first-vm
type: compute.v1.instance # The type of resource to deploy
...
O Deployment Manager oferece uma lista de tipos base mantidos pelo Google que você pode usar imediatamente. Você pode encontrar uma lista com esses tipos no documento Tipos e propriedades de recurso suportados.
Tipos base e provedores de tipos
Um tipo base cria um único recurso primitivo. Por exemplo, os tipos base do Google incluem compute.v1.instance
, storage.v1.bucket
e sqladmin.v1beta4.database
, todos veiculados pela respectiva API Compute Engine V1, API Cloud Storage V1 e API Admin do Cloud SQL v1beta4.
Os tipos base são compatíveis com uma RESTful API que oferece suporte às operações criar, ler, atualizar e excluir (CRUD, na sigla em inglês). Também é possível criar tipos base adicionais com um provedor de tipos, caso os pertencentes ao Google não atendam às suas necessidades. Criar um provedor de tipos expõe todos os recursos de uma API como tipos base que você pode usar. Para criar um provedor de tipos, forneça um documento de descritor da API, que pode ser uma especificação OpenAPI ou um Google Discovery, ajuste os mapeamentos de entrada necessários para a API e registre o tipo no Deployment Manager. Após a criação, você e os outros usuários com acesso ao projeto podem usar os tipos fornecidos pelo provedor.
Quando você adiciona um provedor de tipos, todos os recursos fornecidos pela API e compatíveis com a interface RESTful com as operações CRUD serão expostos como tipos que podem ser usados na implantação.
A criação do seu próprio provedor de tipos é um cenário avançado, e o Google recomenda que você faça isso apenas se estiver familiarizado com a API que quer integrar.
Para saber como criar um provedor de tipos, consulte Como integrar ao Deployment Manager.
Ao chamar um tipo base nos modelos ou configurações, você usará uma das sintaxes abaixo, dependendo do tipo.
Para tipos básicos gerenciados pelo Google, use:
type: [API].[VERSION].[RESOURCE]
Por exemplo,
compute.v1.instance
.Para provedores de tipos gerenciados pelo Google (beta), use:
type: gcp-types/[PROVIDER]:[RESOURCE]
Para uma lista de provedores de tipos compatíveis, consulte Provedores de tipo do Google Cloud compatíveis.
Para tipos básicos fornecidos por um provedor de tipos, use:
type: [PROJECT_ID]/[TYPE_PROVIDER]:[COLLECTION]
Em que
[COLLECTION]
é o caminho para o recurso de API a ser implantado.
Tipos compostos
Um tipo composto contém um ou mais modelos que são pré-configurados para funcionarem juntos. Esses modelos se expandem para um grupo de tipos básicos quando integrados em uma implantação. Os tipos compostos são basicamente modelos hospedados que você pode adicionar ao Deployment Manager. Você pode criar tipos compostos para soluções comuns, para que elas sejam facilmente reutilizáveis, ou criar configurações complexas que poderão ser utilizadas novamente no futuro.
Por exemplo, você pode criar um tipo composto para implantar um grupo de instâncias gerenciadas de rede com balanceamento de carga. Um balanceador de carga de rede requer vários recursos do Google Cloud e certa configuração entre recursos. Portanto, é possível configurá-los uma única vez e registrar o tipo no Deployment Manager. Posteriormente, você e outros usuários com acesso ao projeto podem chamar esse tipo e implantá-lo em configurações futuras.
Para chamar um tipo composto na configuração, use:
type: [PROJECT_ID]/composite:[TYPE_NAME]
Por exemplo:
resources:
- name: my-composite-type
type: myproject/composite:example-composite-type
Para saber como criar um tipo composto, leia Como adicionar um tipo composto ao Deployment Manager.
Manifesto
Manifesto é um objeto somente leitura que contém a configuração original fornecida por você, inclusive todos os modelos importados, e também contém a lista de recursos totalmente expandida, criada pelo Deployment Manager. Sempre que você atualiza uma implantação, o Deployment Manager gera um novo arquivo de manifesto para refletir o novo estado da implantação. Durante a solução de problemas de uma implantação, é útil ver o manifesto.
Para mais informações, consulte Visualização de um manifesto.
Implantação
Implantação é uma coleção de recursos implantados e gerenciados juntos usando-se uma configuração.
Para saber mais informações, consulte Como criar uma implantação.
Próximas etapas
- Leia o guia de início rápido do Deployment Manager.
- Consulte o Guia passo a passo.
- Saiba mais sobre configurações eimplantações.