VM の作成時に VM にデプロイされたコンテナを移行する

Compute Engine のコンテナ起動エージェントは非推奨になりました。このエージェントを使用すると、VM の作成時に Compute Engine インスタンスにコンテナをデプロイできます。

このドキュメントでは、VM またはマネージド インスタンス グループ（MIG）でスタートアップ エージェントが作成した既存のコンテナを他のGoogle Cloud サービスに移行する方法について説明します。

要件に基づいて、次のいずれかのオプションを選択して、非推奨の方法で VM にデプロイされたコンテナを移行します。

• 個々の VM と MIG でコンテナの実行を継続する場合は、起動スクリプトまたは cloud-init を使用します。
• ステートレス コンテナ アプリケーションと小規模から中規模のジョブがある場合は、Cloud Run を使用します。
• コンテナが明確な終了状態を持ち、追加のコンピューティング リソースを必要とするバッチジョブの場合は、Batch を使用します。
• 高度な制御とスケーラビリティが必要な場合や、他のオプションで要件を満たせない場合は、Google Cloud 上の GKE を使用します。

その他のユースケースと代替ソリューションについては、コンテナのデプロイ オプションを比較するをご覧ください。

VM でコンテナを構成するための非推奨のオプション

VM の作成時に VM でコンテナを構成すると、Compute Engine はコンテナ起動エージェントを使用してインスタンスの gce-container-declaration メタデータキーを生成します。このキーにはコンテナ情報が格納されます。コンテナ起動エージェントは非推奨になったため、gce-container-declaration メタデータキーにコンテナ情報を保存できなくなりました。

VM または MIG にコンテナをデプロイする次のオプションでは、コンテナ スタートアップ エージェントを使用して VM 上のコンテナを構成します。

非推奨のコンテナ メタデータを使用するインスタンスを特定する

プロジェクト内のインスタンスで非推奨のコンテナ メタデータが使用されているかどうかを確認するには、gce-container-declaration メタデータ キーと値を持つインスタンスを一覧表示する次の Google Cloud CLI コマンドを実行します。

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

このコマンドは、構成されたプロジェクト内の gce-container-declaration メタデータキーを含むすべての VM インスタンスのリストを返します。メタデータキーは、非推奨のスコープ内の VM を一意に識別します。複数のプロジェクトを使用している場合は、アクティブなすべてのプロジェクトでこのコマンドを実行します。

検証する特定のインスタンスがある場合は、次の Google Cloud CLI コマンドを実行します。

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

VM_NAME は、検証する VM インスタンスの名前に置き換えます。

メタデータの表示の詳細については、メタデータを表示してクエリするをご覧ください。

コンテナのデプロイ オプションを比較する

次の表に、VM でコンテナを実行するユースケースの概要と、ワークロードの移行に推奨される代替コンテナ ソリューションを示します。

Compute Engine コンテナ起動エージェントから代替ソリューションに移行する場合は、次の必要な変更と、それらを実装する際の労力を考慮してください。

• Container-Optimized OS を実行する VM: VM とコンテナ ランタイムのセットアップ、構成、セキュリティ、メンテナンスの完全な所有権を取得します。これには、起動スクリプトまたは cloud-init を使用したスクリプト作成が伴うことがよくあります。
• Cloud Run または Batch: アプリケーションがステートレスであり、リクエスト駆動型またはジョブベースの実行モデルに適合していることを確認します。このアプローチでは、外部の状態管理サービスと連携するようにアプリケーションを適応させる必要があります。
• GKE: Kubernetes の原則を採用し、Kubernetes マニフェスト ファイルを使用してワークロードを定義し、クラスタ リソースを管理します。

起動スクリプトを使用して VM にコンテナをデプロイする

起動スクリプトを使用して、VM で基本的なコンテナを実行できます。

起動スクリプトを使用してコンテナを構成する場合は、次の点を考慮してください。

• 基本的なシナリオでは、起動スクリプトを使用できます。高度な構成については、cloud-init の使用をご検討ください。
• 起動スクリプトを使用して構成されたコンテナを含む新しい VM を作成するため、既存の VM にデプロイされたワークロードの移行を計画する必要があります。
• トラフィックをコンテナを含む新しく作成した VM に転送する前に、すべてが想定どおりに動作することをテストして確認します。

VM を作成し、VM または MIG にコンテナをデプロイするには、次の操作を行います。

1. VM メタデータの現在のコンテナを起動スクリプト コマンドにマッピングする
2. 既存のメタデータ構成に基づいて起動スクリプトを作成する
3. 起動スクリプトを使用して VM を作成するまたは起動スクリプトを使用して MIG を作成する。

コンテナ メタデータを docker run コマンドにマッピングする

VM メタデータまたは gcloud フラグを docker run 引数にマッピングし、VM を作成するための起動スクリプトに含めることができます。

一部の gcloud フラグは VM メタデータに直接変換されます。これらのフラグは docker run フラグに直接変換されます。VM に既存のコンテナがある場合は、VM メタデータ構成を読み取り、同等の docker run コマンドを使用して起動スクリプトをビルドできます。

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

出力は次のようになります。

  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'

次の表を使用して、既存の仕様を docker run コマンドにマッピングします。

起動スクリプトの例

次の例は、起動スクリプトに docker コマンドを含める方法を示しています。

• 例 1: Container-Optimized OS に基づく VM でスタンドアロン コンテナを実行します。

• 例 2: Container-Optimized OS に基づく VM でウェブサーバー コンテナを実行します。

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

# Run docker container from image in docker hub
docker run \
  docker.io/library/busybox \
  echo "hello world!"

#!/bin/bash

# Enable incoming traffic for TCP protocol
sudo iptables -A "INPUT" -p "tcp" -j "ACCEPT"
sudo iptables -A "FORWARD" -p "tcp" -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

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

コンテナのデプロイに関するその他の構成オプション

このセクションでは、VM にコンテナをデプロイするための追加の構成パラメータについて説明します。

これらのオプションの詳細については、コンテナを実行する際のオプションの構成をご覧ください。

Artifact Registry イメージへのアクセス

gcr.io または pkg.dev からコンテナ イメージにアクセスする必要がある場合は、Container-Optimized OS にプリインストールされている docker-credential-gcr ツールを使用して、Docker の Artifact Registry への認証を構成します。コンテナを実行する前に、次のコマンドを実行します。

  # 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

詳細については、Docker 用の Artifact Registry に対する認証を構成するをご覧ください。

ロギングを構成する

VM で ロギング エージェントを有効にすることで、Cloud Logging を使用することをおすすめします。

または、ロギング ドライバを変更する場合は、docker run コマンドに --log-driver パラメータを含めることができます。

  # Enable Cloud Logging
  --log-driver=gcplogs

詳細については、Container-Optimized OS での Cloud Logging の使用をご覧ください。

内部ファイアウォールを構成する

Container-Optimized OS はデフォルトで受信トラフィックを拒否するため、そのトラフィックを許可する iptables ルールを追加する必要があります。これらのコマンドは、ホスト オペレーティング システムの内部ファイアウォールを構成します。また、そのトラフィックを新しい VM に許可するように Virtual Private Cloud ファイアウォールを構成する必要があります。

詳細については、VPC ファイアウォール ルールを使用するをご覧ください。

  # Enable all incoming traffic for TCP protocol
  iptables -A "INPUT" -p "tcp" -j "ACCEPT"
  iptables -A "FORWARD" -p "tcp" -j "ACCEPT"

  # Enable all incoming traffic for UDP protocol
  iptables -A "INPUT" -p "udp" -j "ACCEPT"
  iptables -A "FORWARD" -p "udp" -j "ACCEPT"

  # Enable all incoming traffic for ICMP protocol
  iptables -A "INPUT" -p "icmp" -j "ACCEPT"
  iptables -A "FORWARD" -p "icmp" -j "ACCEPT"

詳細については、ホスト ファイアウォールの構成をご覧ください。

ボリュームをコンテナにアタッチする

ボリュームがコンテナにアタッチされている場合、コンテナのメタデータには volumes エントリと volumeMounts 配列が含まれます。volumes のエントリの name は volumeMounts のエントリの名前に対応し、その逆も同様です。収集するボリュームごとに、volumes または volumeMounts エントリから必要な情報を収集します。

コンテナにボリュームがアタッチされていない場合は、このセクションをスキップして、起動スクリプトを使用して VM を直接作成できます。

tmpfs ファイル システムをマウントする

  # generic command
  --tmpfs <mount-path>[:opts]

  # for our example
  --tmpfs tmpfs-mount-path

ディレクトリまたはホストパスのマウント

  # generic command
  --mount type=bind,source=HOSTPATH,target=MOUNTPATH[,readonly]

  # for our example
  --mount type=bind,source=directory-host-path,target=directory-mount-path,readonly

永続ディスクをコンテナにマウントする

ディスクをコンテナにマウントするには、追加の手順が必要です。ディスクをマウントするには、まず VM にマウントしてから、そのディスクをコンテナにマウントします。

1. ディスクを VM にマウントするには、次のコマンドを実行します。

   #!/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-data" # This is where the disk will be mounted on the VM
   
   # 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. ディスクを VM にマウントしたら、docker run コマンドで --mount フラグを追加して、ディスクをコンテナにマウントします。

   --mount type=bind,source="${HOST_MOUNT_POINT}",target=/disk,readonly
   

起動スクリプトを使用して VM を作成する

コンテナ構成で起動スクリプトを作成したら、この起動スクリプトを使用して VM を作成します。

起動スクリプトの使用の詳細については、Linux VM での起動スクリプトの使用をご覧ください。

    gcloud compute instances create VM_NAME \
        --zone=ZONE \
        [--image=IMAGE | --image-family=IMAGE_FAMILY] \
        --image-project=IMAGE_PROJECT \
        IMAGE_FLAG \
        --machine-type=MACHINE_TYPE \
        --metadata-from-file=startup-script=STARTUP_SCRIPT_FILE

  # Configuration Variables
  PROJECT_ID="my_project_id"
  REGION="us-central1"
  ZONE="us-central1-c"
  INSTANCE_NAME="instance-startup-script"
  STARTUP_SCRIPT_PATH="./startup.sh"

  # Disk and Policy Configuration
  RESOURCE_POLICY_NAME="disk-resource-policy"
  DISK_DEVICE_NAME="my-persistent-disk"

  # Derived Variables (do not change)
  RESOURCE_POLICY_PATH="projects/${PROJECT_ID}/regions/${REGION}/resourcePolicies/${RESOURCE_POLICY_NAME}"

  # Create the VM instance, attach the boot disk with a resource policy,
  # Attach a secondary read-only disk, and runs a startup script.
  gcloud compute instances create "${INSTANCE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${ZONE}" \
    --machine-type="e2-medium" \
    --scopes=devstorage.read_only,logging.write,monitoring.write,servicecontrol \
    --image-family="cos-stable" \
    --image-project="cos-cloud" \
    --metadata-from-file=startup-script="${STARTUP_SCRIPT_PATH}" \
    --create-disk=boot=yes,disk-resource-policy="${RESOURCE_POLICY_PATH}" \
    --disk=name="${DISK_DEVICE_NAME}",mode=ro
 

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"
    }
  }
  attached_disk {
    device_name = "my-persistent-disk"
    mode = "READ_WRITE"
  }
  network_interface {
    network = "default"
  }

  metadata_startup_script = <<EOF
#!/bin/bash
docker pull docker.io/nginx:latest
docker rm -f my-nginx || true
docker run -d -p 80:80 --name my-nginx docker.io/nginx:latest
EOF
}

起動スクリプトを使用して MIG を作成する

起動スクリプトを使用してインスタンス テンプレートを作成したら、次のいずれかの方法で MIG を作成します。

MIG の作成の詳細については、マネージド インスタンス グループを作成するをご覧ください。

  # Create the persistent disk
  gcloud compute disks create my-persistent-disk \
    --region=us-central1 \
    --replica-zones=us-central1-a,us-central1-b \
    --size=20GB

  # 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 \
      --disk=name=my-persistent-disk,device-name=my-persistent-disk,mode=rw,boot=no \
      --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
}
disk {
  source_image = ""
  auto_delete  = false
  boot = false
  device_name = "my-persistent-disk"
  disk_size_gb = 20
}
network_interface {
  network = "default"
}
metadata_startup_script = <<EOF
  #!/bin/bash
  docker pull docker.io/nginx:latest
  docker rm -f my-nginx || true
  docker run -d -p 80:80 --name my-nginx docker.io/nginx:latest
  EOF
lifecycle {
  create_before_destroy = true
}
}
resource "google_compute_region_disk" "my_persistent_disk" {
name = "my-persistent-disk"
region = "us-central1"
replica_zones = ["us-central1-a", "us-central1-b"]
size = 20
}

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
}

シャットダウン スクリプトを使用してコンテナ VM をシャットダウンする

コンテナを正常にシャットダウンするようにシャットダウン スクリプトを設定できます。たとえば、Docker コンテナを停止するには、次のようなシャットダウン スクリプトを追加します。

     #!/bin/sh
     docker stop my_container
   

テストとクリーンアップ

VM または MIG が正常に作成されたら、アプリケーションがコンテナで実行され、想定どおりに動作していることを検証します。問題を解決するには、トラブルシューティングをご覧ください。

スタートアップ スクリプトを使用して作成した新しい VM でアプリケーションが正常に実行されている場合は、コンテナの非推奨のデプロイ方法を使用する VM と MIG を削除できます。

トラブルシューティング

コンテナの移行中に発生する可能性のある問題のトラブルシューティングについては、次のドキュメントをご覧ください。

• Cloud Logging の概要
• Container-Optimized OS での Cloud Logging の使用
• Docker デーモンのトラブルシューティング
• トラブルシューティングと診断
• Terraform のトラブルシューティング
• 基本的なウェブサーバーの実行時のトラブルシューティング
• プライベート VM のインターネット接続の構築

Container-Optimized OS で cloud-init を使用する

業界標準のクロス プラットフォーム ソリューションである cloud-init を使用して、Container-Optimized OS を実行している VM にコンテナをデプロイできます。このツールを使用すると、VM の作成時または起動時にカスタム構成を実行できます。詳細については、Cloud 構成形式での cloud-init の使用をご覧ください。

コンテナのデプロイにマネージド サービスを使用する

このセクションでは、コンテナのデプロイに使用できる Google Cloud が提供するマネージド サービスについて説明します。

Cloud Run

Cloud Run は、ステートレス コンテナ アプリケーションや小規模から中規模のジョブに適しています。

Cloud Run の主な機能は次のとおりです。

• リクエストの処理中にのみ CPU を割り当てるか、常に CPU を割り当てるかを選択できます。
• ステートレス コンテナ アプリケーションを実行したり、ジョブを 1 回限りで実行したり、スケジュールに沿って実行したり、ワークフローの一部として実行したりできます。
• リクエストまたはタスクごとにタイムアウトを構成できます。
• スケーラビリティとセキュリティに優れています。
• ロード バランシングと自動スケーリングが統合されています。

Cloud Run へのコンテナのデプロイの詳細については、Cloud Run へのコンテナ イメージのデプロイをご覧ください。

バッチ

Batch は、 Google Cloud リソースでバッチ処理ワークロードをスケジュールし、キューに入れて実行するフルマネージド サービスです。コンテナにパッケージ化されたワークロードなど、バッチ形式の並列処理可能なワークロードを実行するように設計されています。

Batch へのコンテナのデプロイの詳細については、次のドキュメントをご覧ください。

• 使ってみる
• 基本ジョブを作成して実行する

Google Kubernetes Engine

複雑なアプリケーション、マイクロサービス、継続的な運用を実行しており、きめ細かい制御とスケーラビリティが必要な場合は、Google Kubernetes Engine（GKE）が最適です。GKE へのコンテナのデプロイの詳細については、次のドキュメントをご覧ください。

• GKE の概要
• クイックスタート: アプリを GKE クラスタにデプロイする
• コンテナ化されたウェブ アプリケーションのデプロイ

サポートを受ける

移行プロセスについてご不明な点がある場合やサポートが必要な場合は、よくある質問をご覧になるか、Google Cloud サポートにお問い合わせください。