Migre contentores implementados em VMs durante a criação de VMs

O agente de arranque do contentor no Compute Engine está descontinuado. Este agente permite-lhe implementar contentores em instâncias do Compute Engine quando cria VMs.

Este documento descreve como migrar contentores existentes que o agente de arranque criou nas suas VMs ou grupos de instâncias geridos (MIGs) para outros serviçosTrusted Cloud .

Com base nos seus requisitos, escolha uma das seguintes opções para migrar os contentores implementados em VMs através do método descontinuado:

• Se quiser continuar a executar contentores em VMs individuais e MIGs, use scripts de arranque ou cloud-init.
• Se tiver aplicações de contentores sem estado e tarefas pequenas a médias, use o Cloud Run.
• Se o seu contentor for um trabalho em lote com um estado final definido e que requer recursos de computação adicionais, use o lote.
• Se precisar de controlo e escalabilidade avançados ou se não conseguir cumprir os seus requisitos com as outras opções, use o GKE no Google Cloud.

Para ver mais exemplos de utilização e soluções alternativas, consulte o artigo Compare as opções de implementação de contentores.

Opções descontinuadas para configurar contentores em VMs

Quando configura um contentor durante a criação da VM, o Compute Engine usa o agente de arranque do contentor para ler os metadados gce-container-declaration que armazenam as informações do contentor e para implementar o contentor na VM.

As seguintes opções para implementar contentores diretamente numa VM ou num MIG que usam o agente de arranque do contentor e o gce-container-metadata estão descontinuadas.

Identifique instâncias que usam os metadados do contentor descontinuados

Para determinar se alguma instância no seu projeto usa os metadados do contentor descontinuados, execute o seguinte comando da CLI Google Cloud que lista as instâncias com a chave e o valor dos metadados gce-container-declaration:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Este comando fornece uma lista de todas as instâncias de VM no seu projeto configurado que contêm a chave de metadados gce-container-declaration. A chave de metadados identifica de forma exclusiva as VMs que estão no âmbito da descontinuação. Se estiver a usar vários projetos, execute este comando em todos os projetos ativos.

Se tiver uma instância específica que quer validar, execute o seguinte comando da CLI Google Cloud:

  gcloud compute instances describe VM_NAME --format="(metadata.items)"

Substitua VM_NAME pelo nome da instância de VM que quer validar.

Para mais informações sobre a visualização de metadados, consulte o artigo Veja e consulte metadados.

Compare as opções de implementação do contentor

A tabela seguinte resume os exemplos de utilização para executar contentores em VMs e recomenda soluções de contentores alternativas para migrar as suas cargas de trabalho:

Quando fizer a transição do agente de arranque de contentores do Compute Engine para uma solução alternativa, considere as seguintes alterações necessárias e o potencial esforço da respetiva implementação:

• VMs que executam o SO otimizado para contentores: assuma a propriedade total da VM e da configuração de tempo de execução do contentor, da configuração, da segurança e da manutenção, o que envolve frequentemente a criação de scripts com scripts de arranque ou o cloud-init.
• Cloud Run ou Batch: certifique-se de que as suas aplicações são sem estado e se adequam ao modelo de execução baseado em pedidos ou tarefas. Esta abordagem pode envolver a adaptação de aplicações para funcionar com serviços de gestão de estado externos.
• GKE: adote os princípios do Kubernetes, defina cargas de trabalho através de ficheiros de manifesto do Kubernetes e faça a gestão dos recursos do cluster.

Use scripts de arranque para implementar contentores em VMs

Pode executar um contentor básico numa VM através de um script de arranque.

Considere os seguintes pontos quando usar um script de arranque para configurar contentores:

• Pode usar um script de arranque para cenários básicos. Para uma configuração avançada, pondere usar cloud-init.
• Uma vez que está a criar uma nova VM com um contentor configurado através do script de arranque, tem de planear a transição de todas as cargas de trabalho implementadas nas VMs existentes.
• Teste e certifique-se de que tudo funciona como esperado antes de encaminhar o tráfego para a VM recém-criada com um contentor.

Para criar uma VM e implementar um contentor numa VM ou num MIG, faça o seguinte:

1. Mapeie o contentor atual nos metadados da VM para o comando do script de arranque
2. Crie um script de arranque com base na configuração de metadados existente
3. Crie uma VM através do script de arranque ou crie um MIG através do script de arranque.

Mapeie os metadados do contentor para o comando docker run

Pode mapear os metadados da VM ou as flags gcloud para argumentos docker run e incluí-los no script de arranque para criar VMs.

Algumas flags gcloud traduzem-se diretamente em metadados da VM. Estas flags também se traduzem diretamente em flags docker run. Se tiver um contentor existente numa VM, pode ler a configuração dos metadados da VM e criar um script de arranque com os comandos docker run equivalentes.

  # Get your existing VM instance configuration in yaml format
  gcloud compute instances describe VM_NAME --format="(metadata.items)"

O resultado é semelhante ao seguinte:

  metadata:
    items:
    - key: gce-container-declaration
      value: |
        spec:
          containers:
          - args:
            - '"hello world!"'
            command:
            - echo
            env:
            - name: ONE
              value: '1'
            image: docker.io/library/busybox
            name: my-instance
            securityContext:
              privileged: true
            stdin: true
            tty: true
          restartPolicy: Always
    - key: google-logging-enabled
      value: 'true'

Use a seguinte tabela para mapear a especificação existente para comandos docker run:

Exemplos de scripts de arranque

Os exemplos seguintes mostram como incluir os comandos docker no seu script de início:

• Exemplo 1: executa um contentor autónomo numa VM baseada no SO otimizado para contentores.

• Exemplo 2: executa um contentor de servidor Web numa VM baseada no SO otimizado para contentores.

#!/bin/bash

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull busybox:latest

# Run docker container from image in docker hub
docker run busybox:latest \
  echo "hello world!"

#!/bin/bash

# Enable incoming traffic
iptables -A INPUT -j ACCEPT

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull nginx:latest

# Run docker container from image in docker hub
docker run \
  --name=$CONTAINER_NAME \
  --privileged \
  --restart=always \
  --tty \
  --detach \
  --network="host" \
  nginx:latest

Opções de configuração adicionais para a implementação de contentores

Esta secção descreve os parâmetros de configuração adicionais para implementar contentores nas suas VMs.

Para mais informações acerca destas opções, consulte o artigo Configure opções para executar um contentor.

Acesso a imagens do Artifact Registry

Se precisar de acesso a imagens de contentores a partir de gcr.io ou pkg.dev, use a ferramenta docker-credential-gcr, que está pré-instalada no SO otimizado para contentores, e configure a autenticação no Artifact Registry para o Docker. Execute o seguinte comando antes de executar o contentor:

  # Set home directory to save docker credentials
  export HOME=/home/appuser

  # Configure docker with credentials for gcr.io and pkg.dev
  docker-credential-gcr configure-docker

Para mais informações, consulte o artigo Configure a autenticação no Artifact Registry para o Docker.

Configure o registo

Recomendamos que use o Cloud Logging ativando um agente de registo numa VM.

Em alternativa, se quiser alterar o controlador de registo, pode incluir o parâmetro --log-driver com o comando docker run:

  # Use Cloud Logging logging driver
  docker run --log-driver=gcplogs nginx:latest

Para mais informações, consulte o artigo Usar o Cloud Logging com o SO otimizado para contentores

Configure a firewall interna

O SO otimizado para contentores nega o tráfego recebido por predefinição, pelo que tem de adicionar regras iptables para permitir esse tráfego. Tenha em atenção que estes comandos configuram a firewall interna do sistema operativo do anfitrião. Além disso, tem de configurar a firewall da Virtual Private Cloud para permitir esse tráfego para a nova VM

Para mais informações, consulte o artigo Use regras de firewall de VPC.

  # Enable all incoming and routed traffic
  iptables -A INPUT -j ACCEPT
  iptables -A FORWARD -j ACCEPT

Para mais informações, consulte o artigo Configurar a firewall do anfitrião.

Anexe volumes ao contentor

Se os volumes estiverem anexados ao contentor, os metadados do contentor incluem a entrada volumes e uma matriz volumeMounts. O name de uma entrada em volumes corresponde ao nome de uma entrada em volumeMounts e vice-versa. Para cada volume que recolhe, reúna as informações necessárias a partir da entrada volumes ou da entrada volumeMounts.

Se não estiverem anexados volumes ao contentor, pode ignorar esta secção e criar diretamente uma VM através do script de arranque.

Para mais informações sobre os discos e o sistema de ficheiros no SO otimizado para contentores, consulte a vista geral dos discos e do sistema de ficheiros.

Montar sistema de ficheiros tmpfs

Para montar um sistema de ficheiros tmpfs vazio num contentor, especifique o argumento --tmpfs com o comando docker run. Por exemplo, para montar um sistema de ficheiros de cache no contentor nginx, execute o seguinte comando:

  # mount a cache file system to the nginx container
  docker run -d --name=$CONTAINER_NAME --tmpfs /var/cache/nginx:rw,size=512m,noexec,nosuid,nodev --network="host" nginx:latest

Para mais informações sobre a montagem de sistemas de ficheiros tmpfs, consulte o artigo Montagens tmpfs.

Monte um diretório de anfitrião

Para montar um diretório de uma VM de anfitrião num contentor, especifique o argumento --mount com o comando docker run:

  # mount a read-only directory to the nginx container
  docker run -d --name=$CONTAINER_NAME --mount type=bind,source=/var/www/html,target=/usr/share/nginx/html,ro nginx:latest

Para mais informações, consulte o artigo Montagens de ligação.

Monte um disco persistente no contentor

A montagem de um disco no contentor requer passos adicionais. Para montar um disco, primeiro, monte-o na VM e, em seguida, monte esse disco no contentor:

1. Para montar o disco na VM, execute o seguinte comando:

   #!/bin/bash
   
   DISK_DEVICE_NAME="my-persistent-disk" # This name MUST match the 'device-name' in the gcloud --disk flag
   DISK_BY_ID_PATH="/dev/disk/by-id/google-${DISK_DEVICE_NAME}"
   HOST_MOUNT_POINT="/mnt/disks/my-persistent-disk" # This is the path where the disk will be mounted on the VM
   CONTAINER_MOUNT_PATH="/usr/share/my-persistent-disk" # This is the path where the disk will be mounted in the container
   
   # format a disk as an ext4 filesystem, if it doesn't already contain one
   file -sL $DISK_BY_ID_PATH | grep -q filesystem || \
           mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_BY_ID_PATH
   
   # create a directory for mounting point
   sudo mkdir -p "${HOST_MOUNT_POINT}"
   
   # mount a disk to the VM
   sudo mount -o defaults,discard "${DISK_BY_ID_PATH}" "${HOST_MOUNT_POINT}"
   

2. Depois de montar o disco na VM, adicione a flag --mount com o comando docker run para montar o disco no contentor:

   docker run -d --name=$CONTAINER_NAME --mount type=bind,source="${HOST_MOUNT_POINT}",target="${CONTAINER_MOUNT_PATH}",readonly nginx:latest
   

Crie uma VM através do script de arranque

Depois de criar um script de arranque com a configuração do contentor, use este script de arranque para criar uma VM baseada no SO otimizado para contentores. Para mais informações sobre como criar uma VM baseada no SO otimizado para contentores, consulte o artigo Crie uma instância a partir de uma imagem pública.

Para mais informações sobre a utilização de scripts de arranque, consulte o artigo Utilizar scripts de arranque em VMs Linux.

provider "google" {
project = "PROJECT_ID"
}

resource "google_compute_instance" "cos_vm_instance" {
name         = "VM_NAME"
machine_type = "MACHINE_TYPE"
zone         = "ZONE"

# Use a Container-Optimized OS image for the boot disk
boot_disk {
  initialize_params {
    image = "IMAGE_PROJECT/IMAGE_FAMILY"
  }
}

# Attaches the instance to the default network
network_interface {
  network = "default"
}

# Specify the relative path to the startup script on your local machine
metadata = {
  startup-script = file("STARTUP_SCRIPT_FILE")
}
}

provider "google" {
  project = "my-project"
}

resource "google_compute_instance" "my_container_vm" {
  name = "my-container-vm-startup"
  machine_type = "e2-medium"
  zone = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "cos-cloud/cos-stable"
    }
  }

  network_interface {
    network = "default"
  }

  metadata = {
    startup-script = file("./startup_script.sh")
  }
}

Crie um MIG através do script de arranque

Depois de criar um modelo de instância com o script de arranque, use um dos seguintes métodos para criar um MIG.

Para mais informações sobre a criação de MIGs, consulte o artigo Crie um grupo de instâncias gerido.

  # Create the instance template that uses a startup script
  gcloud compute instance-templates create startup-template \
      --machine-type=e2-medium \
      --image-family=cos-stable \
      --image-project=cos-cloud \
      --metadata-from-file=startup-script=./startup_script.sh

  # Create the managed instance group
    gcloud compute instance-groups managed create startup-mig \
      --template=startup-template \
      --size=2 \
      --zone=us-central1-a

resource "google_compute_instance_template" "startup_template" {
  name_prefix = "startup-template-"
  machine_type = "e2-medium"
  disk {
    source_image = "cos-cloud/cos-stable"
    auto_delete  = true
    boot         = true
  }

  network_interface {
    network = "default"
  }
  metadata = {
    startup-script = file("./startup_script.sh")
}
}

resource "google_compute_instance_group_manager" "startup_mig" {
  name               = "startup-mig"
  base_instance_name = "startup-vm"
  zone               = "us-central1-a"
  version {
    instance_template = google_compute_instance_template.startup_template.id
  }
  target_size = 2
}

Teste e limpe

Após a criação bem-sucedida de uma VM ou de um MIG, valide se a sua aplicação está a ser executada no contentor e a funcionar conforme esperado. Para corrigir problemas, consulte a secção Resolução de problemas.

Se a aplicação estiver a ser executada com êxito nas novas VMs criadas através do script de arranque, pode eliminar as VMs e os MIGs que usam o método descontinuado de implementação de contentores.

Resolução de problemas de scripts de arranque

Esta secção fornece informações de resolução de problemas para problemas que pode encontrar quando usa scripts de arranque.

Não é possível guardar a configuração do Docker

Quando executa o comando docker-credential-gcr configure-docker num script de arranque, pode receber a seguinte mensagem de erro:

ERROR: Unable to save docker config: mkdir /root/.docker: read-only file system

Este erro ocorre porque docker-credential-gcr tenta escrever credenciais no ficheiro /root/.docker/config.json. O sistema de ficheiros root no Container-Optimized OS é apenas de leitura, pelo que não pode escrever nele.

Para resolver este problema, defina a variável de ambiente $HOME para apontar para um diretório base personalizado antes de executar os comandos docker.

Exemplo:

  export HOME=/home/appuser
  docker-credential-gcr configure-docker
  

Veja registos para depurar problemas

Para resolver problemas que possam ocorrer quando configura contentores em VMs através de um script de arranque, veja os registos do script de arranque e os registos do contentor.

• Para ver os registos do script de arranque na instância da VM, execute o seguinte comando:

  sudo journalctl | grep "startup-script"
  

• Para ver os registos do contentor Docker, execute o comando docker logs:

  docker logs CONTAINER_NAME
  

  Substitua CONTAINER_NAME pelo nome do seu contentor.

Para resolver outros problemas, consulte os seguintes documentos:

• Vista geral do Cloud Logging
• Usar o Cloud Logging com o SO otimizado para contentores
• Resolução de problemas do daemon do Docker
• Resolva problemas e faça diagnósticos
• Resolva problemas do Terraform
• Resolução de problemas ao executar um servidor Web básico
• Criar conetividade à Internet para VMs privadas

Use o cloud-init com o SO otimizado para contentores

Pode usar o cloud-init, uma solução multiplataforma e padrão da indústria, para implementar contentores em VMs que executam o SO otimizado para contentores. Esta ferramenta permite-lhe executar uma configuração personalizada durante a criação ou o arranque da VM. Para mais informações, consulte o artigo Usar o cloud-init com o formato de configuração na nuvem.

Use serviços geridos para a implementação de contentores

Esta secção descreve os serviços geridos fornecidos pela Trusted Cloud by S3NS que pode usar para implementar contentores.

Cloud Run

O Cloud Run é uma boa opção para aplicações de contentores sem estado e tarefas de pequena a média dimensão.

As principais funcionalidades do Cloud Run incluem o seguinte:

• Pode optar por atribuir CPUs apenas durante o processamento de pedidos ou atribuir sempre CPUs.
• Pode executar uma aplicação de contentor sem estado ou executar uma tarefa única, num horário ou como parte de um fluxo de trabalho.
• Pode configurar os limites de tempo para cada pedido ou tarefa.
• É altamente escalável e seguro.
• Tem balanceamento de carga e escalabilidade automática integrados.

Para mais informações sobre a implementação de contentores no Cloud Run, consulte o artigo Implementar imagens de contentores no Cloud Run

Lote

O Batch é um serviço totalmente gerido que lhe permite agendar, colocar em fila e executar cargas de trabalho de processamento em lote em Trusted Cloud by S3NS recursos. Foi concebido para executar cargas de trabalho paralelizadas no estilo de lotes, incluindo as que estão em pacotes em contentores.

Para mais informações sobre a implementação de contentores no Batch, consulte os seguintes documentos:

• Comece a usar
• Crie e execute uma tarefa básica

Google Kubernetes Engine

Se estiver a executar aplicações complexas, microsserviços, funcionamento contínuo e precisar de controlo detalhado e escalabilidade, o Google Kubernetes Engine (GKE) é a oferta mais adequada. Para mais informações sobre a implementação de contentores no GKE, consulte os seguintes documentos:

• Vista geral do GKE
• Início rápido: implemente uma app num cluster do GKE
• Implementar uma aplicação Web contentorizada

Obter apoio técnico

Se tiver dúvidas sobre o processo de migração ou precisar de assistência, consulte as Perguntas frequentes ou contacte o Trusted Cloud apoio técnico.