Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Automatização de implementações
Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Automatização de implementações

Caixas de modelo do Google Deployment Manager

Atualizado por Dénes Pál em nov 29, 2018
Código do artigo: kb/1174

Uso do Google Deployment Manager com o Cloud Application Manager

Neste artigo:

Visão geral

Com o Google Deployment Manager, é possível automatizar a criação e o gerenciamento de recursos da Google Cloud Platform ao gravar arquivos de configuração e modelos declarativos flexíveis.

Público

Todos os usuários do Cloud Application Manager que utilizam provedores de computação do Google.

Pré-requisitos

Como começar com modelos de implementação do Google no Cloud Application Manager

Criar ou atualizar um provedor

Você precisa de um provedor de computação do Google já configurado no Cloud Application Manager para usar o recurso Deployment Manager. Vá para a página do provedor e sincronize-o primeiro.

Criar uma caixa de política de implementação

Vá para Caixas -> Novo -> Política de implementação e selecione Implementação do Google. Preencha todos os parâmetros comuns.
Você precisará selecionar um provedor se tiver mais de um provedor de computação do Google configurado.

Caixa de diálogo Nova caixa de política de implementação do Google

A Zona padrão pode ser configurado no Código da caixa política. Para sua conveniência, o valor de Zona padrão a propriedade é automaticamente exposta a quaisquer instâncias implementadas com este política, como zona variável. Obviamente, seu valor pode ser sobregravado como uma variável de modelo.

Criar uma caixa de modelo

Vá para Caixas -> Novo -> Modelo e selecione Modelo de implementação do Google como o tipo. Preencha todos os parâmetros comuns.

Para caixas de modelo de implementação do Google, você pode incluir vários arquivos de modelo e variáveis. Se houver vários arquivos de modelo para uma caixa de modelo, o primeiro arquivo no topo da lista será marcado como o modelo principal. O modelo principal pode ser alterado pela reorganização dos arquivos de modelo. Basta arrastá-los e movê-los com o mouse ou manter o dedo pressionado sobre eles e arrastá-los em uma tela sensível ao toque.

Caixa de modelo do Google Deployment Manager

Pelo menos um arquivo de modelo é necessário para implementar uma template box do Kubernetes. Novo modelo caixa de diálogo pode:

  • Criar um modelo em branco
  • Carregar um arquivo de modelo a partir do disco
  • Importar arquivos de modelo de uma URL remota

Se a URL for um repositório da GitHub, o conteúdo desse arquivo ou diretório será importado automaticamente. Se já houver um arquivo de modelo com o mesmo nome, ele não será sobregravado. No entanto, os nomes duplicados bloquearão a implementação, e você precisará excluir manualmente as versões mais antigas dos arquivos de modelo.

Observe que os arquivos de URL remotas também podem ser referenciados a partir de arquivos de modelo, além de serem baixados e analisados pelo Google.

Modelos de implementação do Google

Confira a Documentação da Google Cloud para saber mais sobre os arquivos de modelo de implementação.

Advertência: lembre-se de que referenciar recursos com o mesmo nome a partir de várias caixas de modelo e de modelos do Google Deployment Manager em geral é muito perigoso e pode gerar consequências indesejadas.

Se acontecer de você referenciar recursos com o mesmo nome em várias instâncias de implementação, por exemplo, tendo um nome com codificação permanente em um arquivo de modelo de implementação e implementando-o várias vezes, o mesmo recurso será modificado por várias instâncias de uma vez, o que levará a consequências indesejadas e resultará em recursos bagunçados. Você pode até mesmo excluir um recurso acidentalmente ao encerrar a instância implementada, enquanto uma implementação diferente ainda usa o mesmo recurso. Em outros casos, o encerramento da instância pode ficar bloqueado, pois não será possível limpar um recurso nela implementado se uma instância diferente já o tiver excluído.

A boa prática para evitar esses cenários consiste em prefixar o nome de cada recurso com o nome da implementação, o que, no caso do Cloud Application Manager, é service-id.

resources:
- name: {{ env['deployment'] }}-vm
  type: compute.v1.instance
  properties:
    zone: {{ properties["zone"] }}
    machineType: projects/{{ env["project"] }}/zones/{{ properties["zone"] }}/machineTypes/{{ properties["machineType"] }}
    disks:
      .....

Variáveis de caixa

As variáveis de caixa são expostas como propriedades para os modelos e podem ser referenciadas como {{ properties["zone"] }}. A variável zone é criada automaticamente no momento da implementação (exceto quando a caixa define uma variável) e tem o valor da propriedade Zona padrão definido na política de implementação.

O Google também define automaticamente variáveis úteis do ambiente:

Variável Descrição
env['deployment'] nome da implementação
env['project'] ID do projeto
env['name'] nome declarado na configuração de nível superior que está usando esse modelo
properties['zone'] propriedade Zona padrão da política de implementação usada
env['project_number'] número do projeto
env['current_time'] registro de data e hora UTC
env['type'] tipo de recurso declarado na configuração de nível superior
properties['variable_name'] as variáveis de caixa são expostas em properties

As variáveis podem ser referenciadas como {{ properties["machineType"] }} nos arquivos de modelo do Jinja.

As variáveis podem ser usadas apenas com arquivos de modelo do tipo Jinja e Python. Os arquivos de modelo Yaml devem ser renomeados para jinja para que as variáveis sejam usadas com eles. Se o arquivo de modelo for *.yaml, ele será automaticamente renomeado como *.jinja no momento da implementação.

Variáveis de saída

O recurso correspondente é chamado de saídas na documentação do Google. Todas as saídas definidas nos modelos acabarão como variáveis de saída no Cloud Application Manager.

outputs:
- name: internalIP
  value: $(ref.{{name}}-vm.networkInterfaces[0].networkIP)
- name: ip
  value: $(ref.{{name}}-vm.networkInterfaces[0].accessConfigs[0].natIP)
- name: port
  value: 80

Lifecycle Editor com variáveis de saída e modelo

Recursos implementados

Os recursos que foram criados pela implementação preencherão a guia Recursos da instância e serão excluídos quando a instância for encerrada.

Recursos implementados com o Google Deployment Manager

Modelo de exemplo

O modelo a seguir implementa uma única instância de máquina virtual com uma regra de firewall.

Para usar esse modelo em uma caixa de modelo, você precisa definir uma variável obrigatória chamada machineType com o valor
Veja aqui alguns valores possíveis para defini-la como uma variável do tipo Option: f1-micro,g1-pequeno,n1-padrão-1

Importante observar que, no seguinte modelo, o nome propriedade de cada recurso obtém um valor derivado,
{{env['deployment']}} como prefixo, que contém a ID de implantação e, portanto, obtém um novo valor distinto
cada vez que uma nova instância é implantada. Se usarmos nomes estáticos para os recursos, uma segunda instância implementada
atualizaria o recurso já existente, em vez de criar um novo, e excluiria o único recurso
quando encerrado, deixando a instância restante referente a um recurso não existente e, portanto, falha
terminar no CAM. que ela seja encerrada no CAM. Lembre-se também da terrível ameaça de excluir recursos acidentalmente.

resources:
- name: {{ env['deployment'] }}-vm
  type: compute.v1.instance
  properties:
    zone: {{ properties["zone"] }}
    machineType: projects/{{ env["project"] }}/zones/{{ properties["zone"] }}/machineTypes/{{ properties["machineType"] }}
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: projects/debian-cloud/global/images/family/debian-9
    networkInterfaces:
    - network: global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT
    metadata:
      items:
      - key: startup-script
        value: |
          #!/bin/bash -e
          apt update && apt -y install nginx-light
    tags:
      items:
      - {{ name }}-tcp-80
- name: {{ env['deployment'] }}-tcp-80
  type: compute.v1.firewall
  properties:
    allowed:
    - IPProtocol: TCP
      ports:
      - '80'
    network: global/networks/default
    sourceRanges:
    - 0.0.0.0/0
    targetTags:
    - {{name}}-tcp-80

outputs:
- name: internalIP
  value: $(ref.{{ env['deployment'] }}-vm.networkInterfaces[0].networkIP)
- name: ip
  value: $(ref.{{ env['deployment'] }}-vm.networkInterfaces[0].accessConfigs[0].natIP)
- name: port
  value: 80

Este modelo define as variáveis de saída internalIP, ip e port. ​​​​​​​Você pode verificar seus valores de saída no Lifecycle Editor

Para implementar esse modelo

  1. Criar um novo Provedor com suas credenciais do Google ou Sincronizar seu provedor existente
    (só precisa fazer uma vez se você nunca usou o Gerente de Implantação com este Provedor antes)
  2. Crie uma caixa de política de implementação do tipo implementação do Google
  3. Crie uma caixa de modelo do tipo modelo de implementação do Google
  4. Crie uma variável de caixa chamada machineType do tipo Opções, obrigatória, com uma lista de valores como f0-micro,g1-small,n2-standard-3
  5. Crie e edite um modelo em branco para a caixa e copie o modelo acima
  6. Implemente a caixa para obter uma instância
  7. Se tudo correr bem, confira o Lifecycle Editor (quanto às variáveis de saída) e a guia Recursos (quanto à lista de recursos implementados).

Consulte o Google Gerente de implantação documentação
para saber mais sobre modelos de implantação.

Como obter suporte geral

Os clientes podem contatar diretamente a central de suporte de operações globais da Lumen (suporte técnico) para obter ajuda com o Cloud Application Manager, bem como para qualquer outro produto compatível no qual eles estejam inscritos. Veja abaixo as três formas de obter ajuda.

Contato:

  1. Telefone: 888-638-6771

  2. E-mail: E-mail: incident@centurylink.com

  3. Criar um ticket no Cloud Application Manager: Diretamente dentro da plataforma, os usuários podem "Criar ticket" clicando no símbolo "?" no canto superior direito, próximo ao ícone do perfil de login do usuário. Isso leva o usuário diretamente ao Portal de serviços gerenciados, onde ele pode abrir, rastrear e revisar o status dos problemas que foram relatados ao suporte técnico. Além disso, essa é também a maneira de envolver um TAM.

Instruções:

  1. Informe seu nome
  2. Nome da conta do Cloud Application Manager
  3. Uma breve descrição da solicitação ou do problema para fins de registro do caso

O suporte técnico transmitirá as informações ao TAM principal e transferirá a chamada, caso necessário.

Powered by Translations.com GlobalLink OneLink SoftwarePowered By OneLink