Como automatizar a infraestrutura com o Cloud Composer

Neste tutorial, demonstraremos uma maneira de automatizar a infraestrutura em nuvem usando o Cloud Composer. O exemplo mostra como programar backups automáticos de instâncias de máquina virtual (VM) do Compute Engine.

O Cloud Composer é um serviço de orquestração de fluxo de trabalho totalmente gerenciado no Google Cloud. O Cloud Composer permite criar fluxos de trabalho com uma API Python, programá-los para serem executados de forma automática ou iniciá-los manualmente, além de monitorar a execução de tarefas em tempo real por meio de uma interface gráfica.

O Cloud Composer é baseado no Apache Airflow. O Google executa essa plataforma de orquestração de código aberto em um cluster do Google Kubernetes Engine (GKE). Esse cluster gerencia os workers do Airflow e abre uma série de oportunidades de integração com outros produtos do Google Cloud.

Este tutorial é destinado a operadores, administradores de TI e desenvolvedores interessados em automatizar a infraestrutura e se aprofundar nos principais recursos do Cloud Composer. Ele não serve como guia de recuperação de desastre (DR, na sigla em inglês) em nível corporativo nem como um guia de práticas recomendadas para backups. Para mais informações sobre como criar um plano de DR para sua empresa, consulte o guia de planejamento de recuperação de desastres.

Como definir a arquitetura

Os fluxos de trabalho do Cloud Composer são definidos pela criação de um grafo acíclico dirigido (DAG). Por uma perspectiva do Airflow, um DAG é uma coleção de tarefas organizadas para refletir as interdependências direcionais delas. Neste tutorial, você aprenderá como definir um fluxo de trabalho do Airflow que é executado regularmente para fazer backup de uma instância de máquina virtual do Compute Engine usando snapshots do disco permanente.

A VM do Compute Engine usada neste exemplo consiste em uma instância com um disco permanente de inicialização associado. Seguindo as diretrizes de snapshots, descritas posteriormente, o fluxo de trabalho de backup do Cloud Composer chama a API Compute Engine para interromper a instância, tirar um snapshot do disco permanente e reiniciar a instância. Entre essas tarefas, o fluxo de trabalho aguarda que cada operação seja concluída antes de prosseguir.

O diagrama a seguir resume a arquitetura:

Arquitetura para automatizar a infraestrutura

Antes de começar o tutorial, a próxima seção mostra como criar um ambiente do Cloud Composer. A vantagem desse ambiente é que ele usa vários produtos do Google Cloud, mas você não precisa configurar cada um deles individualmente.

  • Cloud Storage: o DAG, o plug-in e os registros do Airflow são armazenados em um bucket do Cloud Storage.
  • Google Kubernetes Engine: a plataforma Airflow é baseada em uma arquitetura de microsserviço e é adequada para execução no GKE.
  • Os workers do Airflow carregam definições de plug-in e fluxo de trabalho do Cloud Storage e executam cada tarefa usando a API Compute Engine.
  • O programador do Airflow garante que os backups sejam executados na cadência configurada e com a ordem de tarefas adequada.
  • O Redis é usado como um intermediário de mensagem entre os componentes do Airflow.
  • O Cloud SQL Proxy é usado para se comunicar com o repositório de metadados.
  • Cloud SQL e App Engine Flex: o Cloud Composer também usa uma instância do Cloud SQL para metadados e um aplicativo do App Engine Flex que exibe a IU do Airflow. Esses recursos não são mostrados no diagrama porque estão em um projeto separado gerenciado pelo Google.
  • Para mais detalhes, consulte a visão geral do Cloud Composer.

    Como escalonar o fluxo de trabalho

    O caso de uso apresentado neste tutorial é simples: tire um instantâneo de uma única máquina virtual com uma programação fixa. No entanto, um cenário real pode incluir centenas de VMs pertencentes a diferentes partes da organização ou camadas distintas de um sistema, cada uma exigindo programações de backup diversas. O escalonamento não se aplica apenas ao nosso exemplo com VMs do Compute Engine, mas a qualquer componente de infraestrutura para o qual um processo programado precisa ser executado.

    O Cloud Composer se destaca nesses cenários complexos porque é um mecanismo de fluxo de trabalho completo baseado no Apache Airflow hospedado na nuvem, e não só uma alternativa ao Cloud Scheduler ou cron.

    Os DAGs do Airflow, representações flexíveis de um fluxo de trabalho, se adaptam às necessidades reais enquanto ainda são executados a partir de um único codebase. Para criar DAGs adequados ao seu caso de uso, é possível usar uma combinação das duas abordagens a seguir:

    • Crie uma instância do DAG para grupos de componentes de infraestrutura em que a mesma programação possa ser usada para iniciar o processo.
    • Crie instâncias do DAG independentes para grupos de componentes de infraestrutura que exigem programações próprias.

    Um DAG pode processar componentes em paralelo. Uma tarefa precisa iniciar uma operação assíncrona para cada componente ou criar um branch para processar cada componente. É possível criar DAGs dinamicamente a partir do código para adicionar ou remover ramificações e tarefas conforme necessário.

    Além disso, é possível modelar dependências entre camadas de aplicativos no mesmo DAG. Por exemplo: talvez você queira parar todas as instâncias do servidor da Web antes de interromper qualquer instância do servidor de aplicativos.

    Essas otimizações estão fora do escopo deste tutorial.

    Como usar práticas recomendadas para snapshots

    O disco permanente (DP) é um armazenamento em blocos durável que pode ser anexado a uma instância de máquina virtual e usado como disco de inicialização principal para a instância ou como disco secundário de não inicialização para dados críticos. Os DPs são altamente disponíveis. Em cada gravação, três réplicas são gravadas, mas os clientes do Google Cloud são cobrados apenas por uma delas.

    Um instantâneo é uma cópia exata de um disco permanente em um determinado momento. Os instantâneos são incrementais, compactados e armazenados de maneira transparente no Cloud Storage.

    É possível tirar instantâneos de qualquer disco permanente enquanto os aplicativos estão em execução. Nenhum instantâneo conterá um bloco parcialmente gravado. No entanto, se uma operação de gravação abrangendo vários blocos estiver em execução quando o back-end receber a solicitação de criação de instantâneo, essa captura instantânea poderá conter apenas alguns dos blocos atualizados. Lide com essas inconsistências da mesma forma que trataria de desligamentos com erros.

    Recomendamos que você siga estas diretrizes para garantir que os instantâneos sejam consistentes:

    • Minimize ou evite gravações em disco durante o processo de criação de instantâneos. Programar backups fora do horário de pico é um bom começo.
    • Para discos secundários que não sejam de inicialização, pause aplicativos e processos que gravam dados e congelam ou desconectam o sistema de arquivos.
    • Para discos de inicialização, não é seguro ou viável congelar o volume-raiz. Parar a instância da máquina virtual antes de tirar um snapshot pode ser uma abordagem adequada.

      Para evitar a inatividade do serviço causada pelo congelamento ou parada de uma máquina virtual, recomendamos usar uma arquitetura altamente disponível. Para mais informações, consulte Cenários de recuperação de desastre para aplicativos.

    • Use uma convenção de nomenclatura consistente para os instantâneos. Por exemplo, use um carimbo de data/hora com a granularidade apropriada, concatenada com o nome da instância, disco e zona.

    Para mais informações sobre a criação de snapshots consistentes, consulte as práticas recomendadas de snapshots.

    Objetivos

    • Criar operadores do Airflow personalizados e um sensor para o Compute Engine.
    • Criar um fluxo de trabalho do Cloud Composer usando os operadores do Airflow e um sensor.
    • Programar o fluxo de trabalho para fazer backup de uma instância do Compute Engine em intervalos regulares.

    Custos

    Use a calculadora de preços para gerar uma estimativa de custo com base no uso previsto.

    Antes de começar

    1. Faça login na sua Conta do Google.

      Se você ainda não tiver uma, inscreva-se.

    2. No Console do Cloud, na página de seletor de projetos, selecione ou crie um projeto do Cloud.

      Acessar a página do seletor de projetos

    3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud. Saiba como confirmar se a cobrança está ativada para o seu projeto.

    4. Crie um ambiente do Cloud Composer. Para minimizar o custo, escolha um tamanho de disco de 20 GB.

      IR PARA A PÁGINA "CRIAR AMBIENTE"

      Geralmente, leva cerca de 15 minutos para provisionar o ambiente do Cloud Composer, mas isso pode levar até uma hora.

    5. O código completo deste tutorial está disponível no GitHub. Para examinar os arquivos conforme você segue, abra o repositório no Cloud Shell:

      ACESSAR o Cloud Shell
    6. No diretório inicial do console do Cloud Shell, execute o comando a seguir:
      git clone https://github.com/GoogleCloudPlatform/composer-infra-python.git

    Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a limpeza.

    Como configurar uma instância de exemplo do Compute Engine

    A primeira etapa é criar a instância da máquina virtual de exemplo do Compute Engine para fazer o backup. Essa instância executa o WordPress, um sistema de gerenciamento de conteúdo de código aberto.

    Siga estas etapas para criar a instância do WordPress no Compute Engine:

    1. No Google Cloud Marketplace, acesse a página de lançamento do WordPress certificada pelo Bitnami.
    2. Clique em Iniciar.
    3. Uma janela pop-up com uma lista dos seus projetos é exibida. Selecione o projeto que você criou anteriormente para este tutorial.

      O Google Cloud configura as APIs necessárias no projeto e, após uma breve espera, mostra uma tela com as diferentes opções de configuração da instância do WordPress no Compute Engine.

    4. Opcionalmente, altere o tipo de disco de inicialização para SSD para aumentar a velocidade de inicialização da instância.

    5. Clique em Implantar.

      Você é levado para a tela do Deployment Manager, onde é possível ver o status da implantação.

      O script do WordPress no Deployment Manager cria a instância do WordPress no Compute Engine e duas regras de firewall para permitir que o tráfego TCP atinja a instância pelas portas 80 e 443. Esse processo pode levar vários minutos enquanto cada item é implantado e mostra um ícone indicativo do progresso.

      Quando o processo estiver concluído, sua instância do WordPress estará pronta e disponibilizará o conteúdo padrão no URL do site. A tela do Deployment Manager mostra o URL do site (endereço do site), o URL do console de administração (URL do administrador) com usuário e senha, links de documentação e as próximas etapas sugeridas.

      Deployment Manager mostrando instância implantada

    6. Clique no endereço do site para verificar se sua instância do WordPress está funcionando. Você verá uma página de blog padrão do WordPress.

    A instância de exemplo do Compute Engine agora está pronta. A próxima etapa é configurar um processo de backup incremental automático do disco permanente dessa instância.

    Como criar operadores personalizados do Airflow

    Para fazer backup do disco permanente da instância de teste, é possível criar um fluxo de trabalho do Airflow que pare a instância, tire um snapshot do disco permanente e a reinicie. Cada uma dessas tarefas é definida como código com um operador do Airflow personalizado. O código dos operadores é, então, agrupado em um plug-in do Airflow.

    Nesta seção, você aprenderá a criar operadores personalizados do Airflow que chamam a biblioteca de cliente de Python do Compute Engine para controlar o ciclo de vida da instância. Você tem outras opções para fazer isso, por exemplo:

    • Use o BashOperator do Airflow para executar comandos gcloud compute.
    • Use o HTTPOperator do Airflow para executar chamadas HTTP diretamente para a API REST do Compute Engine.
    • Use o PythonOperator do Airflow para chamar funções arbitrárias do Python sem definir operadores personalizados.

    Este tutorial não explora essas alternativas.

    Autorizar chamadas para a API Compute Engine

    Os operadores personalizados criados neste tutorial usam a biblioteca de cliente do Python para chamar a API Compute Engine. As solicitações para a API precisam ser autenticadas e autorizadas. A maneira recomendada é usar uma estratégia chamada Application Default Credentials (ADC).

    A estratégia ADC é aplicada sempre que uma chamada é feita a partir de uma biblioteca de cliente:

    1. A biblioteca verifica se uma conta de serviço está especificada na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS.
    2. Se a conta de serviço não for especificada, a biblioteca usará a conta de serviço padrão fornecida pelo Compute Engine ou GKE.

    Se esses dois métodos falharem, ocorrerá um erro.

    Os operadores do Airflow desse tutorial se enquadram no segundo método. Quando você cria o ambiente do Cloud Composer, um cluster do GKE é provisionado. Os nós desse cluster executam pods de worker do Airflow. Por sua vez, esses workers executam o fluxo de trabalho com os operadores personalizados que você define. Como você não especificou uma conta de serviço quando criou o ambiente, a conta de serviço padrão para os nós de cluster do GKE é aquela usada pela estratégia ADC.

    Os nós do cluster do GKE são instâncias do Compute Engine. Por isso, é fácil receber as credenciais associadas à conta de serviço padrão do Compute Engine no código do operador.

    def get_compute_api_client(self):
      credentials = GoogleCredentials.get_application_default()
      return googleapiclient.discovery.build(
          'compute', 'v1', cache_discovery=False, credentials=credentials)

    Esse código usa as credenciais do aplicativo padrão para criar um cliente Python que enviará solicitações para a API Compute Engine. Nas seções a seguir, você usará esse código como referência ao criar cada operador do Airflow.

    Como alternativa ao uso da conta de serviço padrão do Compute Engine, é possível criar uma conta de serviço e configurá-la como uma conexão no console de administração do Airflow. Esse método é descrito na página Como gerenciar conexões do Airflow e permite um controle de acesso mais detalhado aos recursos do Google Cloud. Este tutorial não explora essa alternativa.

    Desligar a instância do Compute Engine com segurança

    Esta seção analisa a criação do primeiro operador personalizado do Airflow, StopInstanceOperator. Esse operador chama a API Compute Engine para interromper a instância do Compute Engine que está executando o WordPress:

    1. No Cloud Shell, use um editor de texto, como nano ou vim, para abrir o arquivo gce_commands_plugin.py:

      vi $HOME/composer-infra-python/no_sensor/plugins/gce_commands_plugin.py
      
    2. Examine as importações na parte superior do arquivo:

      import datetime
      import logging
      import time
      from airflow.models import BaseOperator
      from airflow.plugins_manager import AirflowPlugin
      from airflow.utils.decorators import apply_defaults
      import googleapiclient.discovery
      from oauth2client.client import GoogleCredentials

      As importações mais relevantes são:

      • BaseOperator: classe base que todos os operadores personalizados do Airflow precisam herdar.
      • AirflowPlugin: classe base para criar um grupo de operadores, formando um plug-in.
      • apply_defaults: decorador de função que preenche argumentos com valores padrão se eles não forem especificados no construtor do operador.
      • GoogleCredentials: classe usada para recuperar as credenciais padrão do app.
      • googleapiclient.discovery: ponto de entrada da biblioteca de cliente que permite a descoberta das APIs básicas do Google. Nesse caso, a biblioteca de cliente cria um recurso para interagir com a API Compute Engine.
    3. Em seguida, observe a classe StopInstanceOperator abaixo das importações:

      class StopInstanceOperator(BaseOperator):
        """Stops the virtual machine instance."""
      
        @apply_defaults
        def __init__(self, project, zone, instance, *args, **kwargs):
          self.compute = self.get_compute_api_client()
          self.project = project
          self.zone = zone
          self.instance = instance
          super(StopInstanceOperator, self).__init__(*args, **kwargs)
      
        def get_compute_api_client(self):
          credentials = GoogleCredentials.get_application_default()
          return googleapiclient.discovery.build(
              'compute', 'v1', cache_discovery=False, credentials=credentials)
      
        def execute(self, context):
          logging.info('Stopping instance %s in project %s and zone %s',
                       self.instance, self.project, self.zone)
          self.compute.instances().stop(
              project=self.project, zone=self.zone, instance=self.instance).execute()
          time.sleep(90)

      A classe StopInstanceOperator tem três métodos:

      • __init__: o construtor da classe. Recebe o nome do projeto, a zona onde a instância está sendo executada e o nome da instância que você quer parar. Além disso, inicializa a variável self.compute chamando get_compute_api_client.
      • get_compute_api_client: método auxiliar que retorna uma instância da API Compute Engine. Usa o ADC fornecido por GoogleCredentials para autenticar com a API e autorizar chamadas subsequentes.
      • execute: método do operador principal modificado de BaseOperator. O Airflow chama esse método para executar o operador. O método insere uma mensagem informativa nos registros e, em seguida, chama a API Compute Engine para interromper a instância do Compute Engine especificada pelos três parâmetros recebidos no construtor. A função sleep() no final aguarda até que a instância seja interrompida. Em um ambiente de produção, é preciso usar um método mais determinístico, como a comunicação cruzada do operador. Essa técnica é descrita mais adiante neste tutorial.

    O método stop() da API Compute Engine encerra a instância da máquina virtual de maneira limpa. O sistema operacional executa os scripts de desligamento init.d, incluindo o do WordPress em /etc/init.d/bitnami. Esse script também processa a inicialização do WordPress quando a máquina virtual é iniciada novamente. Você pode examinar a definição do serviço com a configuração de desligamento e inicialização em /etc/systemd/system/bitnami.service.

    Criar snapshots de backup incremental com nomes exclusivos

    Esta seção cria o segundo operador personalizado, SnapshotDiskOperator. Esse operador tira um snapshot do disco permanente da instância.

    No arquivo gce_commands_plugin.py que você abriu na seção anterior, observe a classe SnapshotDiskOperator:

    class SnapshotDiskOperator(BaseOperator):
      """Takes a snapshot of a persistent disk."""
    
      @apply_defaults
      def __init__(self, project, zone, instance, disk, *args, **kwargs):
        self.compute = self.get_compute_api_client()
        self.project = project
        self.zone = zone
        self.instance = instance
        self.disk = disk
        super(SnapshotDiskOperator, self).__init__(*args, **kwargs)
    
      def get_compute_api_client(self):
        credentials = GoogleCredentials.get_application_default()
        return googleapiclient.discovery.build(
            'compute', 'v1', cache_discovery=False, credentials=credentials)
    
      def generate_snapshot_name(self, instance):
        # Snapshot name must match regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)'
        return ('' + self.instance + '-' +
                datetime.datetime.now().strftime('%Y-%m-%d-%H%M%S'))
    
      def execute(self, context):
        snapshot_name = self.generate_snapshot_name(self.instance)
        logging.info(
            ("Creating snapshot '%s' from: {disk=%s, instance=%s, project=%s, "
             "zone=%s}"),
            snapshot_name, self.disk, self.instance, self.project, self.zone)
        self.compute.disks().createSnapshot(
            project=self.project, zone=self.zone, disk=self.disk,
            body={'name': snapshot_name}).execute()
        time.sleep(120)

    A classe SnapshotDiskOperator tem os seguintes métodos:

    • __init__: o construtor da classe. Parecido com o construtor na classe StopInstanceOperator, mas além do nome do projeto, da zona e da instância, esse construtor recebe o nome do disco a partir do qual o snapshot será criado. Isso ocorre porque uma instância pode ter mais de um disco permanente anexado a ela.
    • generate_snapshot_name: este método de amostra cria um nome exclusivo simples para cada snapshot usando o nome da instância, a data e a hora com granularidade de um segundo. Ajuste o nome de acordo com suas necessidades, por exemplo: adicionando o nome do disco quando vários discos estiverem conectados a uma instância ou aumentando a granularidade de tempo para oferecer suporte a solicitações de criação de snapshots específicos.
    • execute: o método do operador principal modificado por BaseOperator. Quando o worker do Airflow o executa, ele gera um nome de snapshot usando o método generate_snapshot_name. Em seguida, ele imprime uma mensagem informativa e chama a API Compute Engine para criar o snapshot com os parâmetros recebidos no construtor.

    Iniciar a instância do Compute Engine

    Nesta seção, você cria o terceiro e último operador personalizado, StartInstanceOperator. Esse operador reinicia uma instância do Compute Engine.

    No arquivo gce_commands_plugin.py que você abriu anteriormente, observe a classe SnapshotDiskOperator na parte inferior do arquivo:

    class StartInstanceOperator(BaseOperator):
      """Starts a virtual machine instance."""
    
      @apply_defaults
      def __init__(self, project, zone, instance, *args, **kwargs):
        self.compute = self.get_compute_api_client()
        self.project = project
        self.zone = zone
        self.instance = instance
        super(StartInstanceOperator, self).__init__(*args, **kwargs)
    
      def get_compute_api_client(self):
        credentials = GoogleCredentials.get_application_default()
        return googleapiclient.discovery.build(
            'compute', 'v1', cache_discovery=False, credentials=credentials)
    
      def execute(self, context):
        logging.info('Starting instance %s in project %s and zone %s',
                     self.instance, self.project, self.zone)
        self.compute.instances().start(
            project=self.project, zone=self.zone, instance=self.instance).execute()
        time.sleep(20)

    A classe StartInstanceOperator tem os seguintes métodos:

    • __init__: o construtor da classe. Parecido com o construtor na classe StopInstanceOperator.
    • execute: o método do operador principal modificado por BaseOperator. A diferença em relação aos operadores anteriores é a invocação da API Compute Engine adequada para iniciar a instância indicada nos parâmetros de entrada do construtor.

    Como definir o fluxo de trabalho do Airflow

    Anteriormente, você definiu um plug-in do Airflow contendo três operadores. Esses operadores definem as tarefas que fazem parte de um fluxo de trabalho do Airflow. O fluxo de trabalho apresentado aqui é simples e linear, mas os fluxos de trabalho do Airflow podem ser grafos acíclicos direcionados complexos.

    Nesta seção, criamos a classe de plug-in que expõe os três operadores, cria o DAG usando esses operadores, implanta-o no Cloud Composer e executa-o.

    Criar o plugin

    Até o momento, o arquivo gce_commands_plugin.py inclui os operadores start, snapshot e stop. Para usar esses operadores em um fluxo de trabalho, é preciso incluí-los em uma classe de plug-in.

    1. Observe a classe GoogleComputeEnginePlugin na parte inferior do arquivo gce_commands_plugin.py:

      class GoogleComputeEnginePlugin(AirflowPlugin):
        """Expose Airflow operators."""
      
        name = 'gce_commands_plugin'
        operators = [StopInstanceOperator, SnapshotDiskOperator,
                     StartInstanceOperator]

      Essa classe, herdada de AirflowPlugin, dá ao plug-in o nome interno gce_commands_plugin e adiciona os três operadores a ele.

    2. Feche o arquivo gce_commands_plugin.py.

    Configurar o grafo acíclico dirigido

    O DAG define o fluxo de trabalho que o Airflow executa. Para que o DAG saiba de qual disco fazer backup, é necessário definir algumas variáveis: em qual instância do Compute Engine o disco está conectado, a zona em que a instância está sendo executada e o projeto em que todos os recursos estão disponíveis.

    Seria possível codificar essas variáveis no próprio código-fonte do DAG, mas recomenda-se defini-las como variáveis do Airflow. Dessa forma, qualquer alteração de configuração pode ser gerenciada de maneira centralizada e independente das implantações de código.

    Defina a configuração do DAG:

    1. No Cloud Shell, defina a localização do seu ambiente do Cloud Composer:

      LOCATION=[CLOUD_ENV_LOCATION]
      

      O local é a região do Compute Engine em que o ambiente do Cloud Composer está localizado, por exemplo: us-central1 ou europe-west1. Ele foi definido no momento da criação do ambiente e está disponível na página do console do Cloud Composer.

    2. Defina o nome do ambiente do Cloud Composer:

      ENVIRONMENT=$(gcloud composer environments list \
          --format="value(name)" --locations $LOCATION)
      

      O parâmetro --format é usado para selecionar apenas a coluna name da tabela resultante. Suponha que apenas um ambiente foi criado.

    3. Crie a variável PROJECT no Airflow usando o nome do projeto atual do Google Cloud:

      gcloud composer environments run $ENVIRONMENT --location $LOCATION \
          variables -- --set PROJECT $(gcloud config get-value project)
      

      Onde:

      • gcloud composer environments run é usado para executar comandos da CLI do Airflow.
      • O comando variables do Airflow define a variável PROJECT do Airflow como o valor retornado por gcloud config
    4. Crie a variável INSTANCE no Airflow com o nome da instância do WordPress:

      gcloud composer environments run $ENVIRONMENT --location $LOCATION \
          variables -- --set INSTANCE \
          $(gcloud compute instances list \
          --format="value(name)" --filter="name~'.*wordpress.*'")
      

      Esse comando usa o parâmetro --filter para selecionar apenas a instância cujo name corresponde a uma expressão regular que contém a string wordpress. Essa abordagem pressupõe que haja apenas uma instância desse tipo e que sua instância e disco tenham "wordpress" como parte do nome, o que acontece quando você aceita os padrões.

    5. Crie a variável ZONE no Airflow usando a zona da instância do WordPress:

      gcloud composer environments run $ENVIRONMENT --location $LOCATION \
          variables -- --set ZONE \
          $(gcloud compute instances list \
          --format="value(zone)" --filter="name~'.*wordpress.*'")
      
    6. Crie a variável DISK no Airflow com o nome do disco permanente anexado à instância do WordPress:

      gcloud composer environments run $ENVIRONMENT --location $LOCATION \
          variables -- --set DISK \
          $(gcloud compute disks list \
          --format="value(name)" --filter="name~'.*wordpress.*'")
      
    7. Verifique se as variáveis do Airflow foram criadas corretamente:

      1. No Console do Cloud, acesse a página do Cloud Composer.

        Ir para a página do Cloud Composer

      2. Na coluna do servidor da Web do Airflow, clique no link Airflow. Será aberta uma nova guia mostrando a página principal do servidor da Web do Airflow.

      3. Clique em Admin e depois em Variables.

        A lista mostra as variáveis de configuração do DAG.

        Variáveis de configuração do DAG

    Criar o grafo acíclico dirigido

    A definição do DAG fica em um arquivo dedicado do Python. Seu próximo passo é criar o DAG, encadeando os três operadores do plug-in.

    1. No Cloud Shell, use um editor de texto, como nano ou vim, para abrir o arquivo backup_vm_instance.py:

      vi $HOME/composer-infra-python/no_sensor/dags/backup_vm_instance.py
      
    2. Examine as importações na parte superior do arquivo:

      import datetime
      from airflow import DAG
      from airflow.models import Variable
      from airflow.operators import SnapshotDiskOperator
      from airflow.operators import StartInstanceOperator
      from airflow.operators import StopInstanceOperator
      from airflow.operators.dummy_operator import DummyOperator

      Resumindo essas importações:

      • DAG é a classe de grafo acíclico dirigido definida pelo Airflow.
      • DummyOperator é usado para criar os operadores do início e fim do ambiente autônomo para melhorar a visualização do fluxo de trabalho. Em DAGs mais complexos, DummyOperator pode ser usado para mesclar ramificações e criar SubDAGs.
      • O DAG usa os três operadores que você definiu nas seções anteriores.
    3. Defina os valores dos parâmetros que serão transmitidos aos construtores do operador:

      INTERVAL = '@daily'
      START_DATE = datetime.datetime(2018, 7, 16)
      PROJECT = Variable.get('PROJECT')
      ZONE = Variable.get('ZONE')
      INSTANCE = Variable.get('INSTANCE')
      DISK = Variable.get('DISK')

      Onde:

      • INTERVAL define com que frequência o fluxo de trabalho de backup é executado. O código anterior especifica uma recorrência diária usando uma predefinição cron do Airflow. Se você quiser usar um intervalo diferente, consulte a página de referência de execuções do DAG. Também é possível acionar o fluxo de trabalho manualmente, não importa qual seja a programação;
      • START_DATE define o momento em que os backups estão programados para começar. Não é necessário alterar este valor;
      • os demais valores são recuperados das variáveis do Airflow que você configurou na seção anterior.
    4. Use o código a seguir para criar o DAG com alguns dos parâmetros definidos anteriormente. Esse código também fornece ao DAG um nome e uma descrição, que são mostrados na IU do Cloud Composer.

      dag1 = DAG('backup_vm_instance',
                 description='Backup a Compute Engine instance using an Airflow DAG',
                 schedule_interval=INTERVAL,
                 start_date=START_DATE,
                 catchup=False)
    5. Preencha o DAG com tarefas, que são instâncias do operador:

      ## Dummy tasks
      begin = DummyOperator(task_id='begin', retries=1, dag=dag1)
      end = DummyOperator(task_id='end', retries=1)
      
      ## Compute Engine tasks
      stop_instance = StopInstanceOperator(
          project=PROJECT, zone=ZONE, instance=INSTANCE, task_id='stop_instance')
      snapshot_disk = SnapshotDiskOperator(
          project=PROJECT, zone=ZONE, instance=INSTANCE,
          disk=DISK, task_id='snapshot_disk')
      start_instance = StartInstanceOperator(
          project=PROJECT, zone=ZONE, instance=INSTANCE, task_id='start_instance')

      Esse código instancia todas as tarefas necessárias para o fluxo de trabalho, transmitindo os parâmetros definidos para os construtores do operador correspondente.

      • Os valores task_id são os códigos exclusivos que serão mostrados na IU do Cloud Composer. Use esses códigos posteriormente para transmitir dados entre tarefas.
      • retries define o número de vezes que uma tarefa é repetida antes de falhar. Para tarefas DummyOperator, esses valores são ignorados.
      • dag=dag indica que uma tarefa está anexada ao DAG criado anteriormente. Esse parâmetro só é necessário na primeira tarefa do fluxo de trabalho.
    6. Defina a sequência de tarefas que compõem o DAG do fluxo de trabalho:

      # Airflow DAG definition
      begin >> stop_instance >> snapshot_disk >> start_instance >> end
      
    7. Feche o arquivo gce_commands_plugin.py.

    Executar o fluxo de trabalho

    O fluxo de trabalho representado pelo operador DAG agora está pronto para ser executado pelo Cloud Composer. O Cloud Composer lê as definições do DAG e do plug-in de um bucket associado do Cloud Storage. Esse bucket e os diretórios dags e plugins correspondentes foram criados automaticamente quando você criou o ambiente do Cloud Composer.

    Usando o Cloud Shell, é possível copiar o DAG e o plug-in no bucket do Cloud Storage associado:

    1. No Cloud Shell, veja o nome do bucket:

      BUCKET=$(gsutil ls)
      echo $BUCKET
      

      Deve haver um único bucket com um nome do formulário: gs://[REGION]-{ENVIRONMENT_NAME]-{ID}-bucket/.

    2. Execute o script abaixo para copiar os arquivos do DAG e do plug-in nos diretórios de buckets correspondentes:

      gsutil cp $HOME/composer-infra-python/no_sensor/plugins/gce_commands_plugin.py "$BUCKET"plugins
      gsutil cp $HOME/composer-infra-python/no_sensor/dags/backup_vm_instance.py "$BUCKET"dags
      

      O nome do bucket já inclui uma barra à direita, portanto, as aspas duplas ao redor da variável $BUCKET.

    3. No Console do Cloud, acesse a página do Cloud Composer.

      Ir para a página do Cloud Composer

    4. Na coluna do servidor da Web do Airflow, clique no link Airflow. Será aberta uma nova guia mostrando a página principal do servidor da Web do Airflow. Aguarde dois a três minutos e atualize a página. Pode ser necessário esperar e atualizar algumas vezes para que a página fique pronta.

      Uma lista com o DAG recém-criado, semelhante à lista abaixo, será exibida:

      Lista de DAGs

      Se houver erros de sintaxe no código, uma mensagem será exibida na parte superior da tabela do DAG. Se houver erros de ambiente de execução, eles serão marcados em DAG Runs. Corrija todos os erros antes de continuar. A maneira mais fácil de fazer isso é copiando novamente os arquivos do repositório do GitHub para o bucket.

    5. Para ver um rastreamento de pilha mais detalhado, execute o comando a seguir no Cloud Shell:

      gcloud composer environments run $ENVIRONMENT --location $LOCATION list_dags
      
    6. O Airflow começa a executar o fluxo de trabalho imediatamente, mostrado abaixo da coluna Dag Runs.

      O fluxo de trabalho já está em andamento, mas se você precisar executá-lo novamente, poderá acioná-lo manualmente com as seguintes etapas:

      1. Na coluna Links, clique no primeiro ícone, Trigger Dag, marcado com uma seta na captura de tela anterior.
      2. No pop-up de confirmação Are you sure?, clique em OK.

        Em alguns segundos, o fluxo de trabalho é iniciado e uma nova execução aparece como um círculo verde claro em DAG Runs.

    7. Na coluna Links, clique no ícone de visualização de grafo, marcado com uma seta na captura de tela anterior.

      Captura de tela do Cloud Composer

      A Visualização de grafo mostra o fluxo de trabalho, as tarefas executadas com sucesso com uma borda verde escura, a tarefa em execução com uma borda verde clara e as tarefas pendentes sem borda. Clique na tarefa para visualizar registros, ver detalhes e executar outras operações.

    8. Para acompanhar a execução, clique periodicamente no botão de atualização no canto superior direito.

      Parabéns! Você concluiu sua primeira execução de fluxo de trabalho do Cloud Composer. Quando o fluxo de trabalho termina, ele cria um instantâneo do disco permanente da instância do Compute Engine.

    9. No Cloud Shell, verifique se o snapshot foi criado:

      gcloud compute snapshots list
      

      Como alternativa, use o menu do Console do Cloud para acessar a página Snapshots do Compute Engine.

      Página

    Um snapshot estará visível neste momento. As execuções subsequentes do fluxo de trabalho, acionadas de forma manual ou automática seguindo a programação especificada, criarão outros snapshots.

    Snapshots são graduais. O primeiro instantâneo é o maior, porque contém todos os blocos do disco permanente em formato compactado. Os instantâneos sucessivos contêm apenas os blocos que foram alterados a partir do instantâneo anterior e quaisquer referências aos blocos inalterados. Assim, os instantâneos subsequentes são menores que o primeiro, levam menos tempo para serem produzidos e custam menos.

    Se um instantâneo for excluído, os dados dele serão movidos para o próximo instantâneo correspondente para manter a consistência de deltas consecutivos armazenados na rede de instantâneos. Quando todos os instantâneos são removidos, o mesmo ocorre com todos os dados de backup do disco permanente.

    Como criar o sensor personalizado do Airflow

    Ao executar o fluxo de trabalho, você deve ter notado que leva algum tempo para concluir cada etapa. Essa espera ocorre porque os operadores incluem uma instrução sleep() no final para dar tempo para a API Compute Engine concluir o trabalho antes de iniciar a próxima tarefa.

    No entanto, essa abordagem não é ideal e pode causar problemas inesperados. Por exemplo, durante a criação de instantâneos, o tempo de espera pode ser muito longo para instantâneos incrementais, o que significa que você está perdendo tempo esperando por uma tarefa que já terminou. Ou o tempo de espera pode ser muito curto. Isso pode causar a falha de todo o fluxo de trabalho ou produzir resultados não confiáveis porque a instância não está totalmente parada ou o processo de instantâneos não é feito quando o computador é iniciado.

    É necessário ser capaz de dizer à próxima tarefa que a tarefa anterior foi feita. Uma solução é usar os sensores do Airflow, que pausam o fluxo de trabalho até que alguns critérios sejam atendidos. Nesse caso, o critério é a conclusão da operação anterior do Compute Engine.

    Compartilhar dados de comunicação cruzada entre tarefas

    Quando as tarefas precisam se comunicar umas com as outras, o Airflow fornece um mecanismo conhecido como XCom, ou "comunicação cruzada". O XCom permite que as tarefas troquem mensagens compostas por uma chave, um valor e um carimbo de data/hora.

    A maneira mais simples de transmitir uma mensagem usando XCom é um operador retornar um valor do método execute(). O valor pode ser qualquer objeto que o Python possa serializar usando o módulo pickle.

    Os três operadores descritos nas seções anteriores chamam a API Compute Engine. Todas essas chamadas de API retornam um objeto Recurso de operação. Esses objetos devem ser usados para gerenciar solicitações assíncronas, como as dos operadores do Airflow. Cada objeto tem um campo name que pode ser usado para pesquisar o estado mais recente da operação do Compute Engine.

    Modifique os operadores para retornar o name do objeto de recurso de operação:

    1. No Cloud Shell, use um editor de texto, como nano ou vim, para abrir o arquivo gce_commands_plugin.py, desta vez no diretório sensor/plugins:

      vi $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py
      
    2. No método execute do StopInstanceOperator, observe como o código a seguir:

      self.compute.instances().stop(
          project=self.project, zone=self.zone, instance=self.instance).execute()
      time.sleep(90)

      foi substituído por este código:

      operation = self.compute.instances().stop(
          project=self.project, zone=self.zone, instance=self.instance).execute()
      return operation['name']

      Onde:

      • A primeira linha captura o valor de retorno da chamada de API na variável operation.
      • A segunda linha retorna o campo name da operação do método execute(). Essa instrução serializa o nome usando pickle e o coloca no espaço compartilhado dentro da tarefa XCom. O valor será extraído mais tarde pela ordem "last-in, first-out" (último a entrar, primeiro a sair).

      Se uma tarefa precisar enviar vários valores, é possível dar ao XCom um key explícito chamando xcom_push() diretamente, em vez de retornar o valor.

    3. Da mesma forma, no método execute do SnapshotDiskOperator, observe como o código a seguir:

      self.compute.disks().createSnapshot(
          project=self.project, zone=self.zone, disk=self.disk,
          body={'name': snapshot_name}).execute()
      time.sleep(120)

      foi substituído por este código:

      operation = self.compute.disks().createSnapshot(
          project=self.project, zone=self.zone, disk=self.disk,
          body={'name': snapshot_name}).execute()
      return operation['name']

      Existem dois nomes não relacionados neste código. O primeiro refere-se ao nome do snapshot e o segundo é o nome da operação.

    4. Por fim, no método execute do StartInstanceOperator, observe como o código a seguir:

      self.compute.instances().start(
          project=self.project, zone=self.zone, instance=self.instance).execute()
      time.sleep(20)

      foi substituído por este código:

      operation = self.compute.instances().start(
          project=self.project, zone=self.zone, instance=self.instance).execute()
      return operation['name']
    5. Neste ponto, não deve haver chamadas para o método sleep() em todo o arquivo gce_commands_plugin.py. Verifique se esse é o caso pesquisando sleep no arquivo. Caso contrário, confira novamente as etapas anteriores desta seção.

      Como nenhuma chamada para sleep() é feita a partir do código, a linha a seguir foi removida da seção de importações na parte superior do arquivo:

      import time
      
    6. Feche o arquivo gce_commands_plugin.py.

    Implementar e expor o sensor

    Na seção anterior, você modificou cada operador para retornar um nome de operação do Compute Engine. Nesta seção, usando o nome da operação, você cria um sensor de Airflow para pesquisar a API Compute Engine para a conclusão de cada operação.

    1. No Cloud Shell, use um editor de texto, como nano ou vim, para abrir o arquivo gce_commands_plugin.py, lembrando de usar o diretório sensor/plugins:

      vi $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py
      

      Observe a seguinte linha de código na parte superior da seção de importação, logo abaixo da linha from airflow.models import BaseOperator:

      from airflow.operators.sensors import BaseSensorOperator
      

      Todos os sensores são derivados da classe BaseSensorOperator e precisam modificar o método poke().

    2. Examine a nova classe OperationStatusSensor:

      class OperationStatusSensor(BaseSensorOperator):
        """Waits for a Compute Engine operation to complete."""
      
        @apply_defaults
        def __init__(self, project, zone, instance, prior_task_id, *args, **kwargs):
          self.compute = self.get_compute_api_client()
          self.project = project
          self.zone = zone
          self.instance = instance
          self.prior_task_id = prior_task_id
          super(OperationStatusSensor, self).__init__(*args, **kwargs)
      
        def get_compute_api_client(self):
          credentials = GoogleCredentials.get_application_default()
          return googleapiclient.discovery.build(
              'compute', 'v1', cache_discovery=False, credentials=credentials)
      
        def poke(self, context):
          operation_name = context['task_instance'].xcom_pull(
              task_ids=self.prior_task_id)
          result = self.compute.zoneOperations().get(
              project=self.project, zone=self.zone,
              operation=operation_name).execute()
      
          logging.info(
              "Task '%s' current status: '%s'", self.prior_task_id, result['status'])
          if result['status'] == 'DONE':
            return True
          else:
            logging.info("Waiting for task '%s' to complete", self.prior_task_id)
            return False

      A classe OperationStatusSensor tem os seguintes métodos:

      • __init__: o construtor da classe. Esse construtor usa parâmetros semelhantes aos dos operadores, com uma exceção: prior_task_id. Este parâmetro é o código da tarefa anterior.
      • poke: o método do sensor principal modificado por BaseSensorOperator. O Airflow chama esse método a cada 60 segundos até que o método retorne True. Somente nesse caso, as tarefas posteriores poderão ser executadas.

        Configure o intervalo para essas novas tentativas passando o parâmetro poke_interval para o construtor. Também é possível definir um timeout. Para mais informações, consulte a referência da API BaseSensorOperator.

        Na implementação do método poke anterior, a primeira linha é uma chamada para xcom_pull(). Esse método obtém o valor XCom mais recente para a tarefa identificada por prior_task_id. O valor é o nome de uma operação do Compute Engine e é armazenado na variável operation_name.

        Em seguida, o código executa o método zoneOperations.get(), passando operation_name como um parâmetro para receber o status mais recente da operação. Se o status for DONE, o método poke() retornará True. Caso contrário, False. No primeiro caso, as tarefas posteriores serão iniciadas; No último caso, a execução do fluxo de trabalho permanece pausada, e o método poke() é chamado novamente após poke_interval segundos.

    3. Na parte inferior do arquivo, observe como a classe GoogleComputeEnginePlugin foi atualizada para adicionar OperationStatusSensor à lista de operadores exportados pelo plug-in:

      class GoogleComputeEnginePlugin(AirflowPlugin):
        """Expose Airflow operators and sensor."""
      
        name = 'gce_commands_plugin'
        operators = [StopInstanceOperator, SnapshotDiskOperator,
                     StartInstanceOperator, OperationStatusSensor]
    4. Feche o arquivo gce_commands_plugin.py.

    Atualizar o fluxo de trabalho

    Depois de criar o sensor no plug-in, será possível adicioná-lo ao fluxo de trabalho. Nesta seção, você atualiza o fluxo de trabalho para o estado final, que inclui todos os três operadores mais as tarefas intermediárias do sensor. Em seguida, você executa e verifica o fluxo de trabalho atualizado.

    1. No Cloud Shell, use um editor de texto, como nano ou vim, para abrir o arquivo backup_vm_instance.py, desta vez no diretório sensor/dags:

      vi $HOME/composer-infra-python/sensor/dags/backup_vm_instance.py
      
      
    2. Na seção de importações, observe que o sensor recém-criado é importado abaixo da linha from airflow operators import StartInstanceOperator:

      from airflow.operators import OperationStatusSensor
      
    3. Examine as linhas após o comentário ## Wait tasks

      ## Wait tasks
      wait_for_stop = OperationStatusSensor(
          project=PROJECT, zone=ZONE, instance=INSTANCE,
          prior_task_id='stop_instance', poke_interval=15, task_id='wait_for_stop')
      wait_for_snapshot = OperationStatusSensor(
          project=PROJECT, zone=ZONE, instance=INSTANCE,
          prior_task_id='snapshot_disk', poke_interval=10,
          task_id='wait_for_snapshot')
      wait_for_start = OperationStatusSensor(
          project=PROJECT, zone=ZONE, instance=INSTANCE,
          prior_task_id='start_instance', poke_interval=5, task_id='wait_for_start')

      O código reutiliza OperationStatusSensor para definir três "tarefas de espera" intermediárias. Cada uma dessas tarefas aguarda a conclusão da operação anterior. Os seguintes parâmetros são transmitidos para o construtor do sensor:

      • PROJECT, ZONE e INSTANCE da instância do WordPress, já definidos no arquivo.
      • prior_task_id: o código da tarefa que o sensor está aguardando. Por exemplo, a tarefa wait_for_stop aguarda a conclusão da tarefa com código stop_instance.

      • poke_interval: o número de segundos que o Airflow precisa aguardar entre as novas tentativas de chamada para o método poke() do sensor. Em outras palavras, a frequência para verificar se prior_task_id já foi concluído.

      • task_id: o código da tarefa de espera recém-criada.

    4. Na parte inferior do arquivo, observe como o código a seguir:

      begin >> stop_instance >> snapshot_disk >> start_instance >> end
      

      foi substituído por este código:

      begin >> stop_instance >> wait_for_stop >> snapshot_disk >> wait_for_snapshot \
              >> start_instance >> wait_for_start >> end
      

      Essas linhas definem o fluxo de trabalho de backup completo.

    5. Feche o arquivo backup_vm_instance.py.

    Agora, copie o DAG e o plug-in do bucket do Cloud Storage associado:

    1. No Cloud Shell, veja o nome do bucket:

      BUCKET=$(gsutil ls)
      echo $BUCKET
      

      Você verá um único bucket com um nome no formato: gs://[REGION]-[ENVIRONMENT_NAME]-[ID]-bucket/.

    2. Execute o script abaixo para copiar os arquivos do DAG e do plug-in nos diretórios de buckets correspondentes:

      gsutil cp $HOME/composer-infra-python/sensor/plugins/gce_commands_plugin.py "$BUCKET"plugins
      gsutil cp $HOME/composer-infra-python/sensor/dags/backup_vm_instance.py "$BUCKET"dags
      

      O nome do bucket já inclui uma barra à direita. Portanto, as aspas duplas ao redor da variável $BUCKET

    3. Faça upload do fluxo de trabalho atualizado no Airflow:

      1. No Console do Cloud, acesse a página do Cloud Composer.

        Ir para a página do Cloud Composer

      2. Na coluna do Airflow, clique no link servidor da Web Airflow para exibir a página principal.

      3. Aguarde dois ou três minutos até que o Airflow atualize automaticamente o plug-in e o fluxo de trabalho. Você pode observar a tabela do DAG se esvaziando momentaneamente. Atualize a página algumas vezes até que a seção Links apareça de forma consistente.

      4. Verifique se não há nenhum erro e, na seção Links, clique em Tree View.

        Captura de tela da página À esquerda, o fluxo de trabalho é representado como uma árvore de baixo para cima. À direita, um grafo da tarefa é executado para datas diferentes. Um quadrado verde significa uma execução bem-sucedida para essa tarefa e data específicas. Um quadrado branco representa uma tarefa que nunca foi executada. Como você atualizou o DAG com novas tarefas do sensor, todas essas tarefas são mostradas em branco, enquanto as tarefas do Compute Engine são exibidas em verde.

      5. Execute o fluxo de trabalho de backup atualizado:

        1. No menu superior, clique em DAGs para voltar à página principal.
        2. Na coluna Links, clique em Trigger DAG.
        3. No pop-up de confirmação Are you sure?, clique em OK. A execução de um novo fluxo de trabalho é iniciada, aparecendo como um círculo verde claro na coluna DAG Runs.
      6. Em Links, clique no ícone Graph View para observar a execução do fluxo de trabalho em tempo real.

      7. Clique no botão de atualização no lado direito para seguir a execução da tarefa. Observe como o fluxo de trabalho para em cada uma das tarefas do sensor para aguardar a conclusão da tarefa anterior. O tempo de espera é ajustado de acordo com as necessidades de cada tarefa, em vez de depender de um valor de suspensão codificado.

      Captura de tela da execução da tarefa do Cloud Composer

    4. Como opção, durante o fluxo de trabalho, volte para o Console do Cloud, selecione o menu Compute Engine e clique em Instâncias de VM para ver como a máquina virtual é interrompida e reiniciada. Também é possível clicar em Snapshots para ver o novo instantâneo sendo criado.

    Agora você executou um fluxo de trabalho de backup que cria um instantâneo a partir de uma instância do Compute Engine. Esse instantâneo segue as práticas recomendadas e otimiza o fluxo com sensores.

    Como restaurar uma instância de um instantâneo

    Ter um instantâneo disponível é apenas parte da história de backup. A outra parte é poder restaurar sua instância a partir do instantâneo.

    Para criar uma instância usando um instantâneo:

    1. No Cloud Shell, veja uma lista dos instantâneos disponíveis:

      gcloud compute snapshots list
      

      A saída é semelhante a esta:

      NAME                              DISK_SIZE_GB  SRC_DISK                            STATUS
      wordpress-1-vm-2018-07-18-120044  10            us-central1-c/disks/wordpress-1-vm  READY
      wordpress-1-vm-2018-07-18-120749  10            us-central1-c/disks/wordpress-1-vm  READY
      wordpress-1-vm-2018-07-18-125138  10            us-central1-c/disks/wordpress-1-vm  READY
      
    2. Selecione um instantâneo e crie um disco permanente de inicialização autônomo a partir dele. Substitua os marcadores entre colchetes pelos seus próprios valores.

      gcloud compute disks create [DISK_NAME] --source-snapshot [SNAPSHOT_NAME] \
          --zone=[ZONE]
      

      Onde:

      • DISK_NAME é o nome do novo disco permanente de inicialização autônomo;
      • SNAPSHOT_NAME é o snapshot selecionado da primeira coluna da saída anterior;
      • ZONE é a zona do Compute na qual o novo disco será criado.
    3. Crie uma nova instância usando o disco de inicialização. Substitua [INSTANCE_NAME] pelo nome da instância que você quer criar.

      gcloud compute instances create [INSTANCE_NAME] --disk name=[DISK_NAME],boot=yes \
          --zone=ZONE --tags=wordpress-1-tcp-443,wordpress-1-tcp-80
      

      Com as duas tags especificadas no comando, a instância é automaticamente autorizada a receber tráfego de entrada nas portas 443 e 80 devido às regras de firewall que foram criadas para a instância inicial do WordPress.

      Anote o IP externo da nova instância retornado pelo comando anterior.

    4. Verifique se o WordPress está sendo executado na instância recém-criada. Em uma nova guia do navegador, navegue até o endereço IP externo. A página de destino padrão do WordPress será mostrada.

    5. Como alternativa, crie uma instância usando um snapshot do console:

      1. No Console do Cloud, acesse a página Snapshots:

        IR PARA A PÁGINA "SNAPSHOTS"

      2. Clique no instantâneo mais recente.

      3. Clique em Criar instância.

      4. No formulário Nova instância de VM, clique em Gerenciamento, segurança, discos, rede, locatário único e, em seguida, Rede.

      5. Adicione wordpress-1-tcp-443 e wordpress-1-tcp-80 ao campo Tags de rede, pressionando Enter após cada tag. Veja acima uma explicação dessas tags.

      6. Clique em Criar.

        Uma nova instância baseada no snapshot mais recente é criada e está pronta para exibir o conteúdo.

    6. Abra a página de instâncias do Compute Engine e anote o IP externo da nova instância.

    7. Verifique se o WordPress está sendo executado na instância recém-criada. Navegue até o IP externo em uma nova guia do navegador.

    Para mais detalhes, consulte Como criar uma instância a partir de um snapshot.

    Como fazer a limpeza

    1. No Console do Cloud, acesse a página Gerenciar recursos:

      Acessar a página Gerenciar recursos

    2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
    3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

    A seguir