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

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

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

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

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

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

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

VM の作成時にコンテナを構成すると、Compute Engine はコンテナ起動エージェントを使用して、コンテナ情報を格納する gce-container-declaration メタデータを読み取り、VM にコンテナをデプロイします。

コンテナ起動エージェントと gce-container-metadata を使用して VM または MIG にコンテナを直接デプロイする次のオプションは非推奨になりました。

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

プロジェクト内のインスタンスで非推奨のコンテナ メタデータが使用されているかどうかを確認するには、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

# 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

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

このセクションでは、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 パラメータを含めることができます。

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

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

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

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

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

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

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

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

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

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

Container-Optimized OS のディスクとファイルシステムの詳細については、ディスクとファイルシステムの概要をご覧ください。

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

空の tmpfs ファイル システムをコンテナにマウントするには、docker run コマンドで --tmpfs 引数を指定します。たとえば、キャッシュ ファイル システムを nginx コンテナにマウントするには、次のコマンドを実行します。

  # 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

tmpfs ファイル システムのマウントの詳細については、tmpfs マウントをご覧ください。

ホスト ディレクトリをマウントする

ホスト VM からコンテナにディレクトリをマウントするには、docker run コマンドで --mount 引数を指定します。

  # 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

詳細については、バインド マウントをご覧ください。

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

ディスクをコンテナにマウントするには、追加の手順が必要です。ディスクをマウントするには、まず 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-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. ディスクを VM にマウントしたら、docker run コマンドで --mount フラグを追加して、ディスクをコンテナにマウントします。

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

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

コンテナ構成を含む起動スクリプトを作成したら、この起動スクリプトを使用して Container-Optimized OS に基づく VM を作成します。Container-Optimized OS に基づいて VM を作成する方法については、公開イメージからインスタンスを作成するをご覧ください。

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

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 を作成する

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

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

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

テストとクリーンアップ

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

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

トラブルシューティング

起動スクリプトを使用して VM でコンテナを構成する際に発生する可能性のある問題のトラブルシューティングを行うには、起動スクリプトのログとコンテナのログを表示します。

• VM インスタンスで起動スクリプトのログを表示するには、次のコマンドを実行します。

  sudo journalctl | grep "startup script"
  

• Docker コンテナのログを表示するには、docker logs コマンドを実行します。

  docker logs CONTAINER_NAME
  

  CONTAINER_NAME は、実際のコンテナ名に置き換えます。

他の問題のトラブルシューティングについては、次のドキュメントをご覧ください。

• 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 の使用をご覧ください。

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

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

Cloud Run

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

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

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

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

バッチ

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

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

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

Google Kubernetes Engine

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

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

サポートを受ける

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