Migrate to Containers を使用した VM のコンテナへの移行

Last reviewed 2021-10-21 UTC

このドキュメントは、コンテナへの仮想マシンベース ワークロードの移行プランを設計し、実装を担当するクラウド アーキテクトを対象としています。このドキュメントは、Migrate to Containers を使用して、移行元の環境から Google Kubernetes Engine（GKE）または GKE Enterprise で実行されるコンテナに仮想マシン（VM）を移行する際のガイダンスとなります。移行元の環境は、オンプレミス環境、プライベート ホスティング環境、または別のクラウドで実行されていることを前提としています。

このドキュメントでは、Migrate to Containers の概要について説明します。また、コンテナへの VM の移行を計画する際に考慮すべき重要なポイントについても説明します。これは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。

このドキュメントは、Migrate to Containers を使用して、サポートされている移行元の環境から GKE または GKE Enterprise 環境に Linux や Windows などの互換性のあるオペレーティング システム（OS）が稼働している VM を移行する計画がある場合にお読みください。移行元の環境としては、次のようなものがあります。

Migrate to Containers を使用すると、以下のことを行わずに、VM ベースの既存のワークロードを GKE と GKE Enterprise コンテナに配置できます。

  • ソースコードへのアクセスを要求する
  • ワークロードを書き換える
  • ワークロードを手動でコンテナ化する

Migrate to Containers を使用した VM ベースのワークロードの移行には、次の利点があります。

  • コンテナ化された環境。次のようなメリットがあります。
  • 高密度ワークロード
  • 豊富なオーケストレーション メカニズムとポリシー管理
  • 柔軟なサービス間通信チャネル
  • 継続的インテグレーションと継続的デプロイのパイプラインの使用
  • サポートされていない OS バージョンからの移行が可能
  • VM ベースの環境の縮小と廃止

Migrate to Containers を使用した VM ベースのワークロードのコンテナへの移行は、ワークロードのモダナイゼーションでも実施できるステップの一つです。Migrate to Containers を使用して VM ベースのワークロードを移行すると、ワークロードのモダナイズに必要な高コストの書き換えが不要になります。ただし、クラウド環境で実行するように設計されたワークロードに変換されることはありません。

この移行に適した候補としては、次のようなものがあります。

  • 完全な書き換えによるモダナイゼーションができないか、コストが高すぎるワークロード
  • 変更すると破損する可能性がある不明な依存関係のあるワークロード
  • メンテナンスはされているが、積極的に開発が行われていないワークロード
  • メンテナンスされていないワークロード
  • ソースコードにアクセスできないワークロード

Migrate to Containers は、いくつかの方法で使用できます。たとえば、Google Cloud コンソールからアクセスできます。移行プロセスを自動化し、既存のツールチェーンと統合する必要がある場合は、コマンドライン インターフェースと Migrate to Containers の Kubernetes カスタム リソース定義（CRD）を使用します。

Migrate to Containers インターフェースの詳細については、API とリファレンス | Migrate to Containers をご覧ください。

このドキュメントは、次のドキュメントを読み、その内容を理解していることを前提としています。

Google Cloud への移行の設計

VM を移行元の環境から Google Cloud 内で実行されるコンテナに移行するには、Google Cloud への移行のシリーズで説明されているフレームワークに従うことをおすすめします。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

上の図に示すフレームワークは、4 フェーズで構成されています。

  1. 評価。このフェーズでは、移行元の環境を評価し、Google Cloud に移行するワークロードを評価して、どの VM が各ワークロードをサポートするのかを評価します。
  2. 計画。このフェーズでは、リソース階層のプロビジョニングやネットワーク アクセスの設定など、Migrate to Containers の基本インフラストラクチャを作成します。
  3. デプロイ。このフェーズでは、Migrate to Containers を使用して、VM を移行元の環境から GKE または GKE Enterprise に移行します。
  4. 最適化。このフェーズでは、クラウドのテクノロジーと機能を最大限に活用します。

移行元の環境とワークロードの評価

評価フェーズでは、移行元の環境と移行する VM ベースのワークロードに関する情報を収集します。これは、移行と移行先の環境の両方で必要なリソースのサイズを適切に設定するのに役立ちます。

評価フェーズでは、次のことを行います。

  1. ワークロードの包括的なインベントリを作成する。
  2. プロパティと依存関係に応じてアプリケーションを分類する。
  3. チームを Google Cloud でトレーニングして教育する。
  4. Google Cloud 上で実験と概念実証を作成する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. 最初に移行するワークロードを選ぶ。

以降のセクションは、Google Cloud への移行: ワークロードの評価と調査の情報に基づいていますが、Migrate to Containers でコンテナに移行する VM ベースのワークロードの評価については固有の情報を提供しています。

インベントリを構築する

移行のスコープを設定するには、現在の VM ベースの環境を把握する必要があります。環境を把握するには、ワークロードとその依存関係に関する情報を収集します。

アプリのインベントリを作成するでは、VM ベース環境のワークロードとその依存関係のインベントリを作成する方法について説明しています。そのガイダンスに沿ってインベントリを作成してから、このドキュメントの手順を続けてください。

ワークロードとその依存関係のインベントリを作成したら、インベントリを修正します。Migrate to Containers で VM ベースのワークロードを移行するときに、組織で重要となる側面と機能を評価します。

ワークロードのインベントリを完了するには、次の点を考慮してください。

  • 移行元の環境。Migrate to Containers は、次のような異なる移行元環境からの VM の移行をサポートしています。

    • Compute Engine
    • VMware vSphere
    • Microsoft Azure VM
    • Amazon EC2

    ワークロードを移行できるように Migrate to Containers を正しく設定するには、移行元の環境を評価する必要があります。

  • VM で実行中のオペレーティング システム: VM で実行中のオペレーティング システムとそのライセンスに関する情報を収集し、オペレーティング システムと Migrate to Containers の互換性を維持します。Migrate to Containers がサポート対象外の OS を実行している場合は、サポートされているバージョンにアップグレードするか、OS を Migrate to Containers がサポートする OS に変更することを検討します。

  • VM 内のワークロード: 各 VM にデプロイされているワークロードを評価します。次に、ワークロード間の依存関係をマッピングします。また、ワークロードと外部サービス間の依存関係もマッピングします。次に、ワークロードの構成ソースに関する情報を収集します。たとえば、ワークロードを動的に構成するために、環境変数、分散構成システム、またはメタデータ サーバーを使用しているかどうか。また、ワークロードがロギング システムにどのように情報を送信するかも評価します。

  • Migrate to Containers の適合性スコア: ワークロードが Migrate to Containers を使用した移行に適しているかどうかを評価します。Migrate to Containers は、VM で適合性スコアを計算できる Linux および Windows 用の適合性評価ツールを提供します。適合性スコアが低い場合は、ワークロードを移行する前に解決しなければならない問題があることを示しています。たとえば、セキュリティが強化された Linux を VM で有効にした場合、移行前にこの依存関係を軽減するための追加作業が必要になることがあります。

  • ネットワーク サービス: ネットワーク サービスの構成と VM ベースのワークロードがこれらのサービスをどのように使用しているのかに関する情報を収集します。たとえば、他のワークロードやサービスのロケーションを特定するために、ワークロードがドメイン ネーム システム（DNS）、マルチキャスト DNS、ホストファイルなどのサービス ディスカバリ メカニズムをどのように使用しているかを評価します。次に、ワークロードに必要なカスタム エントリについて、各 VM の hosts ファイルを評価します。hosts ファイルの詳細については、生成されたリソースと記述子の確認と検証をご覧ください。

  • ハードウェアの依存関係: 高パフォーマンス ストレージ デバイス、GPU、TPU、ネットワーク アプライアンスなど、VM ベースの環境で使用しているあらゆるタイプのハードウェアを評価します。

  • ステートレス ワークロードとステートフル ワークロード: ステートレス ワークロードは、クラスタまたは永続ストレージに状態を保存しません。ステートフル ワークロードでは、後で使用するためにデータを保存します。ステートフル ワークロードの移行は通常、ステートレス ワークロードの移行よりも難しいため、どのワークロードがステートレスで、どのワークロードがステートフルを評価してください。

  • ストレージ: ステートフル ワークロードの場合は、ストレージ要件のリストを作成します。リストを作成する際は、次の点を考慮してください。

    • ストレージ システムの種類（ブロック ボリューム、ファイル ストレージ、オブジェクト ストレージ）
    • ストレージ システムのサイズ

    • ストレージ システムへのワークロード アクセス

      • たとえば、ワークロードがネットワーク ファイル システム（NFS）やサーバー メッセージ ブロック（SMB）を使用してネットワークを介してファイルにアクセスしているかどうか。

      • たとえば、NFS サーバーまたは SMB サーバーで VM を実行しているかどうか。

        VM がカーネルモードで NFS サーバーを実行している場合、サーバーの移行に追加の作業が必要になります。これらのサーバーは、Compute Engine や GKE などの別のランタイム環境に移行できます。また、フルマネージド ネットワーク接続ストレージ サービスである Filestore にデータを移行することもできます。

    • ディスク構成:

      • VM 内のすべてのディスク、データ パーティション、ボリュームの構成と、それぞれのセキュリティと機密性保持に関する機能を評価します。

  • データの局所性: データの局所性は、ステートフル ワークロードのパフォーマンスに影響を与えます。環境と外部システムの距離や接続性がレイテンシに影響します。外部データ ストレージ システムごとに、満たす必要があるパフォーマンスと可用性の要件を検討します。

評価を完了する

環境と VM ベースのワークロードに関連するインベントリを作成したら、Google Cloud への移行: ワークロードの評価と調査の評価フェーズの残りの作業を行います。この作業が完了したら、以下の説明に進んでください。

基盤の計画と構築

計画と構築フェーズでは、Google Cloud 上のワークロードをサポートするクラウド インフラストラクチャとサービスをプロビジョニングして構成します。

  1. リソース階層を構築する。
  2. Identity and Access Management を構成する。
  3. お支払い情報を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. モニタリングとアラートを設定する。

ワークロードとその依存関係をサポートするクラウド インフラストラクチャとサービスの構築方法については、Google Cloud への移行: 基盤の構築をご覧ください。これらのガイドラインに沿って環境の基盤を構築します。この作業が完了したら、以下の説明に進んでください。

「Google Cloud への移行: 基盤の構築」のガイダンスに沿って、Migrate to Containers の設定により、基盤に関する作業を完了します。

  1. ワークロードと移行元の環境が Migrate to Containers の前提条件を満たしていることを確認します。
  2. Migrate to Containers Cloud APIs への移行を有効にします。
  3. Migrate to Containers が移行先の環境のリソースにアクセスするために使用するサービス アカウントをプロビジョニングします。
  4. ワークロードを Google Cloud の GKE または GKE クラスタに移行する場合は、Migrate to Virtual Machines を設定します。
  5. Migrate to Containers 処理クラスタを構成します。Migrate to Containers クラスタは、移行中にコンテナ移行コンポーネントを実行します。
  6. 処理クラスタに Migrate to Containers をインストールして構成します。

前述の「Migrate to Containers の設定」記事では、Migrate to Containers とその依存関係をプロビジョニングして構成する方法について説明しました。そのガイダンスに従って、Migrate to Containers を設定します。

作業が完了したら、このドキュメントの先に進みます。

VM ベースのワークロードのコンテナへの移行

デプロイ フェーズでは、次のマイルストーンを使用して、移行元の環境から GKE または GKE Enterprise で実行されているコンテナに VM を移行します。

  1. 移行計画を生成して確認します。
  2. コンテナ アーティファクトとデプロイ記述子を生成します。
  3. Migrate to Containers が生成したリソース記述子を確認、検証、カスタマイズします。
  4. コンテナ化されたワークロードを GKE または GKE Enterprise にデプロイして検証します。
  5. Migrate to Containers をアンインストールします。

Migrate to Containers を使用して VM を移行するために必要な手順については、移行を実行するをご覧ください。

移行計画を作成して確認する

VM ベースのワークロードの Migrate to Containers 移行計画を作成します。

  1. 移行元の環境を Migrate to Containers の移行元として構成します。Migrate to Containers で VM ベースのワークロードを移行するには、VM が現在実行されている移行元の環境に関する情報が必要です。これらの情報は、このドキュメントのインベントリの作成で説明している手順で収集しています。移行元の環境の構成の詳細については、移行元の追加（Linux）と移行元の追加（Windows）をご覧ください。
  2. 移行計画を作成します。移行元の環境からサポートされている移行先の環境に移行する VM ベースのワークロードを指定するには、移行計画を作成します。たとえば、永続データを保存する場所を構成します。移行計画の作成とモニタリングの詳細については、移行の作成（Linux）と移行の作成（Windows）をご覧ください。
  3. 移行計画を確認してカスタマイズします。移行する VM ベースのワークロードごとに移行計画を生成したら、各移行計画を確認して、要件に合わせてカスタマイズすることをおすすめします。移行計画のカスタマイズの詳細については、移行計画のカスタマイズ（Linux）および移行計画のカスタマイズ（Windows）をご覧ください。

作業が完了したら、このドキュメントの先に進みます。

コンテナ アーティファクトとデプロイ記述子を生成する

ワークロードのターゲット コンテナ アーティファクトを生成するため、Migrate to Containers は、移行計画の VM から抽出したワークロードとデータを含むコンテナ イメージを作成します。次に、コンテナ イメージのコピーを構成済みのコンテナ イメージ リポジトリに保存します。Migrate to Containers は、ターゲット環境でコンテナ イメージのインスタンスのデプロイとカスタマイズに使用できるデプロイ記述子を生成します。

コンテナ アーティファクトの生成方法については、移行の実行（Linux）と移行の実行（Windows）をご覧ください。

作成して移行するコンテナ アーティファクトの進行状況をモニタリングできます。移行のモニタリングの詳細については、移行のモニタリング（Linux）と移行のモニタリング（Windows）をご覧ください。

Windows ワークロードのコンテナ アーティファクトを生成する場合は、Migrate to Containers が生成したアーティファクトとデプロイ記述子を使用して、そのワークロードの Windows コンテナ イメージをビルドします。ワークロードに Windows コンテナ イメージをビルドする方法については、Windows コンテナ イメージのビルドをご覧ください。

作業が完了したら、このドキュメントの先に進みます。

生成されたリソースと記述子を確認して検証する

Migrate to Containers でコンテナ アーティファクトとデプロイ記述子を生成したら、これらのアーティファクトと記述子を確認し、要件に合わせて更新します。コンテナ アーティファクトとデプロイ記述子の更新に必要な時間は、移行する VM ベースのワークロードの数と複雑さによって異なります。コンテナ アーティファクトとデプロイ記述子の確認方法については、生成されたデプロイ ファイル（Linux）の確認と Windows コンテナ イメージのビルドをご覧ください。たとえば、次の点を検討してください。

リソースと記述子の命名

構成およびログのリソースと記述子

ポリシーおよびプロファイルのリソースと記述子

その他のリソースと記述子

作業が完了したら、このドキュメントの先に進みます。

コンテナ化されたワークロードをデプロイして検証する

ワークロードのデプロイ記述子の準備ができたら、次の手順を行います。

  1. 移行したワークロードを移行先の環境にデプロイします。移行された Linux および Windows ワークロードのデプロイ方法については、Linux ワークロードをターゲット クラスタにデプロイするとターゲット クラスタに Windows ワークロードをデプロイするをご覧ください。

  2. 移行したワークロードをモニタリングします。移行した Linux ワークロードと Windows ワークロードをデプロイすると、パフォーマンスに関する情報を収集できます。詳細については、移行されたワークロードのモニタリング（Linux）と移行されたワークロードのモニタリング（Windows）をご覧ください。

  3. 移行したワークロードを統合します。移行先の環境にデプロイしたワークロードが動作するようになったら、ワークロードの統合を行います。ワークロードのコンテナ アーティファクトの生成プロセスとデプロイ プロセスをデプロイ プロセスとパイプラインに統合します。現在、自動デプロイ プロセスを実施しておらず、ワークロードを手動でデプロイする場合は、手動デプロイから自動デプロイに移行することをおすすめします。

作業が完了したら、このドキュメントの先に進みます。

Migrate to Containers をアンインストールする

Migrate to Containers でのワークロード移行の完了後は、次のことをおすすめします。

  1. 移行中に Migrate to Containers で生成されたアーティファクトへのすべての参照が存在することを確認します。
  2. Migrate to Containers をアンインストールします。

作業が完了したら、このドキュメントの先に進みます。

移行後に環境を最適化する

環境の最適化が移行の最終段階です。GKE と GKE Enterprise 環境を最適化するには、環境の最適化をご覧ください。

次のステップ