VM の作成時に Compute Engine インスタンスにコンテナをデプロイするコンテナ起動エージェントは非推奨になりました。
このドキュメントでは、VM の作成時に作成したコンテナを他の Trusted Cloud by S3NS サービスに移行する計画を立てる方法について説明します。
全般情報
- Compute Engine のコンテナ起動エージェントとは何ですか?
- コンテナ起動エージェントを使用すると、VM の作成時に Compute Engine インスタンスまたはマネージド インスタンス グループ(MIG)内のインスタンスにコンテナをデプロイして構成し、Docker コンテナを起動できます。
- コンテナ スタートアップ エージェントが非推奨になったのはなぜですか?
お客様からのフィードバックに基づき、 Trusted Cloud by S3NS コンテナのデプロイ オプションを強化します。コンテナのデプロイでより柔軟なオプションを提供できるように、コンテナ起動エージェントは非推奨になりました。
非推奨のオプションの詳細については、VM でコンテナを構成するための非推奨のオプションをご覧ください。
- この非推奨化の主なマイルストーンは何ですか?期限までに対応しなかった場合はどうなりますか?
2026 年 7 月 31 日以降、コンテナ スタートアップ エージェントまたは
gce-container-declaration
インスタンス メタデータに依存するワークフローは機能しなくなります。2027 年 7 月 31 日以降、Google はコンテナ スタートアップ エージェントのサポートを終了します。
gce-container-declaration
メタデータを使用する実行中の VM には、これ以上の更新は提供されません。ワークロードは自己責任で実行することになり、ワークフローに影響する可能性があります。スムーズな移行を実現するため、これらの日付より前にコンテナを代替ソリューションに移行することをおすすめします。
gce-container-declaration
メタデータを使用してコンテナを直接デプロイする新しい VM または MIG を作成できなくなるのはいつですか?最初の非推奨通知から 12 か月後(2026 年 7 月 31 日)。
gce-container-declaration
メタデータを使用する VM または MIG でコンテナ デプロイを実行できなくなるのはいつですか?コンテナ スタートアップ エージェントを使用してデプロイされたワークロードのサポートは、最初の非推奨通知から 24 か月後(2027 年 7 月 31 日)に終了します。
cloud-init
を使用して VM でコンテナを実行しています。今回の変更の影響はありますか?いいえ。この非推奨は、
cloud-init
を使用して構成された VM には影響しません。インスタンスの構成には引き続きcloud-init
を使用できます。詳細については、Cloud Config で cloud-init を使用するをご覧ください。- 今回の変更の影響があるかどうかを確認するにはどうすればよいですか?
コンテナ起動エージェントを使用するか、
gce-container-declaration
を指定して、VM の作成中に VM にコンテナをデプロイする場合は、この非推奨の影響を受けます。プロジェクトで影響を受けるインスタンスがあるかどうかを確認するには、次の gcloud CLI コマンドを実行します。gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"
このコマンドは、
gce-container-declaration
メタデータキーを含むプロジェクト内のすべての VM インスタンスのリストを返します。メタデータキーは、非推奨の範囲内の VM を一意に識別します。複数のプロジェクトを使用している場合は、アクティブなすべてのプロジェクトでコマンドを実行します。プロジェクトのメタデータの表示の詳細については、メタデータのドキュメントをご覧ください。
確認する特定のインスタンスがある場合は、次の gcloud CLI コマンドを実行します。
gcloud compute instances describe VM_NAME
VM_NAME は、VM インスタンスの名前に置き換えます。このコマンドは、メタデータなど、特定のインスタンスのすべての情報を提供します。コマンド出力に
gce-container-declaration
メタデータキーが表示された場合、VM はこの変更の影響を受けます。- 移行中にプロジェクトのセキュリティやプライバシーが侵害されるリスクはありますか?
いいえ。セキュリティとプライバシーは、Google のあらゆる取り組みの基盤です。Google のスクリプトまたはマネージド ソリューションを使用する場合は、要件に合わせて特定のセキュリティ設定とプライバシー設定を柔軟に構成できます。詳細については、移行ガイドをご覧ください。
代替ソリューションも
- Compute Engine のコンテナに推奨される代替ソリューションは何ですか?また、要件に合ったソリューションを選択するにはどうすればよいですか?
コンテナの移行には、次のいずれかの方法を選択できます。
- VM または MIG にコンテナのデプロイを続行する場合、テストと開発用にコンテナを実行する場合、または単一の VM で構成されるワークロードを実行する場合は、起動スクリプトまたは cloud-init を使用します。
- ステートレス コンテナ アプリケーションと小規模から中規模のジョブがある場合は、Cloud Run を検討してください。起動スクリプトを使用することもできます。
- コンテナが明確な終了状態を持ち、追加のコンピューティング リソースを必要とするバッチジョブである場合は、Batch を検討してください。起動スクリプトを使用することもできます。
- 高度な制御とスケーラビリティが必要な場合や、他のオプションでは要件を満たせない場合は、GKE の使用を検討してください。
移行オプションの詳細なガイダンスと推奨事項については、移行ガイドをご覧ください。
- 起動スクリプトを使用するのではなく、Cloud Run、GKE、Batch などのマネージド サービスへの移行を検討すべき理由は何ですか?
Google Kubernetes Engine、Cloud Run、Batch などのコンテナ ソリューションへの移行をご検討ください。これらのマネージド サービスは、スケーラビリティ、柔軟性、高度な管理機能の強化など、従来の VM ベースのデプロイよりも大きなメリットがあります。
主なメリットは次のとおりです。
- 管理オーバーヘッドを削減する: フルマネージド サービスとして、Trusted Cloudは基盤となるインフラストラクチャ(VM、パッチ適用、スケーリング)を処理します。このアプローチにより、貴重なスタッフの時間を解放し、運用上の負担を軽減できます。
- 自動的にスケーリングして伸縮性を確保する: これらのサービスは、需要に応じてリソースを自動的に調整します。これにより、VM のオーバー プロビジョニングと比較して、リソース使用率が向上し、コストを削減できる可能性があります。
- アイドル状態の負荷でコスト効率を実現する: アイドル状態でもコストが発生する VM とは異なり、マネージド サービスはトラフィックが変動するアプリケーションやトラフィックが少ないアプリケーションでコスト効率を高めることができます。
- 無料枠の利用: GKE、Cloud Run、Batch には無料枠が用意されています。これにより、小規模なワークロードの実行やテストを無料で行うことができます。
移行の詳細なガイダンスについては、移行ガイドをご覧ください。
- 代替ソリューションの費用はそれぞれどのくらいですか?現在の設定と比較してどうですか?
コンテナ デプロイの起動スクリプトまたは cloud-init: 起動スクリプトまたは
cloud-init
を直接置き換えても、Compute Engine の費用が本質的に変わることはありません。基盤となる VM リソースの料金は引き続き発生します。マネージド サービス: Cloud Run や Batch などのサービスに移行すると、特に使用量が変動するアプリケーションで費用を削減できます。アイドル状態でも課金される VM とは異なり、これらのマネージド サービスはより効率的です。また、無料枠を使用すると、小規模な一時的なワークロードの費用をさらに削減できます。
詳細については、コンテナのデプロイ オプションを比較するをご覧ください。料金は、選択したサービスと特定の構成によって異なります。正確な見積もりについては、料金計算ツールをご利用ください。
- この非推奨は、Container-Optimized OS イメージが非推奨になることを意味しますか?また、Compute Engine VM で Docker を実行する場合は、独自の VM テンプレートを構成する必要がありますか?
いいえ。Container-Optimized OS イメージ自体は非推奨になりません。この変更は、Container-Optimized OS を使用する VM でコンテナを起動する方法に関するものです。新しいバージョンの Container-Optimized OS では、konlet がサポートされなくなります。これは、
gce-container-declaration
メタデータキーを使用してコンテナを起動する起動エージェントです。つまり、Container-Optimized OS イメージは引き続き利用可能で、サポートされます。ただし、gce-container-declaration
メタデータキーを使用する代わりに、起動スクリプトまたはcloud-init
構成を使用してコンテナをデプロイするように VM を更新する必要があります。
移行プロセス
- コンテナを代替ソリューションに移行する際の推奨アプローチは何ですか?
移行に向けて、次の手順を行うことをおすすめします。
- オプションを理解する: 移行ガイドを確認して、コンテナを実行する代替方法を検討します。
- 移行を早めに計画する: スムーズな移行を確実に行うため、現在のコンテナ デプロイの移行計画を 2026 年 7 月 31 日より前に開始してください。
- 新しいワークロードの準備: VM または MIG へのコンテナの直接デプロイはできなくなるため、新しいコンテナ ワークロードが 2026 年 7 月 31 日までに代替ソリューションで実行できるよう準備してください。
- 最終移行期限: 直接デプロイ方法が完全に廃止される 2027 年 7 月 31 日までに、既存のすべてのコンテナ ワークロードを代替ソリューションに移行してください。
- 推奨ソリューションのいずれかに移行する必要がありますか?それとも、使用できる代替ソリューションはありますか?
Google は、ビジネスニーズに沿った、アクティブにサポートされているソリューションを柔軟に採用できるようサポートします。最適なオプションを選択するには、移行ガイドなどのリソースをご利用ください。
- 移行プロセスの一環としてデータのバックアップまたはエクスポートが必要ですか?
データのバックアップやエクスポートは、データの安全性とビジネス継続性のために常に重要なベスト プラクティスですが、この移行プロセスでは必須の手順ではありません。
- 代替手段への移行にはどれくらいの時間がかかりますか?また、所要時間に影響する要因はありますか?
コンテナ デプロイの起動スクリプト: 起動スクリプトを使用した初期設定とテストには、1 ~ 2 時間ほどかかります。以降のデプロイは、それぞれ数分で完了します。
マネージド サービス: サーバーレスでフルマネージドの PaaS サービスである Cloud Run、Batch、GKE などのTrusted Cloud by S3NS ソリューションを選択すると、時間と労力の初期投資が大きくなる可能性があります。これは、インフラストラクチャを管理する VM 中心(IaaS)のアプローチから、プラットフォームがその多くを処理する PaaS モデルへの根本的な変化によるものです。この適応には、アプリケーションをステートレスにするなどの変更が必要になる場合がありますが、長期的なメリットとして、運用効率、スケーラビリティ、費用対効果が大幅に向上する可能性があります。
この移行のガイダンスについては、移行ガイドをご覧ください。
- 代替への移行を選択した場合、 Trusted Cloud by S3NS プロジェクト、VM、サービス、アプリで中断やダウンタイムが発生しますか?
一般に、推奨される代替ソリューションへの移行は、ダウンタイムのないプロセスになるように設計されています。
Compute Engine VM で長時間実行されるコンテナを移行する場合は、中断を避けるため、代替構成で新しい VM を設定し、テスト後にトラフィックを切り替えることをおすすめします。
- この移行は Terraform 構成にどのような影響を与えますか?
Terraform などの自動化を使用して、
gce-container-declaration
メタデータキーを明示的に設定してコンテナを含む VM または MIG を作成または更新している場合、ワークフローは 2026 年 7 月 31 日に機能しなくなります。中断を回避するには、コンテナ デプロイの起動スクリプトを含めるように構成を更新し、gce-container-declaration
メタデータキーへの依存関係を削除する必要があります。この変更を実装する方法の詳細については、VM の作成時に VM にデプロイされたコンテナを移行するをご覧ください。
サポートの利用
- 移行プロセスについて質問がある場合は、Compute Engine のどこに問い合わせればよいですか?
- ご不明な点やサポートが必要な場合は、Google Cloud サポートまでお問い合わせください。
- 移行をサポートし、技術的なガイダンスを提供するリソースはありますか?
- 移行プロセスについては、この FAQ、移行ガイド、Google Cloud サポートをご利用ください。