Fundamentos do Deployment Manager

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, como my-vm, project-data-disk, the-test-network.
  • type: o tipo do recurso que está sendo implantado, como compute.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, como zone: 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 ver uma lista dos 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. Assim, é possível definir esses recursos em uma configuração 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]

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.

A seguir