Como executar outras tarefas com as instâncias

Estas são outras tarefas que podem ser executadas com as instâncias.

Antes de começar

Copiar arquivos entre uma instância e um computador local

Use gcloud compute scp para transferir arquivos entre uma instância do Linux e um computador local:

gcloud compute scp my-instance:~/file-1 \
    my-instance:~/file-2 \
    ~/local-dir

Para copiar arquivos da máquina local para a instância, execute:

gcloud compute scp ~/local-dir/file-1 \
    my-instance:~/remote-destination

Detectar se o Compute Engine é o ambiente em execução

Nos sistemas, é comum a necessidade de detectar em qual ambiente de nuvem específico você está executando. Use as instruções a seguir para detectar se o ambiente em execução é o Compute Engine.

Usar o servidor de metadados

Com o servidor de metadados, é fácil detectar se os aplicativos ou scripts estão sendo executados dentro de uma instância do Compute Engine. Quando você envia uma solicitação para o servidor, qualquer resposta de metadados dele contém o cabeçalho Metadata-Flavor: Google. Verifique este cabeçalho para detectar com segurança se a execução está sendo feita no Compute Engine.

Por exemplo, a seguinte solicitação curl retorna um cabeçalho Metadata-Flavor: Google, indicando que ela foi enviada de uma instância do Compute Engine.


me@my-inst:~$ curl metadata.google.internal -i


HTTP/1.1 200 OK
Metadata-Flavor: Google
Content-Type: application/text
Date: Thu, 10 Apr 2014 19:24:27 GMT
Server: Metadata Server for VM
Content-Length: 22
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

0.1/

computeMetadata/

Usar outros métodos

Linux

Para instâncias do Linux, a ferramenta dmidecode pode ser usada para acessar as informações de DMI/SMBIOS diretamente em /proc/mem. Execute o comando a seguir para que a ferramenta dmidecode imprima "Google Compute Engine" como meio de indicar que você está no Google Compute Engine:

my@myinst:~$ sudo dmidecode -s system-product-name | grep "Google Compute Engine"
Google Compute Engine

Windows

Nas instâncias do Windows, "Google" é listado como fabricante e modelo do sistema. Use utilitários, como o msinfo32.exe, para pesquisar essas informações. Por exemplo, o msinfo32 exibe o seguinte:

Tela do msinfo32 exibindo o Google como fabricante e modelo (clique para ampliar)
Tela do msinfo32 exibindo o Google como fabricante e modelo (clique para ampliar)

Se precisar determinar essas informações de modo programático em uma instância do Windows, crie um aplicativo de Instrumentação de Gerenciamento do Windows (WMI, na sigla em inglês) com algumas modificações(ambos em inglês).

Como processar as falhas nas instâncias

Infelizmente, as instâncias individuais podem apresentar falhas. Isso pode acontecer por várias razões, incluindo interrupções inesperadas, erro de hardware ou outras falhas de sistema. Para diminuir o impacto causado por essas ocorrências, use discos permanentes e faça o backup dos dados regularmente.

Quando ocorre uma falha na instância, ela é reiniciada automaticamente, com as mesmas configurações de disco permanente raiz, metadados e instâncias. Para controlar o comportamento de reinicialização automática de uma instância, consulte Como configurar opções de programação.

Em geral, é recomendável que se projete um sistema robusto o suficiente para que a falha de uma única instância não seja catastrófica para o aplicativo. Para mais informações, consulte Projetar sistemas robustos.

Identificar uma instância por meio do UUID

Cada máquina virtual tem um identificador único universal (UUID, na sigla em inglês) que, no caso das imagens do Linux, pode ser acessado por meio da ferramenta dmidecode. Um UUID é calculado a partir do ID, zona e nome da instância do projeto da máquina virtual. O UUID de uma instância é único entre as máquinas virtuais do Compute Engine e estável durante todo o tempo de vida da instância. Ele permanece após as reinicializações da máquina virtual. Quando ela é excluída e recriada no mesmo projeto e zona, com o mesmo nome de instância, o UUID também é o mesmo.

Para procurar o UUID de uma instância em uma instância do Linux, execute o seguinte comando na máquina virtual:

me@myinst:~$ sudo dmidecode -t system | grep UUID

A ferramenta imprimirá uma resposta semelhante a esta:

  UUID: FE0C672D-324F-25F1-052C-6C50FA8B7397

Instalar pacotes e configurar uma instância

O criador de instâncias tem privilégios de administrador em todas as instâncias que ele adicionou ao projeto e está automaticamente na lista do SUDO.

Após fazer login em uma instância como administrador, instale os pacotes e configure a instância da mesma maneira que em um computador com Linux normal. Por exemplo, instale o Apache, conforme mostrado aqui:


user@myinst:~$ sudo apt-get update && sudo apt-get install apache2
Reading package lists... Done

Building dependency tree
Reading state information... Done
The following extra packages will be installed:

[...]

Mova os arquivos entre o computador local e a instância usando gcloud compute scp, conforme descrito em Como copiar arquivos entre uma instância e o computador local .

Observe que a máquina precisa acessar a Internet para executar o apt-get. Isso significa que é necessário um endereço IP externo ou acesso a um proxy de Internet.

No Compute Engine, como parte de um evento de manutenção de infraestrutura pendente, um atributo especial no servidor de metadados de uma máquina virtual é alterado pouco antes de qualquer tentativa de migração em tempo real ou encerramento e reinicialização dessa máquina. O atributo maintenance-event é atualizado antes e depois de um evento, o que permite detectar a iminência desses eventos. Use essas informações para automatizar todos os scripts ou comandos que quiser executar antes e/ou depois do evento.

Para mais informações, consulte a seção Aviso de manutenção transparente na página de documentação do Servidor de metadados.

Listar todas as instâncias

Para ver uma lista com todas as instâncias de um projeto, chame instances list:

gcloud compute instances list
NAME               ZONE          MACHINE_TYPE  INTERNAL_IP    EXTERNAL_IP     STATUS
example-instance   us-central1-a n1-standard-1 10.105.155.92  173.255.114.53  RUNNING
example-instance-2 us-central1-a n1-standard-1 10.181.215.203 146.148.32.59   RUNNING

Por padrão, o gcloud compute fornece uma lista agregada de todos os recursos em todas as zonas disponíveis. Se você só quer uma lista dos recursos de uma zona específica, use a sinalização --zones na solicitação.

Na API, é necessário enviar solicitações para dois métodos diferentes para receber uma lista de recursos agregados ou uma lista de recursos dentro de uma zona. Para solicitar uma lista agregada, envie a solicitação GET para o URI do aggregatedList desse recurso, substituindo o projeto pelo ID do seu projeto:

https://compute.googleapis.com/compute/v1/projects/myproject/aggregated/instances

Nas bibliotecas cliente, faça uma solicitação para a função instances().aggregatedList:

def listAllInstances(auth_http, gce_service):
  request = gce_service.instances().aggregatedList(project=PROJECT_ID)
  response = request.execute(auth_http)

  print response

Para solicitar uma lista de instâncias dentro de uma zona, envie uma solicitação GET para o seguinte URI, substituindo o projeto pelo ID do seu projeto e a zona pela zona das instâncias:

https://compute.googleapis.com/compute/v1/projects/myproject/zones/us-central1-f/instances

Nas bibliotecas de clientes da API, crie uma solicitação instances().list:

def listInstances(auth_http, gce_service):
  request = gce_service.instances().list(project="myproject",
    zone="us-central1-f")
  response = request.execute(auth_http)

  print response

Reduzir custos com instâncias preemptivas

O Compute Engine oferece instâncias preemptivas que podem ser criadas e executadas a um preço muito mais baixo que as instâncias regulares. Se os aplicativos são tolerantes a falhas e resistentes a possíveis interrupções de instâncias, as instâncias preemptivas podem reduzir consideravelmente os custos do Compute Engine. Consulte a documentação das Instâncias preemptivas para mais informações.

Configurar o Network Time Protocol (NTP) para instâncias

Muitos sistemas de software que dependem de um cuidadoso sequenciamento de eventos se baseiam em um relógio de sistema estável e consistente. Os registros de sistema gravados pela maioria dos serviços incluem um carimbo de data/hora que ajuda a depurar os problemas que ocorrem entre os diversos componentes do sistema. Para manter os relógios em sincronia, as instâncias do Compute Engine são pré-configuradas com o Network Time Protocol (NTP).

Além de manter o horário do servidor em sincronia, o NTP é útil no caso raro de um segundo bissexto. Um segundo bissexto é um ajuste de um segundo aplicado ao horário UTC para corrigir as variações na rotação da Terra. Ele não acontece em intervalos regulares, porque a velocidade da rotação da Terra varia de maneira irregular, em resposta a eventos climáticos e geológicos. No passado, uma série de serviços e aplicativos na Web foram prejudicados pelos segundos bissextos. Os servidores NTP ajudam a garantir que o mesmo horário seja informado por todos os servidores durante o evento de um segundo bissexto.

Nesta seção, você aprende a configurar servidores NTP em máquinas virtuais para que se comportem corretamente no caso de um segundo bissexto.

Servidores NTP do Google e leap smearing

Normalmente, os segundos bissextos no Unix são implementados pela repetição do último segundo do dia. Isso pode causar problemas em softwares que presumem que o carimbo de data/hora sempre aumenta. Para contornar esse problema, os servidores de horário do Google “distribuem” o segundo extra em 20 horas, 10 antes e 10 após o evento do segundo bissexto. Desse modo, o segundo extra não fica todo concentrado em um carimbo de data/hora repetido nos computadores. Isso reduz o risco em sistemas que dependem de um carimbo de data/hora consistente. Use os serviços de NTP internos do Google em todas as instâncias de máquina virtual do Compute Engine.

Configurar NTP nas instâncias

O Google não pode prever de que maneira os serviços externos de NTP, como o pool.ntp.org, processam o segundo bissexto. Se possível, não use fontes de NTP externas com máquinas virtuais do Compute Engine. Além disso, o uso do serviço de NTP do Google com um serviço externo pode resultar em alterações imprevisíveis no horário do sistema. É preferível usar apenas uma única fonte de NTP externa do que usar essa combinação, mas saiba que os serviços de NTP externos, como o pool.ntp.org, usam stepping para processar o segundo bissexto. Como resultado, haverá um carimbo de data/hora repetido nas máquinas virtuais.

A abordagem mais segura é configurar as máquinas virtuais do Compute Engine para usar um único servidor NTP, o servidor interno fornecido pelo Google. Não misture servidores NTP externos com servidores NTP do Google, porque isso pode causar um comportamento inesperado.

Para garantir a configuração correta de máquinas virtuais, siga estas instruções.

Linux

  1. Use o ssh para se conectar à sua instância.

    Console

    1. Acesse a página Instâncias de VMs no Console do GCP.
    2. Clique no botão ssh ao lado da instância que quer configurar.

      Captura de tela do botão

    gcloud

    Com a ferramenta de linha de comando gcloud, execute:

    gcloud compute instances ssh INSTANCE
    

  2. Na instância, execute ntpq -p para verificar o estado atual da configuração do NTP:

    $ ntpq -p
    
    
         remote           refid      st t when poll reach   delay   offset  jitter
    
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    *217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
    

    Quando há um único registro apontando para metadata.google ou metadata.google.internal, não é necessário fazer alterações. Se há várias fontes, misturando o metadata.google com uma fonte pública como o pool.ntp.org, você precisa atualizá-las para remover todos os servidores NTP externos.

    Nesse exemplo, há dois registros, um apontando para o metadata.google e o outro para um endereço externo. Uma vez que existem várias fontes, é necessário atualizar os servidores NTP para remover o endereço *217.162.232.173.

    1. Configure os servidores NTP para remover as fontes externas.

      Para configurar os servidores NTP, edite o arquivo /etc/ntp.conf no editor de texto de sua preferência. Procure a seção servers da configuração e remova todas as fontes NTP que não sejam do Google:

    $ vim /etc/ntp.conf
    
    ...
    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example
    ...
    server metadata.google.internal iburst
    

    Depois de editar o arquivo /etc/ntp.conf, reinicie o serviço NTP. Dependendo da distribuição do Linux, o comando de reinicialização pode ser diferente:

    $ sudo service ntp reload
    1. Verifique a configuração. Execute o comando ntpq -p novamente para verificar se suas alterações:
    $ ntpq -p
    
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    

Windows

  1. Acesse a página Instâncias de VMs no Console do GCP.
  2. Clique no botão RDP ao lado da instância do Windows em que você quer fazer login.

    Captura de tela do botão

  3. Depois de fazer login, clique com o botão direito do mouse no ícone do PowerShell e selecione Executar como administrador.

    Captura de tela do ícone

  4. Quando o prompt de comando carregar, execute o seguinte comando para ver a configuração atual do NTP:

    PS C:\Windows\system32>w32tm /query /configuration
    [Configuration]
    ...
    Type: NTP (Local)
    NtpServer: metadata.google.internal,
    ...
    

    Quando há um único registro apontando para metadata.google ou metadata.google.internal, não é necessário fazer alterações. Quando há várias fontes, misturando o metadata.google com uma fonte pública, é necessário remover o servidor externo. Consulte o guia do Windows para configurar o servidor NTP.

O recurso leap smearing dos servidores NTP do Google é uma maneira conveniente de gerenciar o risco envolvido na repetição de um segundo nos sistemas afetados pelo tempo. Os outros serviços NTP talvez forneçam recursos aceitáveis para a maioria dos sistemas de software. Entretanto, é importante não misturar os serviços NTP de leap smearing do Google com serviços NTP públicos de stepping.

Para sincronizar os dispositivos fora da nuvem do Google com o tempo distribuído, use o NTP público do Google. Ele utiliza o mesmo método de distribuição fornecido para as instâncias de máquina virtual do Compute Engine.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine