Noções básicas do Deployment Manager

Os seguintes componentes são os fundamentos do Deployment Manager.

Configuração

Uma configuração descreve todos os recursos que quer para uma única implementação. Uma configuração é um ficheiro escrito na sintaxe YAML que lista cada um dos recursos que quer criar e as respetivas propriedades de recursos. Uma configuração tem de conter uma secção resources: seguida da lista de recursos a criar.

Cada recurso tem de conter três componentes:

  • name: uma string definida pelo utilizador para identificar este recurso, como my-vm, project-data-disk ou the-test-network.
  • type - O tipo de recurso que está a ser implementado, como compute.v1.instance, compute.v1.disk. Os tipos de recursos base são descritos e apresentados na documentação Tipos de recursos suportados.
  • properties – Os parâmetros para este tipo de recurso. Têm de corresponder às propriedades do tipo, como zone: asia-east1-a e boot: true.

Segue-se um exemplo de configuração:

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 são essencialmente partes do ficheiro de configuração que foram abstraídas em bases individuais. Depois de criar um modelo, pode reutilizá-lo em implementações, conforme necessário. Da mesma forma, se estiver a reescrever configurações que partilham propriedades muito semelhantes, pode abstrair as partes partilhadas em modelos. Os modelos são muito mais flexíveis do que os ficheiros de configuração individuais e destinam-se a suportar a portabilidade fácil entre implementações.

Um ficheiro de modelo é escrito em Python ou Jinja2. O sistema do Deployment Manager interpreta cada modelo recursivamente e incorpora os resultados no ficheiro de configuração. Como tal, a interpretação de cada modelo acaba por resultar na mesma sintaxe YAML para recursos que a definida acima para o próprio ficheiro de configuração.

Para criar um modelo simples, leia o artigo 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 implementação, incluindo qualquer conteúdo de ficheiros de modelos importados. Por exemplo, forneceria uma configuração não expandida que usa um modelo da seguinte forma:

imports:
- path: vm_template.jinja

resources:
- name: vm-instance
  type: vm_template.jinja
  properties:
    zone: us-central1-a
    project: myproject

Depois de expandido, o ficheiro de configuração contém o conteúdo de todos os seus modelos, da seguinte forma:

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

Um recurso representa um único recurso da API. Pode ser um recurso de API fornecido por um tipo base gerido pela Google ou um recurso de API fornecido por um fornecedor de tipos. Por exemplo, uma instância do Compute Engine é um único recurso, uma instância do Cloud SQL é um único recurso e assim sucessivamente.

Para especificar um recurso, indica um Tipo para esse recurso. Consulte a secção Tipos abaixo para saber mais sobre os tipos.

Tipos

Para criar um recurso no Deployment Manager, tem de especificar um type. Um tipo pode representar um único recurso da API, conhecido como tipo base, ou um conjunto de recursos, conhecido como tipo composto, que será criado como parte da sua implementação.

Por exemplo, para criar uma instância de VM do Compute Engine, especifique o tipo base correspondente na sua configuração da seguinte forma:

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 pela Google que pode usar imediatamente. Pode encontrar uma lista destes tipos na documentação Tipos de recursos e propriedades suportados.

Tipos base e fornecedores de tipos

Um tipo base cria um único recurso primitivo. Por exemplo, os tipos base pertencentes à Google incluem compute.v1.instance, storage.v1.bucket e sqladmin.v1beta4.database, que são todos fornecidos pela respetiva API Compute Engine V1, API Cloud Storage V1 e API Cloud SQL v1beta4 Admin.

Os tipos base são suportados por uma API RESTful que suporta operações de criação, leitura, atualização e eliminação (CRUD). Também pode criar tipos base adicionais adicionando um fornecedor de tipos se os tipos pertencentes à Google não satisfizerem as suas necessidades. A criação de um fornecedor de tipos expõe todos os recursos de uma API como tipos base que pode usar. Para criar um fornecedor de tipos, tem de fornecer um documento de descritor da API, que pode ser uma especificação OpenAPI ou uma Google Discovery, ajustar quaisquer mapeamentos de entrada necessários para a API e registar o tipo no Deployment Manager. Depois de criados, os tipos fornecidos pelo fornecedor podem ser usados por si e por outros utilizadores com acesso ao seu projeto.

Quando adiciona um fornecedor de tipos, todos os recursos fornecidos pela API e suportados por uma interface RESTful com operações de criação, leitura, atualização e eliminação (CRUD) são expostos como tipos que pode usar na sua implementação.

A criação do seu próprio fornecedor de tipos é um cenário avançado, e a Google recomenda que o faça apenas se estiver muito familiarizado com a API que quer integrar.

Para saber como criar um fornecedor de tipos, consulte o artigo Integração com o Deployment Manager.

Quando chama um tipo base nos seus modelos ou configurações, usa uma das seguintes sintaxes, consoante o tipo.

  • Para tipos base geridos pela Google, use:

    type: [API].[VERSION].[RESOURCE]
    

    Por exemplo, compute.v1.instance.

  • Para fornecedores de tipos geridos pela Google (beta), use:

    type: gcp-types/[PROVIDER]:[RESOURCE]
    

    Para ver uma lista dos fornecedores de tipos suportados, consulte o artigo Fornecedores de Google Cloud tipos suportados.

  • Para tipos base fornecidos por um fornecedor de tipos, use:

    type: [PROJECT_ID]/[TYPE_PROVIDER]:[COLLECTION]
    

    Onde [COLLECTION] é o caminho para o recurso da API a implementar.

Tipos compostos

Um tipo composto contém um ou mais modelos que estão pré-configurados para funcionar em conjunto. Estes modelos expandem-se para um conjunto de tipos base quando implementados numa implementação. Os tipos compostos são essencialmente modelos alojados que pode adicionar ao Deployment Manager. Pode criar tipos compostos para soluções comuns, de modo que a solução seja facilmente reutilizável, ou criar configurações complexas que pode reutilizar no futuro.

Por exemplo, pode criar um tipo composto que implementa um grupo de instâncias gerido com balanceamento de carga de rede. Um equilibrador de carga de rede requer vários Google Cloud recursos e alguma configuração entre recursos, para que possa configurar estes recursos uma vez e registar o tipo no Deployment Manager. Posteriormente, você e outros utilizadores com acesso ao seu projeto podem chamar esse tipo e implementá-lo em configurações futuras.

Para chamar um tipo composto na sua 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 o artigo Adicionar um tipo composto ao Gestor de Implementações.

Manifesto

Um manifesto é um objeto só de leitura que contém a configuração original que forneceu, incluindo todos os modelos importados, e também contém a lista de recursos totalmente expandida, criada pelo Deployment Manager. Sempre que atualiza uma implementação, o Deployment Manager gera um novo ficheiro de manifesto para refletir o novo estado da implementação. Quando resolve um problema com uma implementação, é útil ver o manifesto.

Para mais informações, consulte o artigo Ver um manifesto.

Implementação

Uma implementação é uma coleção de recursos implementados e geridos em conjunto, através de uma configuração.

Para mais informações, consulte o artigo Criar uma implementação.

O que se segue?