Migrer des conteneurs déployés sur des VM lors de la création de VM

L'agent de démarrage de conteneur dans Compute Engine est obsolète. Cet agent vous permet de déployer des conteneurs sur des instances Compute Engine lorsque vous créez des VM.

Ce document explique comment migrer les conteneurs existants que l'agent de démarrage a créés sur vos VM ou groupes d'instances gérés (MIG) vers d'autres servicesTrusted Cloud .

En fonction de vos besoins, choisissez l'une des options suivantes pour migrer les conteneurs déployés sur des VM à l'aide de la méthode obsolète :

• Si vous souhaitez continuer à exécuter des conteneurs sur des VM et des MIG individuels, utilisez des scripts de démarrage ou cloud-init.
• Si vous avez des applications de conteneur sans état et des jobs de petite ou moyenne taille, utilisez Cloud Run.
• Si votre conteneur est un job par lot qui a un état final défini et qui nécessite des ressources de calcul supplémentaires, utilisez Batch.
• Si vous avez besoin d'un contrôle et d'une évolutivité avancés, ou si vous ne pouvez pas répondre à vos exigences avec les autres options, utilisez GKE sur Google Cloud.

Pour découvrir d'autres cas d'utilisation et solutions alternatives, consultez Comparer les options de déploiement de conteneurs.

Options obsolètes pour configurer des conteneurs sur des VM

Lorsque vous configurez un conteneur lors de la création d'une VM, Compute Engine utilise l'agent de démarrage du conteneur pour lire les métadonnées gce-container-declaration qui stockent les informations du conteneur et pour déployer le conteneur sur la VM.

Les options suivantes pour déployer des conteneurs directement sur une VM ou un MIG qui utilisent l'agent de démarrage de conteneur et gce-container-metadata sont obsolètes.

Identifier les instances qui utilisent les métadonnées de conteneur obsolètes

Pour déterminer si des instances de votre projet utilisent les métadonnées de conteneur obsolètes, exécutez la commande Google Cloud CLI suivante, qui liste les instances avec la clé et la valeur de métadonnées gce-container-declaration :

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

Cette commande fournit la liste de toutes les instances de VM de votre projet configuré qui contiennent la clé de métadonnées gce-container-declaration. La clé de métadonnées identifie de manière unique les VM concernées par l'abandon. Si vous utilisez plusieurs projets, exécutez cette commande sur tous les projets actifs.

Si vous souhaitez valider une instance spécifique, exécutez la commande Google Cloud CLI suivante :

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

Remplacez VM_NAME par le nom de l'instance de VM que vous souhaitez valider.

Pour en savoir plus sur l'affichage des métadonnées, consultez Afficher et interroger des métadonnées.

Comparer les options de déploiement de conteneurs

Le tableau suivant récapitule les cas d'utilisation pour l'exécution de conteneurs sur des VM et recommande d'autres solutions de conteneurs pour la migration de vos charges de travail :

Lorsque vous passez de l'agent de démarrage de conteneur Compute Engine à une solution alternative, tenez compte des modifications requises suivantes et de l'effort potentiel nécessaire pour les implémenter :

• VM exécutant Container-Optimized OS : vous êtes entièrement responsable de la configuration, de la sécurité et de la maintenance de la VM et de l'environnement d'exécution du conteneur, ce qui implique souvent de créer des scripts avec des scripts de démarrage ou cloud-init.
• Cloud Run ou Batch : assurez-vous que vos applications sont sans état et qu'elles correspondent au modèle d'exécution basé sur les requêtes ou les jobs. Cette approche peut impliquer l'adaptation des applications pour qu'elles fonctionnent avec des services de gestion d'état externes.
• GKE : adoptez les principes de Kubernetes, définissez les charges de travail à l'aide de fichiers manifestes Kubernetes et gérez les ressources du cluster.

Utiliser des scripts de démarrage pour déployer des conteneurs sur des VM

Vous pouvez exécuter un conteneur de base sur une VM à l'aide d'un script de démarrage.

Tenez compte des points suivants lorsque vous utilisez un script de démarrage pour configurer des conteneurs :

• Vous pouvez utiliser un script de démarrage pour les scénarios de base. Pour une configuration avancée, envisagez d'utiliser cloud-init.
• Étant donné que vous créez une VM avec un conteneur configuré à l'aide du script de démarrage, vous devez planifier la transition des charges de travail déployées sur les VM existantes.
• Testez et assurez-vous que tout fonctionne comme prévu avant de rediriger le trafic vers la VM avec un conteneur que vous venez de créer.

Pour créer une VM et déployer un conteneur sur une VM ou un MIG, procédez comme suit :

1. Mapper le conteneur actuel dans les métadonnées de la VM à la commande du script de démarrage
2. Créer un script de démarrage basé sur la configuration des métadonnées existante
3. Créer une VM à l'aide du script de démarrage ou créer un MIG à l'aide du script de démarrage

Mapper les métadonnées de votre conteneur à la commande docker run

Vous pouvez mapper les indicateurs de métadonnées ou gcloud de VM aux arguments docker run et les inclure dans votre script de démarrage pour créer des VM.

Certains indicateurs gcloud se traduisent directement en métadonnées de VM. Ces indicateurs correspondent directement aux indicateurs docker run. Si vous disposez d'un conteneur existant sur une VM, vous pouvez lire la configuration des métadonnées de la VM et créer un script de démarrage à l'aide des commandes docker run équivalentes.

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

Le résultat ressemble à ce qui suit :

  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'

Utilisez le tableau suivant pour mapper les spécifications existantes sur les commandes docker run :

Exemples de scripts de démarrage

Les exemples suivants montrent comment inclure les commandes docker dans votre script de démarrage :

• Exemple 1 : exécute un conteneur autonome dans une VM basée sur Container-Optimized OS.

• Exemple 2 : exécute un conteneur de serveur Web dans une VM basée sur Container-Optimized OS.

#!/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

Options de configuration supplémentaires pour le déploiement de conteneurs

Cette section décrit les paramètres de configuration supplémentaires pour déployer des conteneurs sur vos VM.

Pour en savoir plus sur ces options, consultez Configurer des options pour exécuter un conteneur.

Accès aux images Artifact Registry

Si vous avez besoin d'accéder à des images de conteneurs depuis gcr.io ou pkg.dev, utilisez l'outil docker-credential-gcr, qui est préinstallé dans Container-Optimized OS, et configurez l'authentification pour Artifact Registry pour Docker. Exécutez la commande suivante avant d'exécuter le conteneur :

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

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

Pour en savoir plus, consultez Configurer l'authentification sur Artifact Registry pour Docker.

Configurer la journalisation

Nous vous recommandons d'utiliser Cloud Logging en activant un agent de journalisation sur une VM.

Vous pouvez également inclure le paramètre --log-driver avec votre commande docker run si vous souhaitez modifier le pilote de journalisation :

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

Pour en savoir plus, consultez Utiliser Cloud Logging avec Container-Optimized OS.

Configurer le pare-feu interne

Container-Optimized OS refuse le trafic entrant par défaut. Vous devez donc ajouter des règles iptables pour l'autoriser. Notez que ces commandes configurent le pare-feu interne du système d'exploitation hôte. En outre, vous devez configurer le pare-feu de votre cloud privé virtuel pour autoriser ce trafic vers la nouvelle VM.

Pour en savoir plus, consultez Utiliser des règles de pare-feu VPC.

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

Pour en savoir plus, consultez Configurer le pare-feu de l'hôte.

Associer des volumes au conteneur

Si des volumes sont associés au conteneur, les métadonnées du conteneur incluent l'entrée volumes et un tableau volumeMounts. Le name d'une entrée dans volumes correspond au nom d'une entrée dans volumeMounts, et inversement. Pour chaque volume que vous collectez, rassemblez les informations requises à partir de l'entrée volumes ou volumeMounts.

Si aucun volume n'est associé au conteneur, vous pouvez ignorer cette section et créer directement une VM à l'aide du script de démarrage.

Pour en savoir plus sur les disques et le système de fichiers sur Container-Optimized OS, consultez la présentation des disques et du système de fichiers.

Monter le système de fichiers tmpfs

Pour installer un système de fichiers tmpfs vide dans un conteneur, spécifiez l'argument --tmpfs avec votre commande docker run. Par exemple, pour installer un système de fichiers cache dans votre conteneur nginx, exécutez la commande suivante :

  # 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

Pour en savoir plus sur l'installation des systèmes de fichiers tmpfs, consultez Installations tmpfs.

Installer un répertoire hôte

Pour installer un répertoire depuis une VM hôte dans un conteneur, spécifiez l'argument --mount avec la commande 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

Pour en savoir plus, consultez Montages de liaison.

Installer un disque persistant dans le conteneur

L'installation d'un disque sur le conteneur nécessite des étapes supplémentaires. Pour installer un disque, commencez par l'installer sur la VM, puis installez-le sur le conteneur :

1. Pour installer le disque sur la VM, exécutez la commande suivante :

   #!/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. Après avoir installé le disque sur la VM, ajoutez l'indicateur --mount avec la commande docker run pour installer le disque sur le conteneur :

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

Créer une VM à l'aide du script de démarrage

Après avoir créé un script de démarrage avec la configuration de votre conteneur, utilisez-le pour créer une VM basée sur Container-Optimized OS. Pour en savoir plus sur la création d'une VM basée sur Container-Optimized OS, consultez Créer une instance à partir d'une image publique.

Pour en savoir plus sur l'utilisation des scripts de démarrage, consultez Utiliser des scripts de démarrage sur des VM 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")
  }
}

Créer un MIG à l'aide du script de démarrage

Après avoir créé un modèle d'instance à l'aide du script de démarrage, utilisez l'une des méthodes suivantes pour créer un MIG.

Pour en savoir plus sur la création de MIG, consultez Créer un groupe d'instances géré.

  # 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
}

Tester et nettoyer

Une fois une VM ou un MIG créé, vérifiez que votre application s'exécute sur le conteneur et fonctionne comme prévu. Pour résoudre les problèmes éventuels, consultez la section Dépannage.

Si l'application s'exécute correctement sur les nouvelles VM créées à l'aide du script de démarrage, vous pouvez supprimer les VM et les MIG qui utilisent la méthode obsolète de déploiement des conteneurs.

Dépannage

Pour résoudre les problèmes qui peuvent survenir lorsque vous configurez des conteneurs sur des VM à l'aide d'un script de démarrage, consultez les journaux du script de démarrage et les journaux des conteneurs.

• Pour afficher les journaux du script de démarrage sur l'instance de VM, exécutez la commande suivante :

  sudo journalctl | grep "startup script"
  

• Pour afficher les journaux du conteneur Docker, exécutez la commande docker logs :

  docker logs CONTAINER_NAME
  

  Remplacez CONTAINER_NAME par le nom du conteneur.

Pour résoudre d'autres problèmes, consultez les documents suivants :

• Présentation de Cloud Logging
• Utiliser Cloud Logging avec Container-Optimized OS
• Dépannage du daemon Docker
• Dépannage et diagnostic
• Résoudre les problèmes liés à Terraform
• Dépannage lors de l'exécution d'un serveur Web de base
• Créer une connexion Internet pour les VM privées

Utiliser cloud-init avec Container-Optimized OS

Vous pouvez utiliser cloud-init, une solution multiplate-forme standard du secteur, pour déployer des conteneurs sur des VM exécutant Container-Optimized OS. Cet outil vous permet d'exécuter une configuration personnalisée lors de la création ou du démarrage de la VM. Pour en savoir plus, consultez Utiliser cloud-init avec le format de configuration Cloud.

Utiliser des services gérés pour le déploiement de conteneurs

Cette section décrit les services gérés fournis par Trusted Cloud by S3NS que vous pouvez utiliser pour déployer des conteneurs.

Cloud Run

Cloud Run est une bonne option pour les applications de conteneurs sans état et les tâches de petite et moyenne envergure.

Voici les principales caractéristiques de Cloud Run :

• Vous pouvez choisir de n'allouer des processeurs que lors du traitement des requêtes ou de les allouer en permanence.
• Vous pouvez exécuter une application de conteneur sans état ou un job de manière unique, planifiée ou dans le cadre d'un workflow.
• Vous pouvez configurer des délais avant expiration pour chaque requête ou tâche.
• Il est hautement évolutif et sécurisé.
• Il intègre l'équilibrage de charge et l'autoscaling.

Pour en savoir plus sur le déploiement de conteneurs sur Cloud Run, consultez Déployer des images de conteneur dans Cloud Run.

Lot

Batch est un service entièrement géré qui vous permet de planifier, de mettre en file d'attente et d'exécuter des charges de travail de traitement par lot sur des ressources Trusted Cloud by S3NS . Il est conçu pour exécuter des charges de travail par lots parallélisables, y compris celles empaquetées dans des conteneurs.

Pour en savoir plus sur le déploiement de conteneurs sur Batch, consultez les documents suivants :

• Commencer
• Créer et exécuter un job de base

Google Kubernetes Engine

Si vous exécutez des applications complexes, des microservices ou des opérations continues, et que vous avez besoin d'un contrôle précis et d'évolutivité, Google Kubernetes Engine (GKE) est l'offre la mieux adaptée. Pour en savoir plus sur le déploiement de conteneurs sur GKE, consultez les documents suivants :

• Présentation de GKE
• Guide de démarrage rapide : Déployer une application dans un cluster GKE
• Déployer une application Web en conteneur

Obtenir de l'aide

Si vous avez des questions sur le processus de migration ou si vous avez besoin d'aide, consultez les questions fréquentes ou contactez l'assistanceTrusted Cloud .