Criar e configurar instâncias

Existem duas formas de criar e configurar instâncias do Compute Engine que executam o SO otimizado para contentores da Google.

Para cenários simples em que quer executar um único contentor numa VM ou em cada VM num grupo de instâncias gerido, pode especificar uma imagem de contentor e parâmetros de configuração opcionais quando define a instância ou o modelo de instância. O Compute Engine cria a instância com a versão mais recente do SO otimizado para contentores e inicia o contentor especificado quando a VM é iniciada.

Nota: a funcionalidade do Compute Engine que implementa contentores em VMs durante a criação de VMs foi descontinuada. Use os comandos docker run num script de arranque ou use a ferramenta cloud-init para configurar e executar contentores nas suas VMs e MIGs. Para mais informações, consulte o artigo Migre contentores implementados em VMs durante a criação de VMs.

Para cenários avançados em que pode implementar vários contentores e configurar opções do Docker através do cloud-init, pode criar uma instância do Compute Engine com a imagem do SO otimizado para contentores à sua escolha e, em seguida, configurar o contentor conforme necessário.

Criar uma instância simples

Use este método para implementar um único contentor numa VM com a versão mais recente do SO otimizado para contentores. Pode realizar esta tarefa através da Google Cloud consola ou da CLI gcloud.

Consola

Nota: a opção Implementar contentor na Google Cloud consola foi descontinuada. Use o comando docker run equivalente para configurar e executar o contentor.

1. Aceda à página de instâncias de VM.

   Aceda à página de instâncias de VM

2. Clique em Criar instância.

3. Especifique um nome para a instância.

4. Na secção Contentor, selecione a caixa de verificação Implementar uma imagem de contentor nesta instância de VM.

5. Especifique a imagem do contentor a usar.

   • Pode especificar uma imagem do Container Registry ou do Artifact Registry. Por exemplo:
     • gcr.io/cloud-marketplace/google/nginx1:1.15 seleciona uma imagem de contentor NGINX 1.15 no Google Cloud Marketplace.
     • us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 seleciona uma imagem de amostra hello-app do Artifact Registry.
   • Se usar uma imagem de contentor do Docker Hub, especifique sempre o nome completo da imagem Docker. Por exemplo, especifique o seguinte nome da imagem para implementar uma imagem de contentor do Apache: docker.io/httpd:2.4.

6. Opcionalmente, clique em Opções avançadas do contentor. Para mais informações, consulte o artigo Configurar opções para executar o seu contentor.

7. Clique em Criar para criar a instância, arrancar a instância e iniciar o contentor.

gcloud

Nota: o comando da CLI gcloud está descontinuado.create-with-container Use o comando docker run equivalente para configurar e executar o contentor.

Para criar uma instância de VM básica, execute o seguinte comando:

gcloud compute instances create-with-container instance-name \
    --container-image image-name

Substitua o seguinte:

• instance-name: o nome da nova instância.
• image-name: o nome da imagem do contentor.

Por exemplo, o comando seguinte cria uma nova instância de VM denominada nginx-vm, que inicia e executa a imagem do contentor gcr.io/cloud-marketplace/google/nginx1:1.15:

gcloud compute instances create-with-container nginx-vm \
    --container-image gcr.io/cloud-marketplace/google/nginx1:1.15

Da mesma forma, pode criar uma nova instância de VM denominada hello-app que inicia e executa um contentor de exemplo no Artifact Registry:

gcloud compute instances create-with-container hello-app \
--container-image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Quando usar uma imagem de contentor do Docker Hub, tem sempre de especificar um nome de imagem do Docker completo. Por exemplo, especifique o seguinte nome de imagem para implementar uma imagem de contentor do Apache:

docker.io/httpd:2.4

Para executar um único contentor em cada VM num grupo de instâncias gerido, especifique o nome da imagem do contentor quando definir o modelo de instância. Consulte o artigo Criar um modelo de instância com uma imagem de contentor para mais informações.

Criar uma instância para cenários avançados

Use este método para selecionar uma imagem específica do SO otimizado para contentores, implementar vários contentores e usar o cloud-init para uma configuração avançada.

Ver imagens disponíveis

As imagens do SO otimizado para contentores estão disponíveis na Google Cloud lista de imagens da consola com o prefixo cos. Estes estão alojados no projeto cos-cloud. Também pode ver todas as versões atualmente disponíveis na linha de comandos executando o seguinte comando:

gcloud compute images list --project cos-cloud --no-standard-images

O resultado é semelhante ao seguinte:

NAME                       PROJECT    FAMILY      DEPRECATED  STATUS
cos-69-10895-385-0         cos-cloud  cos-69-lts              READY
cos-73-11647-534-0         cos-cloud  cos-73-lts              READY
cos-77-12371-251-0         cos-cloud  cos-77-lts              READY
cos-81-12871-103-0         cos-cloud  cos-81-lts              READY
cos-beta-81-12871-44-0     cos-cloud  cos-beta                READY
cos-dev-84-13078-0-0       cos-cloud  cos-dev                 READY
cos-stable-81-12871-103-0  cos-cloud  cos-stable              READY

Nota: as imagens do SO otimizado para contentores mais recentes estão agora disponíveis no projeto cos-cloud e usam o prefixo de nome cos. Estas imagens são idênticas às versões anteriores do SO otimizado para contentores, que usavam o prefixo de nome gci e eram acessíveis através do projeto google-containers. As imagens gci no projeto google-containers são consideradas obsoletas.
As versões mais recentes das imagens do SO otimizado para contentores estão agora a ser enviadas apenas para o projeto cos-cloud. Atualize o seu fluxo de trabalho de desenvolvimento ou produção para usar as imagens cos em cos-cloud para receber os lançamentos mais recentes.

Criar uma instância

Pode criar uma instância através da Google Cloud consola, da CLI gcloud ou da API.

Consola

Nota: a opção Implementar contentor na Google Cloud consola foi descontinuada. Use o comando docker run equivalente para configurar e executar o contentor.

Para executar uma instância do Compute Engine com um SO otimizado para contentores e o Docker instalado, faça o seguinte:

1. Abra a página de criação de instâncias do Compute Engine na Google Cloud consola.

   Crie uma nova instância do Compute Engine

2. Especifique um nome para a instância.

3. Na secção Contentores, desmarque a caixa de verificação Implementar uma imagem de contentor nesta instância de VM. Esta opção é útil se quiser implementar um único contentor na VM.

4. Na secção Disco de arranque, selecione uma imagem do SO otimizado para contentores.

5. Clique em Criar para criar e arrancar a instância.

gcloud

Nota: o comando da CLI gcloud está descontinuado.create-with-container Use o comando docker run equivalente para configurar e executar o contentor.

Reveja as imagens disponíveis e, de seguida, use o seguinte comando para criar uma instância de imagem do nó cos:

gcloud compute instances create instance-name \
    --image image-name \
    --image-project cos-cloud \
    --zone compute-zone \
    --machine-type machine-type-name

Substitua o seguinte:

• instance-name: o nome da sua instância de VM.
• image-name: o nome da imagem do SO otimizado para contentores para a instância, obtido a partir da lista de imagens disponíveis. A partir do nosso exemplo anterior, podemos usar cos-beta-81-12871-44-0.
• compute-zone: a zona de computação da sua instância.
• machine-type-name: o tipo de máquina a usar para esta nova instância. O tipo predefinido é n1-standard-1.

Por exemplo, o comando seguinte cria uma instância denominada cos-test usando a imagem cos-beta-67-10575-13-0:

gcloud compute instances create cos-test \
    --image cos-beta-67-10575-13-0 \
    --image-project cos-cloud \
    --zone us-east1-d \
    --machine-type n1-standard-1

Pode adicionar a flag --preemptible para instâncias experimentais únicas.

API

Na API, crie um pedido normal para criar uma instância, mas inclua uma imagem de origem do Container-Optimized OS. Por exemplo:

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/compute-zone/instances

{
  'machineType': 'zones/compute-zone/machineTypes/machine-type-name',
  'name': 'instance-name',
  'networkInterfaces': [
    {
      'accessConfigs': [
        {
          'type': 'ONE_TO_ONE_NAT',
          'name': 'External NAT'
        }
      ],
      'network': 'global/networks/default'
    }
  ],
  'disks': [
    {
      'type': 'PERSISTENT',
      'boot': true,
      'autoDelete': true,
      'initializeParams': {
        'sourceImage': 'projects/cos-cloud/global/images/image-name'
      }
    }
  ]
}

Configurar uma instância

Em alguns casos, pode querer fazer uma configuração adicional quando a instância é iniciada. Pode usar a ferramenta cloud-init com o SO otimizado para contentores para aplicar informações de configuração que fornece num cloud-config formato.

Usar o cloud-init com o formato de configuração na nuvem

As imagens do SO otimizado para contentores incluem cloud-init como forma de configurar a sua instância quando é iniciada. A ferramenta cloud-init espera a respetiva configuração no valor da chave user-data dos metadados da instância. A cloud-init ferramenta compreende vários formatos.

Segue-se um exemplo de um ficheiro cloud-init que mostra como criar uma conta de utilizador e criar um serviço systemd pertencente a este utilizador que controla a gestão de um contentor Docker busybox:

#cloud-config

users:
- name: cloudservice
  uid: 2000

write_files:
- path: /etc/systemd/system/cloudservice.service
  permissions: 0644
  owner: root
  content: |
    [Unit]
    Description=Start a simple docker container

    [Service]
    ExecStart=/usr/bin/docker run --rm -u 2000 --name=mycloudservice busybox:latest /bin/sleep 3600
    ExecStop=/usr/bin/docker stop mycloudservice
    ExecStopPost=/usr/bin/docker rm mycloudservice

runcmd:
- systemctl daemon-reload
- systemctl start cloudservice.service

# Optional once-per-boot setup. For example: mounting a PD.
bootcmd:
- fsck.ext4 -tvy /dev/[DEVICE_ID]
- mkdir -p /mnt/disks/[MNT_DIR]
- mount -t ext4 -O ... /dev/[DEVICE_ID] /mnt/disks/[MNT_DIR]

Nota: a utilização de systemctl enable na secção runcmd do cloud-init não funciona como previsto. Isto deve-se ao facto de /etc no SO otimizado para contentores não ter estado, pelo que os comandos como systemctl enable/disable, que modificam /etc, não persistem nos reinícios. Consulte Discos e sistema de ficheiros para mais informações sobre o sistema de ficheiros do SO otimizado para contentores. Uma alternativa a systemctl enable é usar systemctl start, como no exemplo acima. Os módulos cloud-init, como write_files e runcmd, que são normalmente executados uma vez por instância noutras distribuições, são executados em cada arranque no SO otimizado para contentores.

Nota: a opção uid na secção users é uma extensão de imagem de nó cos. Esta opção não funciona com outras versões do cloud-init. Esta opção define explicitamente o ID do utilizador e permite-lhe certificar-se de que o ID é consistente entre diferentes instâncias. Recomendamos que defina sempre esta opção. Escolha um ID no intervalo [2000, 4999] para evitar conflitos com outras contas de utilizador.

Para criar uma instância de VM do SO otimizado para contentores que referencie este ficheiro cloud-init, use a flag de linha de comandos --metadata-from-file. Partindo do princípio de que o ficheiro cloud-init se chama filename no diretório atual, o comando seguinte cria uma instância do SO otimizado para contentores e aciona cloud-init atribuindo o conteúdo do ficheiro à chave user-data nos metadados da instância:

gcloud compute instances create instance-name \
    --image image-name \
    --image-project cos-cloud \
    --metadata-from-file user-data=filename

Substitua o seguinte:

• instance-name: o nome da sua instância de VM.
• image-name: o nome da imagem do SO otimizado para contentores para a instância. Por exemplo, --image=cos-113-18244-85-29.
• filename: o nome do ficheiro de metadados.

É possível definir outras flags de metadados quando cria instâncias do Container-Optimized OS. Como estas propriedades são pares de chave-valor simples, pode usar a flag --metadata no comando gcloud compute instances create para criar as propriedades. Além disso, a partir do marco 97, pode definir flags de metadados nos metadados do projeto usando o flag --metadata no comando gcloud compute project-info add-metadata. As flags definidas ao nível da instância têm precedência sobre as flags definidas ao nível do projeto.

O exemplo anterior pode ser expandido para recolher estatísticas de utilização e a recolha de despejos de falhas com o seguinte comando:

gcloud compute instances create instance-name \
    --image image-name \
    --image-project cos-cloud \
    --metadata-from-file user-data=filename \
    --metadata=cos-metrics-enabled=true

Outras flags de metadados

Chave de metadados	Descrição	Comportamento predefinido
cos-update-strategy	Especifica o comportamento das atualizações automáticas. O valor pode ser update_enabled, update_disabled ou não definido. Se não estiver definido, é usado o comportamento de atualização automática predefinido para a etapa. Se estiver ativado, o comportamento depende do canal de lançamento: cos-dev e cos-beta: atualizações da versão do SO mais recente na família de imagens correspondente LTS milestone e cos-stable: atualizações da versão mais recente do SO do mesmo milestone	Marcos < 117: ativados por predefinição Milestones >= 117: desativado por predefinição
cos-metrics-enabled	Ativa a recolha de descarregamentos de falhas. Os valores podem ser: true false (predefinição).	Desativado por predefinição

Aviso: a ativação da definição cos-metrics-enabled permite a recolha de alguns relatórios de falhas que ajudam a Google a melhorar a imagem do nó cos. Os relatórios de falhas contêm um fragmento da parte mais recente da memória intermédia do registo do kernel no momento da falha e podem conter informações do utilizador ou pessoais, consoante o que estava a acontecer no momento da falha. As informações são enviadas diretamente para a Google e não são partilhadas fora da Google.

A estabelecer ligação a uma instância

Pode estabelecer uma ligação SSH à sua instância de VM que executa a imagem do nó da cosmesma forma que estabelece uma ligação SSH a outras instâncias do Compute Engine.

Por exemplo:

gcloud compute ssh instance-name \
    --project project-id \
    --zone compute-zone

Executar scripts de arranque

Pode especificar um script de arranque através do servidor de metadados, usando a chave de metadados startup-script. Pode usar a CLI do Google Cloud, a API ou a Google Cloud consola para fornecer um script de arranque. Consulte o artigo Executar scripts de arranque para ver detalhes.

Sincronização de tempo

Antes do milestone 85, o SO otimizado para contentores usa o serviço systemd's systemd-timesyncd para sincronizar o relógio do sistema local com um servidor de Protocolo NTP (Network Time Protocol) remoto através do protocolo SNTP. As seguintes entradas no ficheiro de configuração /etc/systemd/timesyncd.conf mostram valores de configuração predefinidos comentados para ajudar o administrador a fazer as alterações desejadas:

cat /etc/systemd/timesyncd.conf
# comments omitted for brevity
[Time]
#NTP=
#FallbackNTP=metadata.google.internal
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Assim, a distância máxima aceitável da raiz é de 5 segundos e os intervalos de sondagem mínimo e máximo para mensagens NTP são de 32 e 2048 segundos, respetivamente.

A partir da etapa 85, o SO otimizado para contentores usa o serviço chronyd para sincronizar o relógio do sistema local com um servidor de Protocolo NTP (Network Time Protocol) remoto através do protocolo NTP. As seguintes entradas no ficheiro de configuração mostram valores de configuração predefinidos comentados para ajudar o administrador a fazer as alterações pretendidas:/etc/chrony/chrony.conf

cat /etc/chrony/chrony.conf
# Use custom NTP servers
server metadata.google.internal prefer iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

O servidor NTP é definido a partir da resposta DHCP de eth0, que é normalmente o servidor de metadados do Compute Engine:

networkctl status eth0 | grep NTP
             NTP: 169.254.169.254

Alterar o fuso horário

O fuso horário predefinido do SO otimizado para contentores da Google é UTC0. Crie um link simbólico para o fuso horário pretendido, como no exemplo seguinte:

sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/US/Pacific /etc/localtime

Tenha em atenção que o /etc não tem estado, pelo que o fuso horário é reposto para o predefinido (UTC0) sempre que o dispositivo é reiniciado.

Ativar ou desativar as atualizações automáticas

Existem duas formas de ativar ou desativar as atualizações automáticas. O método preferido é definir a chave de metadados da instância cos-update-strategy como update_enabled ou update_disabled, respetivamente. Por exemplo:

gcloud compute instances create instance-name \
    --image image-name \
    --image-project cos-cloud \
    --metadata cos-update-strategy=update_disabled

A partir do marco 97, também pode desativar ou ativar as atualizações automáticas nos metadados do projeto:

gcloud compute project-info add-metadata \
    --metadata cos-update-strategy=update_disabled

Nota: os flags de metadados definidos ao nível da instância têm precedência sobre os flags de metadados definidos ao nível do projeto.

Também pode desativar as atualizações automáticas numa instância em execução com systemctl:

sudo systemctl stop update-engine
sudo systemctl mask update-engine