Container migrieren, die während der VM-Erstellung auf VMs bereitgestellt wurden

Der Container-Start-Agent in Compute Engine ist veraltet. Mit diesem Agent können Sie Container auf Compute Engine-Instanzen bereitstellen, wenn Sie VMs erstellen.

In diesem Dokument wird beschrieben, wie Sie vorhandene Container migrieren, die der Startup-Agent auf Ihren VMs oder verwalteten Instanzgruppen (MIGs) erstellt hat, zu anderenCloud de Confiance by S3NS -Diensten.

Wählen Sie je nach Ihren Anforderungen eine der folgenden Optionen aus, um die Container zu migrieren, die mit der eingestellten Methode auf VMs bereitgestellt wurden:

• Wenn Sie weiterhin Container auf einzelnen VMs und MIGs ausführen möchten, verwenden Sie Startskripts oder cloud-init.
• Wenn Sie zustandslose Containeranwendungen und kleine bis mittelgroße Jobs haben, verwenden Sie Cloud Run.
• Wenn Ihr Container ein Batchjob mit einem bestimmten Endstatus ist und zusätzliche Rechenressourcen benötigt, verwenden Sie Batch.
• Wenn Sie erweiterte Steuerungsmöglichkeiten und Skalierbarkeit benötigen oder Ihre Anforderungen mit den anderen Optionen nicht erfüllen können, verwenden Sie GKE in Google Cloud.

Weitere Anwendungsfälle und alternative Lösungen finden Sie unter Containerbereitstellungsoptionen vergleichen.

Erstellung neuer VMs verhindern, die den Container-Start-Agenten verwenden

Um die Erstellung neuer VMs zu verhindern, die den eingestellten Container-Start-Agent verwenden, können Organisationsadministratoren eine Organisationsrichtlinie erzwingen. Weitere Informationen finden Sie unter Erstellung von VMs verhindern, die die eingestellten Containermetadaten verwenden.

Nicht mehr unterstützte Optionen zum Konfigurieren von Containern auf VMs

Wenn Sie einen Container während der VM-Erstellung konfigurieren, verwendet Compute Engine den Container-Start-Agent, um die gce-container-declaration-Metadaten zu lesen, in denen die Containerinformationen gespeichert sind, und den Container auf der VM bereitzustellen.

Die folgenden Optionen zum direkten Bereitstellen von Containern auf einer VM oder MIG, bei denen der Container-Start-Agent und gce-container-metadata verwendet werden, sind veraltet.

Erstellung von VMs verhindern, die den Container-Start-Agenten verwenden

Informationen zum Verhindern der Erstellung neuer VMs, die den eingestellten Container-Start-Agent verwenden, mithilfe einer Organisationsrichtlinie finden Sie unter Erstellung von VMs verhindern, die die eingestellten Containermetadaten verwenden.

Instanzen identifizieren, die die verworfenen Containermetadaten verwenden

So identifizieren Sie Instanzen in Ihrem Projekt, die die eingestellten Containermetadaten verwenden:gce-container-declaration

1. Führen Sie einen der folgenden Befehle aus:

   • Führen Sie den folgenden gcloud CLI-Befehl aus, um alle Instanzen in Ihrem Projekt aufzulisten, die den Metadatenschlüssel und -wert gce-container-declaration verwenden:

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

     Mit diesem Befehl wird eine Liste aller VM-Instanzen in Ihrem konfigurierten Projekt zurückgegeben, die den Metadatenschlüssel gce-container-declaration enthalten. Der Metadatenschlüssel identifiziert eindeutig VMs, die von der Einstellung betroffen sind. Wenn Sie mehrere Projekte verwenden, führen Sie diesen Befehl für alle aktiven Projekte aus.

   • Führen Sie den folgenden gcloud CLI-Befehl aus, um eine bestimmte Instanz zu validieren:

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

     Ersetzen Sie VM_NAME durch den Namen der VM-Instanz, die Sie validieren möchten.

2. Wenn in der Ausgabe des Befehls aus dem vorherigen Schritt Instanzen aufgeführt sind, die den Metadatenschlüssel gce-container-declaration verwenden, führen Sie den folgenden Befehl aus, um weitere Informationen zur Containerdeklaration auf Ihren VMs zu erhalten:

   gcloud compute instances list \
     --filter='metadata.items.key:gce-container-declaration AND (metadata.items.value~"image:")' \
     --format="table(name, zone, metadata.items.filter(key='gce-container-declaration').extract(value).slice(0):label=CONTAINER_DECLARATION)"
   

3. Berücksichtigen Sie anhand der Ausgabe des Befehls Folgendes:

   • Wenn die Metadaten die Definition für den eingestellten Container-Start-Agenten enthalten, müssen Sie die Containerbereitstellung wie in diesem Dokument beschrieben auf eine alternative Lösung migrieren.

   • Wenn der Metadatenschlüssel gce-container-declaration vorhanden ist, Sie ihn aber nicht für den Container-Start-Agent verwenden, führen Sie die folgenden Schritte aus:

     • Prüfen Sie, ob Sie diesen Metadatenschlüssel für andere Konfigurationen wiederverwenden.
     • Wenn Sie den Schlüssel wiederverwenden, verwenden Sie einen anderen Metadatenschlüssel für andere Konfigurationen.

Weitere Informationen zum Aufrufen von Metadaten finden Sie unter Metadaten ansehen und abfragen.

Containerbereitstellungsoptionen vergleichen

In der folgenden Tabelle sind die Anwendungsfälle für die Ausführung von Containern auf VMs zusammengefasst. Außerdem werden alternative Containerlösungen für die Migration Ihrer Arbeitslasten empfohlen:

Wenn Sie vom Compute Engine-Container-Start-Agent zu einer alternativen Lösung wechseln, sollten Sie die folgenden erforderlichen Änderungen und den potenziellen Aufwand für die Implementierung berücksichtigen:

• VMs mit Container-Optimized OS: Sie sind für die Einrichtung, Konfiguration, Sicherheit und Wartung von VMs und Container-Laufzeiten verantwortlich. Dazu ist häufig die Verwendung von Startskripten oder cloud-init erforderlich.
• Cloud Run oder Batch: Ihre Anwendungen müssen zustandslos sein und dem anfragebasierten oder jobbasierten Ausführungsmodell entsprechen. Dazu müssen Anwendungen möglicherweise an externe Dienste zur Statusverwaltung angepasst werden.
• GKE: Übernehmen Sie Kubernetes-Prinzipien, definieren Sie Arbeitslasten mit Kubernetes-Manifestdateien und verwalten Sie Clusterressourcen.

Startskripts zum Bereitstellen von Containern auf VMs verwenden

Sie können einen einfachen Container auf einer VM mit einem Startskript ausführen.

Beachten Sie die folgenden Punkte, wenn Sie ein Startskript zum Konfigurieren von Containern verwenden:

• Für einfache Szenarien können Sie ein Startskript verwenden. Für die erweiterte Konfiguration empfiehlt sich die Verwendung von cloud-init.
• Da Sie eine neue VM mit einem Container erstellen, der mit dem Startskript konfiguriert wird, müssen Sie die Umstellung aller Arbeitslasten planen, die auf den vorhandenen VMs bereitgestellt werden.
• Testen Sie, ob alles wie erwartet funktioniert, bevor Sie Traffic an die neu erstellte VM mit einem Container weiterleiten.

So erstellen Sie eine VM und stellen einen Container auf einer VM oder einer MIG bereit:

1. Aktuellen Container in VM-Metadaten dem Startskriptbefehl zuordnen
2. Startskript auf Grundlage der vorhandenen Metadatenkonfiguration erstellen
3. VM mit dem Startskript erstellen oder MIG mit dem Startskript erstellen

Containermetadaten dem docker run-Befehl zuordnen

Sie können die VM-Metadaten oder gcloud-Flags den docker run-Argumenten zuordnen und in Ihr Startskript zum Erstellen von VMs einfügen.

Einige gcloud-Flags werden direkt in VM-Metadaten übersetzt. Diese Flags werden auch direkt in docker run-Flags übersetzt. Wenn Sie einen vorhandenen Container auf einer VM haben, können Sie die VM-Metadatenkonfiguration lesen und ein Startskript mit den entsprechenden docker run-Befehlen erstellen.

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

Die Ausgabe sieht etwa so aus:

  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'

In der folgenden Tabelle sehen Sie, wie Sie vorhandene Spezifikationen docker run-Befehlen zuordnen:

Beispiel-Startskripts

Die folgenden Beispiele zeigen, wie Sie die docker-Befehle in Ihr Startskript einfügen:

• Beispiel 1: Führt einen eigenständigen Container auf einer VM aus, die auf Container-Optimized OS basiert.

• Beispiel 2: Führt einen Webserver-Container auf einer VM aus, die auf Container-Optimized OS basiert.

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

Zusätzliche Konfigurationsoptionen für die Containerbereitstellung

In diesem Abschnitt werden die zusätzlichen Konfigurationsparameter für die Bereitstellung von Containern auf Ihren VMs beschrieben.

Weitere Informationen zu diesen Optionen finden Sie unter Optionen zum Ausführen von Containern konfigurieren.

Zugriff auf Artifact Registry-Images

Wenn Sie Zugriff auf Container-Images von gcr.io oder pkg.dev benötigen, verwenden Sie das docker-credential-gcr-Tool, das in Container-Optimized OS vorinstalliert ist, und konfigurieren Sie die Authentifizierung für Artifact Registry für Docker. Führen Sie den folgenden Befehl aus, bevor Sie den Container ausführen:

  # 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 --registries LOCATION-docker.pkg.dev

Ersetzen Sie LOCATION durch den Standort Ihres Repositorys.

Weitere Informationen finden Sie unter Authentifizierung bei Artifact Registry für Docker konfigurieren.

Logging konfigurieren

Wir empfehlen, Cloud Logging zu verwenden, indem Sie einen Logging-Agent auf einer VM aktivieren.

Wenn Sie den Logging-Treiber ändern möchten, können Sie alternativ den Parameter --log-driver in Ihren docker run-Befehl einfügen:

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

Weitere Informationen finden Sie unter Cloud Logging mit Container-Optimized OS verwenden.

Interne Firewall konfigurieren

Container-Optimized OS lehnt eingehenden Traffic standardmäßig ab. Sie müssen also iptables-Regeln hinzufügen, um diesen Traffic zuzulassen. Mit diesen Befehlen wird die interne Firewall des Hostbetriebssystems konfiguriert. Außerdem müssen Sie die Firewall Ihrer Virtual Private Cloud (VPC) so konfigurieren, dass dieser Traffic zur neuen VM zugelassen wird.

Weitere Informationen finden Sie unter VPC-Firewallregeln verwenden.

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

Weitere Informationen finden Sie unter Host-Firewall konfigurieren.

Volumes an den Container anhängen

Wenn dem Container Volumes zugeordnet sind, enthalten die Containermetadaten den Eintrag volumes und ein volumeMounts-Array. Die name eines Eintrags in volumes entspricht dem Namen eines Eintrags in volumeMounts und umgekehrt. Erfassen Sie für jedes Volumen die erforderlichen Informationen entweder aus dem volumes- oder dem volumeMounts-Eintrag.

Wenn keine Volumes an den Container angehängt sind, können Sie diesen Abschnitt überspringen und direkt eine VM mit dem Startskript erstellen.

Weitere Informationen zu Laufwerken und Dateisystemen in Container-Optimized OS finden Sie unter Übersicht über Laufwerke und Dateisysteme.

tmpfs-Dateisystem bereitstellen

Wenn Sie ein leeres tmpfs-Dateisystem in einem Container bereitstellen möchten, geben Sie das Argument --tmpfs mit Ihrem docker run-Befehl an. Wenn Sie beispielsweise ein Cache-Dateisystem in Ihrem NGINX-Container bereitstellen möchten, führen Sie den folgenden Befehl aus:

  # 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

Weitere Informationen zum Mounten von tmpfs-Dateisystemen finden Sie unter tmpfs-Mounts.

Hostverzeichnis bereitstellen

Wenn Sie ein Verzeichnis aus einer Host-VM in einem Container bereitstellen möchten, geben Sie das --mount-Argument mit dem docker run-Befehl an:

  # 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

Weitere Informationen finden Sie unter Bind-Mounts.

Nichtflüchtigen Speicher im Container bereitstellen

Das Bereitstellen eines Laufwerks für den Container erfordert zusätzliche Schritte. Wenn Sie ein Laufwerk bereitstellen möchten, stellen Sie es zuerst auf der VM und dann im Container bereit:

1. Führen Sie den folgenden Befehl aus, um das Laufwerk auf der VM bereitzustellen:

   #!/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. Nachdem Sie das Laufwerk an die VM angehängt haben, fügen Sie das Flag --mount mit dem Befehl docker run hinzu, um das Laufwerk an den Container anzuhängen:

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

Startup-Script mit Unterstützung durch Gemini erstellen

Sie können mit Gemini ein Startskript auf Grundlage Ihrer vorhandenen Containerdeklaration erstellen lassen.

So verwenden Sie Gemini Cloud Assist zum Generieren eines Startscripts:

1. Zur Seite "Compute Engine"

   Zu Compute Engine

2. Klicken Sie in der Cloud de Confiance -Symbolleiste auf spark Gemini-KI-Chat öffnen oder schließen, um den Gemini Cloud Assist-Chat zu öffnen.

   

3. Geben Sie im Feld Prompt eingeben den Beispielprompt ein, der in diesem Abschnitt bereitgestellt wird. Ersetzen Sie die Platzhalter für das Skript und die Container-YAML-Datei durch ein Startskript und Ihre vorhandene Containerkonfiguration.

4. Klicken Sie auf send Prompt senden.

Weitere Informationen zum Einrichten und Verwenden von Gemini Cloud Assist finden Sie unter Gemini Cloud Assist einrichten.

      <OBJECTIVE_AND_PERSONA>
      You are a senior systems architect migrating container deployments on Compute Engine. The legacy container startup agent, Konlet, is deprecated, which is the reason for this migration. Your task is to process the input YAML specification, which is the existing container declaration being migrated, and translate it into a robust Bash startup script for Container-Optimized OS on Compute Engine. You must ensure complete functional equivalence with 1:1 Konlet parity by following the `<INSTRUCTIONS>` and referring to the `<CONTEXT>` element below.
      </OBJECTIVE_AND_PERSONA>

      <INSTRUCTIONS>
      To complete this task, follow these instructions in sequence:
      1. Initialize the script with the shebang `#!/bin/bash` and options `set -euo pipefail`.
      2. Integrate the "Existing Script" input verbatim immediately after the initialization.
      3. Add a blank line, then define a function wrapper: `start_gce_container() { ... }`.
      4. Inside the function, include the mandatory logic blocks for Firewall, Cleanup, and Authentication provided in the `<CONTEXT>`.
      5. Translate the provided YAML "Container Declaration" using the mapping rules in the `<CONTEXT>`.
      6. Generate HostPath, EmptyDir, or Persistent Disk volume preparation steps using the patterns provided in the `<CONTEXT>`.
      7. Finalize the function, add a blank line, and provide the invocation and completion echo statements as specified in the `<OUTPUT_FORMAT>`.
      </INSTRUCTIONS>

      <CONSTRAINTS>
      1. Do not simplify: Ensure all logic steps and verbatim blocks are included. Omitting any block constitutes a functional failure.
      2. UI link protection: Define all URLs using split-string variables to prevent the UI from breaking the script with Markdown links:
         `KLT_URL="http""://metadata.google.internal/..."`
      3. Nsenter prefix: You must prefix every `mkdir`, `mount`, `umount`, `blkid`, `mkfs`, and `grep` (when checking `/proc/mounts`) with: `nsenter -t 1 -m --`.
      4. One command per line: Every single Bash command must be on its own separate line. Do not split a single command's arguments across multiple lines (e.g. keep `docker run` and its flags on one line, or use backslash `\` line continuations if you split the command).
      5. Comment style: Include headers and comments using the `#` symbol for clarity.
      6. Docker execution rules: Always run containers in detached mode using `docker run -d`. Never use the `--rm` flag. Never use the shell background operator (`&`) at the end of the `docker run` command.
      </CONSTRAINTS>

      <CONTEXT>

      ## Translation dictionary (1:1 Konlet parity)
      1. Restart policy:
         - Always: `--restart always`
         - OnFailure: `--restart on-failure`
         - Never: `--restart no`
      2. Security context:
         - privileged: true -> Add `--privileged` flag.
         - If disk name contains 'local-ssd', use dev path: `/dev/disk/by-id/google-local-nvme-ssd-0`
      3. Multi-container support:
         - If `spec.containers` has multiple entries, generate a separate `docker run` command for EACH container.
      4. Background execution:
         - To run containers in the background, you must use the `docker run -d` (detached) flag. Do not use `--rm` or `&`.

      ## Verbatim logic blocks (Use as-is inside function)
      Firewall:
      /sbin/iptables -C INPUT -j ACCEPT 2>/dev/null || /sbin/iptables -A INPUT -j ACCEPT
      /sbin/iptables -C FORWARD -j ACCEPT 2>/dev/null || /sbin/iptables -A FORWARD -j ACCEPT

      Cleanup:
      /usr/bin/docker ps -a --filter "name=klt-" -q | xargs -r /usr/bin/docker rm -f
      nsenter -t 1 -m -- /bin/sh -c 'for m in $(/bin/grep "/mnt/disks/gce-containers-mounts/" /proc/mounts | /usr/bin/awk '\''{print $2}'\'' | /bin/sort -r); do /bin/umount "$m" || true; done'

      Authentication (Hardened for boot-time race conditions):
      export DOCKER_CONFIG="/var/lib/docker-config"
      /bin/mkdir -p "$DOCKER_CONFIG"
      KLT_URL_TOKEN="http""://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
      KLT_URL_REG="https""://gcr.io"
      /bin/sleep 2
      KLT_TOKEN=$(/usr/bin/curl -s -H "Metadata-Flavor: Google" "$KLT_URL_TOKEN" | /bin/grep -o '"access_token":"[^"]*' | /bin/grep -o '[^"]*$')
      if [ -n "$KLT_TOKEN" ]; then
        echo "$KLT_TOKEN" | /usr/bin/docker login -u oauth2accesstoken --password-stdin "$KLT_URL_REG"
      fi

      ## Volume preparation patterns
      Pattern A (GcePersistentDisk):
      nsenter -t 1 -m -- /bin/mkdir -p [MNT_PATH]
      nsenter -t 1 -m -- /sbin/blkid [DEV_PATH] || nsenter -t 1 -m -- /sbin/mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard [DEV_PATH]
      nsenter -t 1 -m -- /bin/mount -t ext4 -o discard,defaults [DEV_PATH] [MNT_PATH]
      nsenter -t 1 -m -- /bin/grep -q " [MNT_PATH] " /proc/mounts || exit 1

      Pattern B (EmptyDir Memory):
      nsenter -t 1 -m -- /bin/mkdir -p [MNT_PATH]
      nsenter -t 1 -m -- /bin/mount -t tmpfs tmpfs [MNT_PATH]
      nsenter -t 1 -m -- /bin/grep -q " [MNT_PATH] " /proc/mounts || exit 1

      Pattern C (HostPath):
      nsenter -t 1 -m -- /bin/mkdir -p [HOST_PATH]
      </CONTEXT>

      <OUTPUT_FORMAT>
      1. Shebang & Opts: `#!/bin/bash` and `set -euo pipefail`.
      2. Existing Script: Integrated verbatim.
      3. [BLANK LINE]
      4. Function Wrapper: `start_gce_container() { ... }`
      5. [BLANK LINE]
      6. Invocation: `start_gce_container || echo "Error: Container failed to start..."`
      7. Completion: `echo "Startup script finished."`
      </OUTPUT_FORMAT>

      <FEW_SHOT_EXAMPLES>
      <INPUT_YAML>
      ```yaml
      spec: \
        containers: \
        - name: klt-main \
          image: gcr.io/my-proj/app:v1 \
          volumeMounts: \
          - name: data \
            mountPath: /data \
        volumes: \
        - name: data \
          gcePersistentDisk: \
            pdName: data-disk \
            fsType: ext4
      ```
      </INPUT_YAML>

      <OUTPUT_THOUGHTS>
      The model should identify Pattern A for GcePersistentDisk and use the `nsenter` prefix for mounts.
      </OUTPUT_THOUGHTS>

      <OUTPUT_SNIPPETS>
      <SAMPLE_STARTUP_SCRIPT>
      #!/bin/bash \
      set -euo pipefail \
      echo "=== STARTING CUSTOM PRE-STARTUP ===" \
      mkdir -p /tmp/test-marker \
      echo "marker-content" > /tmp/test-marker/ok.txt \
      echo "=== FINISHED CUSTOM PRE-STARTUP ==="

      start_gce_container() {
      # Firewall:
      /sbin/iptables -C INPUT -j ACCEPT 2>/dev/null || /sbin/iptables -A INPUT -j ACCEPT
      /sbin/iptables -C FORWARD -j ACCEPT 2>/dev/null || /sbin/iptables -A FORWARD -j ACCEPT

      # Cleanup:
      /usr/bin/docker ps -a --filter "name=klt-" -q | xargs -r /usr/bin/docker rm -f
      nsenter -t 1 -m -- /bin/sh -c 'for m in $(/bin/grep "/mnt/disks/gce-containers-mounts/" /proc/mounts | /usr/bin/awk '\''{print $2}'\'' | /bin/sort -r); do /bin/umount "$m" || true; done'

      # Authentication (Hardened for boot-time race conditions):
      export DOCKER_CONFIG="/var/lib/docker-config"
      /bin/mkdir -p "$DOCKER_CONFIG"
      KLT_URL_TOKEN="http""://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
      KLT_URL_REG="https""://gcr.io"
      /bin/sleep 2
      KLT_TOKEN=$(/usr/bin/curl -s -H "Metadata-Flavor: Google" "$KLT_URL_TOKEN" | /bin/grep -o '"access_token":"[^"]*' | /bin/grep -o '[^"]*$')
      if [ -n "$KLT_TOKEN" ]; then
        echo "$KLT_TOKEN" | /usr/bin/docker login -u oauth2accesstoken --password-stdin "$KLT_URL_REG"
      fi

      </SAMPLE_STARTUP_SCRIPT>
      </OUTPUT_SNIPPETS>
      </FEW_SHOT_EXAMPLES>

      <RECAP>
      As the systems architect leading this migration on Compute Engine, you must ensure that the final script retains full functional equivalence with the deprecated Konlet agent. This requires applying the host-level execution constraints using `nsenter` specified in the `<CONTEXT>` element, protecting URLs with string splitting, and strictly conforming to the `<OUTPUT_FORMAT>` without skipping any logic blocks.
      </RECAP>

      # Input
      1. Existing script: EXISTING_SCRIPT
      2. Container declaration (YAML): CONTAINER_YAML
  

VM mit dem Startskript erstellen

Nachdem Sie ein Startskript mit Ihrer Containerkonfiguration erstellt haben, verwenden Sie dieses Startskript, um eine VM auf Basis von Container-Optimized OS zu erstellen. Weitere Informationen zum Erstellen einer VM auf der Grundlage von Container-Optimized OS finden Sie unter Instanz aus einem öffentlichen Image erstellen.

Weitere Informationen zur Verwendung von Startskripts finden Sie unter Startskripts auf Linux-VMs verwenden.

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")
  }
}

MIG mit dem Startskript erstellen

Nachdem Sie eine Instanzvorlage mit dem Startskript erstellt haben, verwenden Sie eine der folgenden Methoden, um eine MIG zu erstellen.

Weitere Informationen zum Erstellen von MIGs finden Sie unter Verwaltete Instanzgruppen erstellen.

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

Testen und bereinigen

Nachdem Sie eine VM oder eine MIG erfolgreich erstellt haben, prüfen Sie, ob Ihre Anwendung im Container ausgeführt wird und wie erwartet funktioniert. Informationen zur Behebung von Problemen finden Sie unter Fehlerbehebung.

Wenn die Anwendung auf den neuen VMs, die mit dem Startskript erstellt wurden, erfolgreich ausgeführt wird, können Sie die VMs und MIGs löschen, für die die eingestellte Methode zum Bereitstellen von Containern verwendet wird.

Fehlerbehebung bei Problemen mit Startskripts

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei Problemen, die bei der Verwendung von Startskripten auftreten können.

Docker-Konfiguration kann nicht gespeichert werden

Wenn Sie den Befehl docker-credential-gcr configure-docker in einem Startskript ausführen, wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Dieser Fehler tritt auf, weil docker-credential-gcr versucht, Anmeldedaten in die Datei /root/.docker/config.json zu schreiben. Das root-Dateisystem unter Container-Optimized OS ist schreibgeschützt. Sie können also nicht darauf schreiben.

Um dieses Problem zu beheben, legen Sie die Umgebungsvariable $HOME so fest, dass sie auf ein benutzerdefiniertes Home-Verzeichnis verweist, bevor Sie die docker-Befehle ausführen.

Beispiel:

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

Logs ansehen, um Probleme zu beheben

Wenn Sie Probleme beheben möchten, die beim Konfigurieren von Containern auf VMs mit einem Startskript auftreten können, sehen Sie sich die Startskript- und Containerlogs an.

• Führen Sie den folgenden Befehl aus, um die Logs des Startscripts auf der VM-Instanz aufzurufen:

  sudo journalctl | grep "startup-script"
  

• Führen Sie den Befehl docker logs aus, um Logs aus dem Docker-Container aufzurufen:

  docker logs CONTAINER_NAME
  

  Ersetzen Sie CONTAINER_NAME durch den Namen Ihres Containers.

Informationen zur Fehlerbehebung bei anderen Problemen finden Sie in den folgenden Dokumenten:

• Cloud Logging – Übersicht
• Cloud Logging mit Container-Optimized OS verwenden
• Fehlerbehebung für den Docker-Daemon
• Fehlerbehebung und Diagnose
• Fehlerbehebung bei Terraform
• Fehlerbehebung beim Ausführen eines einfachen Webservers
• Network Address Translation mit Public NAT einrichten und verwalten

cloud-init mit Container-Optimized OS verwenden

Sie können cloud-init, eine branchenübliche und plattformübergreifende Lösung, verwenden, um Container auf VMs bereitzustellen, auf denen Container-Optimized OS ausgeführt wird. Mit diesem Tool können Sie benutzerdefinierte Konfigurationen während der VM-Erstellung oder beim Starten der VM ausführen. Weitere Informationen finden Sie unter cloud-init mit dem Cloud-Konfigurationsformat verwenden.

Verwaltete Dienste für die Containerbereitstellung verwenden

In diesem Abschnitt werden die von Cloud de Confiance bereitgestellten verwalteten Dienste beschrieben, mit denen Sie Container bereitstellen können.

Cloud Run

Cloud Run ist eine gute Option für zustandslose Containeranwendungen und kleine bis mittelgroße Jobs.

Zu den wichtigsten Funktionen von Cloud Run gehören:

• Sie können festlegen, dass CPUs nur während der Anfrageverarbeitung oder immer zugewiesen werden.
• Sie können eine zustandslose Containeranwendung ausführen oder einen Job einmalig, nach einem Zeitplan oder als Teil eines Workflows ausführen.
• Sie können Zeitlimits für jede Anfrage oder Aufgabe konfigurieren.
• Er ist hoch skalierbar und sicher.
• Sie bietet integriertes Load-Balancing und Autoscaling.

Weitere Informationen zum Bereitstellen von Containern in Cloud Run finden Sie unter Container-Images in Cloud Run bereitstellen.

Batch

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batchverarbeitungsarbeitslasten auf Cloud de Confiance -Ressourcen planen, in die Warteschlange stellen und ausführen können. Es wurde für die Ausführung von parallelisierbaren Batcharbeitslasten entwickelt, einschließlich der in Containern verpackten.

Weitere Informationen zum Bereitstellen von Containern in Batch finden Sie in den folgenden Dokumenten:

• Jetzt starten
• Einfachen Job erstellen und ausführen

GKE

Wenn Sie komplexe Anwendungen, Mikrodienste und einen kontinuierlichen Betrieb ausführen und eine detaillierte Steuerung und Skalierbarkeit benötigen, ist Google Kubernetes Engine (GKE) die beste Lösung. Weitere Informationen zum Bereitstellen von Containern in GKE finden Sie in den folgenden Dokumenten:

• GKE – Übersicht
• Kurzanleitung: Anwendung in einem GKE-Cluster bereitstellen
• Container-Webanwendung bereitstellen

Support anfordern

Wenn Sie Fragen zum Migrationsprozess haben oder Unterstützung benötigen, lesen Sie die FAQs oder wenden Sie sich an den Cloud de Confiance -Support.