Docker コンテナをデプロイして起動するように仮想マシン（VM）インスタンスまたはインスタンス テンプレートを構成できます。Compute Engine は、VM の起動時に、Docker がインストールされた最新の Container-Optimized OS（COS）イメージを使用してコンテナを起動します。
準備
- コンテナについて理解を深めるために、コンテナの概要とその利点をお読みください。
- Docker について理解を深めるために、Docker のドキュメントをお読みください。
- Container-Optimized OS のドキュメントをお読みください。
- マネージド インスタンス グループ（MIG）のドキュメントをお読みください。
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init - Set a default region and zone.
- コンテナを実行する VM の管理は、Compute Engine インフラストラクチャの構成や管理に他の VM を扱う場合と同じように行います。
- コンテナを実行するマネージド インスタンス グループ（MIG）を使用して、自動スケーリング、自動修復、ローリング更新、マルチゾーンのデプロイ、ロード バランシングなどの機能を提供するスケーラブルなサービスを構築します。
- コンテナをデプロイした VM の管理にも、Google Cloud CLI や Compute Engine API など、使い慣れたプロセスやツールを使用できます。
- マイクロサービスを大量に実行する
- コンテナの起動時間を短縮する
- 自動アップグレード、ノードの自動修復、自動スケーリングなど、Kubernetes の自動オーケストレーションを活用する
- 起動スクリプトまたは cloud-init を使用して、VM の起動時にソフトウェアをデプロイする。
- ソフトウェアがプリインストールされたカスタム ブートディスク イメージを作成する。
- アプリと必要なライブラリを Docker イメージにバンドルし、そのイメージを Artifact Registry や Docker Hub などのサードパーティ レジストリに公開します。
- VM インスタンスまたは MIG のインスタンス テンプレートを作成するときに、Docker イメージ名と
docker run構成を指定します。 - Compute Engine は、Google が提供する Container-Optimized OS イメージを使用する VM インスタンスを作成します。このイメージには、コンテナの起動に必要な Docker ランタイムと追加のソフトウェアが含まれています。
- Compute Engine は、コンテナの設定をインスタンス メタデータの
gce-container-declarationメタデータキーに保存します。 - VM が起動すると、Container-Optimized OS イメージは、インスタンスのメタデータに格納されている
docker runコマンド構成を使用し、リポジトリからコンテナ イメージをプルして、コンテナを起動します。 - 各 VM インスタンスにデプロイできるコンテナは 1 つのみです。1 つの VM インスタンスに複数のコンテナをデプロイする必要がある場合は、Google Kubernetes Engine を検討してください。
公開リポジトリ、またはアクセス可能な限定公開の Artifact Registry または Container Registry リポジトリからのみコンテナをデプロイできます。他の非公開リポジトリはサポートされていません。
限定公開レジストリの権限については、Artifact Registry または Container Registry のアクセス制御のドキュメントをご覧ください。
VM インスタンスのポートをコンテナのポートにマッピング（Docker の
-pオプション）することはできません。コンテナへのアクセスを有効にするには、コンテナポートの公開をご覧ください。このデプロイ方法で使用できるのは、Container-Optimized OS イメージのみです。
この機能を使用できるのは Google Cloud コンソールまたは Google Cloud CLI のみです。API では使用できません。
- Docker イメージを Artifact Registry にアップロードします。
- Docker Hub や他のレジストリで一般公開されているコンテナ イメージを使用します。
[インスタンスの作成] ページに移動します。
VM の詳細を指定します。
[コンテナ] セクションで、コンテナをデプロイをクリックします。
[コンテナの構成] ページで、コンテナ イメージ名を指定し、必要に応じてコンテナの実行オプションを構成します。たとえば、コンテナ イメージとして
gcr.io/cloud-marketplace/google/nginx1:latestを指定できます。VM 作成プロセスを続行します。
- インスタンスのコンテナ宣言を更新します。更新されたコンテナ宣言をインスタンス メタデータの
gce-container-declarationメタデータキーに保存します。 - インスタンスが実行されている場合は、インスタンスを停止して再起動し、更新した構成を有効にします。インスタンスが停止している場合は、コンテナ宣言を更新し、インスタンスを停止したままにします。VM インスタンスは、VM の起動時に新しいイメージをダウンロードして、コンテナを起動します。
[VM インスタンス] ページに移動します。
更新する VM の名前をクリックします。
インスタンスの詳細ページで、[編集] をクリックします。
新しいコンテナ イメージを指定し、必要に応じてコンテナの実行オプションを更新します。
変更を保存するには、[保存して再起動] をクリックします。Compute Engine は変更を保存し、インスタンスを自動的に再起動して更新を実行します。VM が再起動すると、新しいイメージをダウンロードし、更新された構成でコンテナを起動します。
Docker イメージに基づいてインスタンス テンプレートを作成します。
新しいインスタンス テンプレートから MIG を作成します。
[インスタンス テンプレート] ページに移動します。
インスタンス テンプレートを作成するには、[インスタンス テンプレートを作成] をクリックします。
[コンテナ] で、[この VM インスタンスにコンテナ イメージをデプロイします] を選択します。
[コンテナ イメージ] で、Docker イメージ名を指定し、必要に応じてコンテナの実行オプションを構成します。たとえば、コンテナ イメージとして
gcr.io/cloud-marketplace/google/nginx1:15を指定できます。[作成] をクリックします。
- デプロイ用の新しい Docker イメージを準備します。
- コンテナベースのテンプレートを作成すると同じ方法で、新しい Docker イメージに基づいてインスタンス テンプレートを作成します。
- Managed Instance Group Updater を使用して、MIG を新しいインスタンス テンプレートに更新します。
- 新しい MIG のコンテナベースのテンプレートを作成すると同じ方法で、現在のバージョンの Docker イメージに基づいてインスタンス テンプレートを作成します。サポートされている最新バージョンの Container-Optimized OS イメージがデフォルトで使用されます。
- Managed Instance Group Updater を使用して、新しいインスタンス テンプレートで MIG を更新します。
VM_NAME: VM インスタンスの名前CONTAINER_NAME: コンテナの名前起動エージェントのログ（konlet ログとも呼ばれます）。起動エージェントはコンテナの構成を解析し、Compute Engine VM インスタンスでコンテナを起動するタスクを実行します。
Docker イベントログ。コンテナの開始イベントと停止イベントなどのコンテナ イベントをレポートします。
コンテナからのログ。コンテナ内で実行されるアプリの
STDOUTが記録されます。[VM インスタンス] ページに移動します。
起動エージェントのログを表示する VM インスタンスを選択します。
[ログ] の下の [シリアルポート 1（コンソール）] をクリックして、シリアル コンソールのログを表示します。
- SSH を使用してコンテナを含むインスタンスに接続します。
sudo journalctlコマンドを実行して、VM の起動ログとコンテナの起動ログを表示します。コンテナの起動エージェントのログ（konlet）でフィルタするには、次のコマンドを使用します。sudo journalctl -u konlet*
[VM インスタンス] ページに移動します。
起動エージェントのログを表示する VM インスタンスを選択します。
[ログ] で [Cloud Logging] をクリックして、Cloud Logging のログを表示します。
検索フィルタを入力して、起動エージェント ログを取得します。
resource.type="gce_instance" logName="projects/PROJECT_ID/logs/cos_system" jsonPayload.SYSLOG_IDENTIFIER="konlet-startup" jsonPayload._HOSTNAME="VM_NAME"
次のように置き換えます。
PROJECT_ID: インスタンスが含まれるプロジェクト IDVM_NAME: ログを取得するインスタンスの名前
PROJECT_ID: インスタンスが含まれるプロジェクト IDVM_NAME: ログを取得するインスタンスの名前- SSH を使用してコンテナを含むインスタンスに接続します。
次のフィルタを使用して
sudo journalctlコマンドを実行し、Docker イベントログを表示します。sudo journalctl -u docker-events-collector
[VM インスタンス] ページに移動します。
起動エージェントのログを表示する VM インスタンスを選択します。
[ログ] で [Cloud Logging] をクリックして、Cloud Logging のログを表示します。
次の検索フィルタを入力して、Docker イベントログを取得します。
resource.type="gce_instance" logName="projects/PROJECT_ID/logs/cos_system" jsonPayload._HOSTNAME="VM_NAME" jsonPayload.SYSLOG_IDENTIFIER="docker"
次のように置き換えます。
PROJECT_ID: インスタンスが含まれるプロジェクト IDVM_NAME: ログを取得するインスタンスの名前
PROJECT_ID: インスタンスが含まれるプロジェクト IDVM_NAME: ログを取得するインスタンスの名前[VM インスタンス] ページに移動します。
起動エージェントのログを表示する VM インスタンスを選択します。
[ログ] で [Cloud Logging] をクリックして、Cloud Logging のログを表示します。
[Cloud Logging] ページにデフォルトの検索フィルタが読み込まれます。
resource.labels.instance_idの値をコピーします。これは後で使用します。検索フィルタを更新して、コンテナのログを取得します。
resource.type="gce_instance" logName="projects/PROJECT_ID/logs/cos_containers" resource.labels.instance_id="INSTANCE_ID"
次のように置き換えます。
PROJECT_ID: インスタンスが含まれるプロジェクト IDINSTANCE_ID: ログを取得するインスタンスの ID
ログを取得するインスタンスの ID を判別します。
gcloud compute instances describe VM_NAME \ --zone ZONE \ --format="value(id)"
次のように置き換えます。
VM_NAME: ログを取得するインスタンスの名前ZONE: インスタンスが配置されているゾーン。
インスタンスのコンテナのログを表示するには、次のコマンドとフィルタを使用します。
gcloud logging read "resource.type=gce_instance AND \ logName=projects/PROJECT_ID/logs/cos_containers AND \ resource.labels.instance_id=INSTANCE_ID"次のように置き換えます。
PROJECT_ID: インスタンスが含まれるプロジェクトの ID。INSTANCE_ID: インスタンスの ID。
たとえば、次のコマンドを使用して、
my-projectに存在し、インスタンス ID が555123456789012345の COS 70 を実行している VM インスタンスの Cloud Logging の最後の 10 個のコンテナログを表示します。gcloud logging read "resource.type=gce_instance AND \ logName=projects/my-project/logs/cos_containers AND \ resource.labels.instance_id=555123456789012345" \ --limit 10- コンテナの再起動ポリシーを指定します。
- コンテナ
ENTRYPOINT（コンテナの起動時に実行されるデフォルトのコマンド）をオーバーライドします。 - コンテナの
ENTRYPOINTコマンドに引数を渡します。 - 特権モードでコンテナを実行します。
- ホスト ディレクトリまたは
tmpfsをコンテナ内のデータ ボリュームとしてマウントします。 - 環境変数を設定します。
- コンテナ ランタイムに
STDINのバッファを割り当てます。 - 疑似 TTY を割り当てます。
- コンテナを実行する際のオプションの構成について学習する。
- マネージド インスタンス グループの詳細を見る。
- Container-Optimized OS について学習する。
VM および MIG へのコンテナのデプロイを選択する
Compute Engine にコンテナをデプロイすることで、VM インフラストラクチャを調整しながらアプリのデプロイの簡素化を実現できます。
以下のような必要がある場合は、Google Kubernetes Engine へのデプロイを検討されることをおすすめします。
Compute Engine の仮想マシン（VM）ごとに個別のマイクロサービスを実行すると、コストの大部分をオペレーティング システムのオーバーヘッドが占める可能性が生じます。Google Kubernetes Engine を使用すると、VM インスタンスごとに複数のコンテナやコンテナ グループをデプロイできるので、より小さなフットプリントでより効率的にホスト VM のリソースをマイクロサービスに割り当てることができます。
Compute Engine へのコンテナのデプロイの仕組み
Compute Engine の VM インスタンスにソフトウェアをデプロイする一般的な方法は次のとおりです。
上記のどちらの方法も、アプリの構成タスクとオペレーティング システム環境の設定タスクが組み込まれています。デベロッパーは、ランタイムの依存関係を慎重に追跡管理し、解決する必要があります。たとえば、1 つの VM で実行される 2 つのアプリが同じライブラリの異なるバージョンを使用する場合は、両方のバージョンをインストールし、システム変数で参照する必要があります。
アプリがオペレーティング システムに直接デプロイされた VM インスタンス 上記の方法とは別に、コンテナにソフトウェアをデプロイし、VM インスタンスまたは MIG にコンテナをデプロイすることもできます。この場合、コンテナにはアプリケーション ソフトウェアと必要なライブラリの両方が含まれ、OS のアプリやライブラリからは切り離されています。コンテナはデプロイ環境間を簡単に移動でき、コンテナと OS 間でライブラリ バージョンの競合を解決する必要もありません。
アプリがコンテナにデプロイされている VM インスタンス 次のプロセスでは、Compute Engine にコンテナをデプロイする方法について説明します。
VM インスタンスの作成をリクエストすると、Compute Engine によって次のタスクが実行されます。
コンテナを実行する VM インスタンスまたはマネージド インスタンス グループを作成する手順 制限事項
デプロイのためのコンテナの準備
次のいずれかの方法を選択して、Compute Engine がコンテナ イメージにアクセスできるようにします。
新しい VM インスタンスへのコンテナのデプロイ
Google Cloud コンソールまたは Google Cloud CLI を使用して、コンテナを新しい VM インスタンスにデプロイできます。
コンソール
次の例では、Google 提供の Nginx Docker イメージ
https://gcr.io/cloud-marketplace/google/nginx1:latestから作成されたコンテナを VM インスタンスにデプロイします。別の Docker イメージを使用するには、下記の例で、目的のイメージを代わりに指定してください。gcloud
gcloud compute instances create-with-containerコマンドを使用します。gcloud compute instances create-with-container VM_NAME \ --container-image DOCKER_IMAGEたとえば次のコマンドは、
nginx-vmという名前の新しい VM インスタンスを作成します。この VM インスタンスは Docker イメージgcr.io/cloud-marketplace/google/nginx1:latestを起動して実行します。gcloud compute instances create-with-container nginx-vm \ --container-image gcr.io/cloud-marketplace/google/nginx1:latest詳しくは、
gcloud compute instances create-with-containerコマンドをご覧ください。Docker Hub の公開イメージを使用する場合は、常に完全な Docker イメージ名を指定する必要があります。たとえば、Apache コンテナ イメージをデプロイするには、次のイメージ名を指定します。
docker.io/httpd:2.4VM インスタンスのコンテナの更新
VM インスタンスのコンテナで実行されている Docker イメージや実行オプションの構成を更新するには、Google Cloud コンソールまたは Google Cloud CLI を使用します。
コンテナを実行する VM が更新されると、Compute Engine は次の 2 つの手順で動作します。
Console
gcloud
gcloud compute instances update-containerコマンドを使用してコンテナ宣言を更新します。次に例を示します。gcloud compute instances update-container nginx-vm \ --container-image gcr.io/cloud-marketplace/google/nginx1:latestこのコマンドは、コンテナ イメージを
gcr.io/cloud-marketplace/google/nginx1:latestに設定し、インスタンスを再起動して変更を有効にします。また、コンテナの実行オプションの構成で説明されているプロパティに対応するフラグを追加して、設定を更新できます。インスタンスが再起動した後、新しいコンテナ イメージをダウンロードして、新しい構成でコンテナを起動します。
マネージド インスタンス グループへのコンテナのデプロイ
新しいマネージド インスタンス グループ（MIG）にコンテナをデプロイするには、Google Cloud コンソールまたは Google Cloud CLI を使用できます。手順は次のとおりです。
Console
次の例では、Google 提供の Nginx（
gcr.io/cloud-marketplace/google/nginx1:15）Docker イメージからコンテナを MIG にデプロイするインスタンス テンプレートを作成します。他の Docker イメージを使用するには、次の例でgcr.io/cloud-marketplace/google/nginx1:15の代わりに目的のイメージを指定します。次に、新しいインスタンス テンプレートを使用する MIG を作成します。
gcloud
gcloud compute instance-templates create-with-containerコマンドを使用して、Docker イメージを実行するためのインスタンス テンプレートを作成します。gcloud compute instance-templates create-with-container TEMPLATE_NAME \ --container-image DOCKER_IMAGE
必要に応じて、コンテナの実行オプションを構成することもできます。
たとえば次のコマンドは、
nginx-templateという名前の新しいインスタンス テンプレートを作成します。これには、Docker イメージに関する情報が含まれます。このテンプレートから作成された VM インスタンスは、起動時に Docker イメージgcr.io/cloud-marketplace/google/nginx1:15を起動して実行します。gcloud compute instance-templates create-with-container nginx-template \ --container-image gcr.io/cloud-marketplace/google/nginx1:15次に、新しいインスタンス テンプレートを使用して MIG を作成します。
これでインスタンス テンプレートが作成されたので、そのインスタンス テンプレートを使用する MIG を作成できます。たとえば、gcloud CLI と先ほど作成した
nginx-templateを使用して MIG を作成するには、次のコマンドを実行します。gcloud compute instance-groups managed create example-group \ --base-instance-name nginx-vm \ --size 3 \ --template nginx-templateコンテナを実行しているマネージド インスタンス グループの更新
Docker イメージの新しいバージョンまたは Container-Optimized OS イメージの新しいバージョンをデプロイするには、マネージド インスタンス グループ（MIG）を更新します。
MIG をコンテナ イメージの新しいバージョンに更新する
Managed Instance Group Updater を使用して、新しいバージョンの Docker イメージを MIG にデプロイできます。
マネージド インスタンス グループの Container-Optimized OS イメージを新しいバージョンに更新する
Google では Container-Optimized OS イメージを定期的に更新しています。これらの更新を Docker イメージを変更せずに、コンテナ化された MIG に適用できます。Google Cloud コンソールまたは Google Cloud CLI を使用して、次の 2 つの手順で MIG を新しいバージョンの Container-Optimized OS イメージに更新できます。
SSH を使用したコンテナへの接続
VM 上のコンテナには、SSH を使用して接続できます。gcloud CLI を使用して、
--containerフラグを指定してgcloud compute sshを実行します。gcloud compute ssh VM_NAME --container CONTAINER_NAME
次のように置き換えます。
詳細については、
gcloud compute sshコマンドとその引数の詳細をご覧ください。Compute Engine 上のコンテナのモニタリング
Container-Optimized OS イメージを実行しているインスタンスをモニタリングするには、Node Problem Detector エージェントを使用します。このエージェントは、Cloud Monitoring と通信して、健全性関連の指標を報告します。エージェントは、Milestone 77 以降の Container-Optimized OS イメージに組み込まれています。
Milestone 88 以降のイメージを使用するコンテナでエージェントを有効にするには、カスタム メタデータ セクションを編集して、
google-monitoring-enabledをtrueに設定します。Node Problem Detector を有効にする別の方法については、ヘルス モニタリングを有効にするをご覧ください。
Node Problem Detector エージェントは、
guest/で始まる指標リストの指標をサポートしています。エージェントによって収集された指標を操作するには、Metrics Explorer にアクセスします。
ログの表示
コンテナに関連する次の 3 種類のログを表示できます。
起動エージェントのログの表示
起動エージェントのログは、シリアル コンソール内、OS イメージに含まれる
journaldシステム サービス、または Cloud Logging で表示できます。シリアル コンソールでの起動エージェントのログの表示
Console
gcloud
インスタンスのシリアルポートのログを表示するには、
get-serial-port-outputコマンドを使用します。gcloud compute instances get-serial-port-output VM_NAME
VM_NAMEは VM インスタンスの名前に置き換えます。たとえば、次のコマンドを使用すると、
nginx-vmという VM インスタンスのシリアルポート出力が表示されます。gcloud compute instances get-serial-port-output nginx-vm
journaldで起動エージェントのログを表示するLogging で起動エージェントのログを表示する
Console
gcloud
コンテナの起動エージェント ログを表示するには、適切なフィルタを設定した
gcloud logging readコマンドを使用します。gcloud logging read "resource.type=gce_instance AND \ logName=projects/PROJECT_ID/logs/cos_system AND \ jsonPayload.SYSLOG_IDENTIFIER=konlet-startup AND \ jsonPayload._HOSTNAME=VM_NAME"次のように置き換えます。
たとえば、
my-projectに存在し、COS 70 を実行しているnginx-vmという名前の VM インスタンスの最新 10 件の起動エージェント ログを Logging で表示するには、次のコマンドを使用します。gcloud logging read "resource.type=gce_instance AND \ logName=projects/my-project/logs/cos_system AND \ jsonPayload.SYSLOG_IDENTIFIER=konlet-startup AND \ jsonPayload._HOSTNAME=nginx-vm" \ --limit 10Docker イベントログの表示
journaldと Cloud Logging で Docker イベントログを表示できます。journaldで Docker イベントログを表示するLogging で Docker イベントログを表示する
Console
gcloud
適切なフィルタを設定した
gcloud logging readコマンドを使用して、Docker イベントログを表示します。gcloud logging read "resource.type=gce_instance AND \ logName=projects/PROJECT_ID/logs/cos_system AND \ jsonPayload._HOSTNAME=VM_NAME AND \ jsonPayload.SYSLOG_IDENTIFIER=docker"次のように置き換えます。
たとえば、
my-projectに存在し、COS 70 を実行しているnginx-vmという名前の VM インスタンスの最新 10 件の Docker イベントログを Logging で表示するには、次のコマンドを使用します。gcloud logging read "resource.type=gce_instance AND \ logName=projects/my-project/logs/cos_system AND \ jsonPayload._HOSTNAME=nginx-vm AND \ jsonPayload.SYSLOG_IDENTIFIER=docker" \ --limit 10コンテナのログの表示
Console
gcloud
コンテナのログを表示するには、
gcloud logging readコマンドを使用します。コンテナ用に最適化されたイメージまたはイメージ ファミリーの指定
デフォルトでは、コンテナ化された VM インスタンスまたはインスタンス テンプレートの作成には、サポートされている最新のコンテナ用に最適化されたイメージ（COS）が使用されます。このイメージは
cos-cloudプロジェクトにあります。このデフォルトは、
cos-cloudプロジェクトの別のイメージでオーバーライドできます。利用可能なイメージ ファミリーとその属性については、適切な Container-Optimized OS バージョンの選択をご覧ください。たとえば、使用するイメージが判明したら、gcloud CLI で、
--imageフラグを指定してデフォルトのコンテナ用に最適化されたイメージをオーバーライドするか、--image-familyフラグを指定して VM 作成時に指定されたファミリーから最新のイメージを取得します。次の例では、
cos-devイメージ ファミリーの最新のイメージを使用する、コンテナ化された VM インスタンスを作成します。gcloud compute instances create-with-container nginx-vm \ --image-family cos-dev \ --image-project cos-cloud \ --container-image gcr.io/cloud-marketplace/google/nginx1:1.15ファイアウォール ルールの構成
コンテナ化された VM は、ネットワークをホストモードに設定してコンテナを起動します。コンテナはホストのネットワーク スタックを共有し、ホストのインターフェースをすべて使用できます。
Google Cloud のファイアウォール ルールのデフォルトでは、VM インスタンスへのすべての受信接続がブロックされ、VM インスタンスからのすべての送信接続が許可されます。
インスタンスおよびコンテナへの受信接続を許可するには、ファイアウォール ルールを作成します。
コンテナの実行オプションの構成
コンテナを実行する場合に、次のオプションを構成できます。
コンテナを実行する際のオプションの構成をご覧ください。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-11-20 UTC。
-