データ リポジトリの定義

移行の一環として、Migrate to Containers はさまざまなデータ リポジトリに情報を書き込みます。

  1. 移行された Linux VM を表す Docker イメージ ファイルが Docker レジストリに書き込まれます。

    こうした Docker イメージ ファイルは、移行された Linux VM のファイルとディレクトリを表します。Windows ワークロードを移行する場合、このリポジトリは不要です。

  2. 移行されたワークロードを表す移行アーティファクトが 2 つ目のリポジトリに書き込まれます。

    アーティファクトには、移行されたワークロードのデプロイに使用できる構成 YAML ファイルなどのファイルが含まれます。正確なアーティファクトは、Linux ワークロードと Windows ワークロードのどちらを移行するかによって異なります。

プラットフォーム Docker イメージ ファイル レジストリ* 移行アーティファクト リポジトリ
Google Cloud 上の GKE Enterprise クラスタ デフォルトは、Container Registry（GCR）です。

必要に応じて、基本認証をサポートする任意の Docker レジストリを指定します。

 デフォルトは、Cloud Storage です。

必要に応じて、Linux 移行のアーティファクト リポジトリとして S3 を指定します。S3 は、Windows ワークロードの移行ではサポートされません。
ベアメタル版 Google Distributed Cloud Virtual クラスタ デフォルトは、Container Registry（GCR）です。

必要に応じて、基本認証をサポートする任意の Docker レジストリを指定します。

 デフォルトは、Cloud Storage です。

必要に応じて、アーティファクト リポジトリとして S3 を指定します。
* Windows の移行では、Docker イメージ ファイル レジストリは必要ありません。これは、Linux VM の移行の場合のみ必要です。

リポジトリのステータスを表示する

Migrate for Containers をインストールしたら、migctl doctor コマンドを実行して Migrate to Containers インストールを検証します。migctl doctor コマンドは、この検証の一環としてリポジトリのステータスを確認します。

migctl doctor

次の migctl doctor コマンド出力例では、Migrate to Containers が正常にデプロイされていることを示すチェックマークが付いていますが、必要なデータ リポジトリがまだ構成されていません。

  [✓] Deployment
  [!] Docker Registry
  [!] Artifacts Repo
  [!] Source Status

リポジトリに問題がある場合は、コマンドの実行時に migctl doctor によってリポジトリにフラグが設定されます。migctl doctor を実行すると、migctl はすべてのアーティファクト リポジトリに対してクエリを実行し、良好な状態でないリポジトリごとに警告を表示します。

次の migctl doctor コマンド出力例にある感嘆符は、Migrate to Containers がアーティファクト リポジトリでエラーを検出したことを示します。エラーによりリポジトリの初期化に失敗したため、コマンドを再度実行する前に構成を修正する必要があります。デフォルトを超える追加リポジトリが存在する場合でも、これが原因で移行に失敗しているとは限りません。

デフォルトのリポジトリが正常でない場合に表示される X は、Migrate to Containers がエラーを検出したため、移行に失敗する可能性があることを示します。

[✓] Deployment
[✓] Docker Registry
[!] Artifacts Repository
    [✓] example-healthy-repository [default]
    [!] example-failed-repository
        Error: Failed to initialize repository client: Retryable M4A_RepositoryFactoryMissingSecret: artifacts repository secret is configured, but not found at the designated location '/example-failed-repository'
[!] Source Status
[✓] Default storage class

リポジトリを構成した後に migctl doctor コマンドをもう一度実行すると、リポジトリが正しく構成されていることを確認できます。

  [✓] Deployment
  [✓] Docker registry
  [✓] Artifacts repo
  [!] Source Status

Google Cloud コンソールのサポート

Google Cloud コンソールには、リポジトリの実装に基づいて、リポジトリ内のアイテムへの URL が表示されます。たとえば、リポジトリが S3 を使用して実装されている場合、Google Cloud コンソールにはバケットの URL が S3 で表示されます。

リポジトリの場所に関するオプション

データ リポジトリの場所は、移行のパフォーマンスとコストに影響する可能性があります。

たとえば、移行された VM を表す Docker イメージ ファイルは、サイズが大きくなることがあります。処理クラスタがオンプレミスにあり、Docker イメージ ファイルを Google Cloud の GCR に書き込む場合には、データ アップロードのパフォーマンス レイテンシと、そのデータの保存コストが発生します。

オンプレミス処理クラスタの場合、クラスタに対してローカルな Docker レジストリを定義する方が効率的になる可能性があります。レジストリをローカルにすることで、アップロードのレイテンシとストレージ コストを最小限に抑えることができます。

Google Cloud にデプロイされた GKE クラスタの場合、デフォルトの GCR リポジトリを使用すると最高レベルのパフォーマンスが得られますが、そのストレージに対して課金されます。ですが、クラウドベースのクラスタで GCR を使用する必要はなく、代わりに独自の Docker レジストリを使用することもできます。

リポジトリの命名要件

Migrate to Containers に追加するときに、リポジトリに名前を割り当てます。この名前は次の要件を満たす必要があります。

  • 最大文字数は 63 文字とする。
  • 小文字の英数字またはハイフン（-）のみを使用する。
  • 先頭が英数字である。
  • 末尾が英数字である。

リポジトリの認証

Migrate to Containers が使用するすべてのリポジトリには認証が必要です。次の表に示すように、この認証メカニズムはリポジトリの種類によって異なります。

リポジトリ 実装 認証
Docker イメージ ファイル レジストリ GCR Google Cloud サービス アカウントの JSON キー。

詳細については、Container Registry と Cloud Storage にアクセスするためのサービス アカウントの作成をご覧ください。
Docker レジストリ 基本認証用のユーザー名とパスワード。
移行アーティファクト リポジトリ Cloud Storage Google Cloud サービス アカウントの JSON キー。

詳細については、Container Registry と Cloud Storage にアクセスするためのサービス アカウントの作成をご覧ください。
S3 アクセスキーとシークレット、または認証ファイル。詳細については、アクセス管理の概要をご覧ください。

TLS のサポート

一部のリポジトリには、TLS / SSL を使用して HTTPS 経由でアクセスできます。リポジトリへの HTTPS 接続で自己署名証明書を使用する場合は、リポジトリを構成するときに次のいずれかの証明書を含む PEM ファイルを渡す必要があります。

  • 自己署名証明書の公開鍵
  • ルート証明書とすべての中間証明書から実際のサーバー証明書までの連結

Docker レジストリの構成

migctl コマンドを使用して、Docker レジストリを構成します。migctl コマンドを使用すると、レジストリ構成に対して次の操作を行えます。

  • 作成
  • 更新
  • 削除
  • リスト
  • 既定に設定

構成は複数定義できます。Migrate to Containers は、現在デフォルトとして定義されている構成を使用します。migctl docker-registry list コマンドを使用して、デフォルトの構成を含む現在の構成を表示します。migctl docker-registry set-default コマンドを使用してデフォルト構成を設定します。

次の例は、Docker レジストリを構成する方法を示しています。

  • GCR

    migctl docker-registry create gcr registry-name --project project-id --json-key=m4a-install.json

    ここで

    • registry-name は、Docker レジストリ構成のユーザー定義名です。

    • project-id は、Google プロジェクト ID です。

    • m4a-install.json は、サービス アカウントの構成の説明に沿って、Container Registry と Cloud Storage にアクセスするためのサービス アカウントの JSON キーファイルの名前です。

  • Docker レジストリ

    migctl docker-registry create basic-auth registry-name --registry-path url --username username --ca-pem-file ca-pem-filename

    ここで

    • registry-name は、Docker レジストリ構成のユーザー定義名です。

    • url は、http:// または https:// の接頭辞が付加されていないレジストリの URL を指定します。例: localhost:8080/myregistry

    • username は、レジストリの基本認証情報です。パスワードの入力を求められます。

    • レジストリが自己署名証明書を使用している場合は、ca-pem-filename は公開鍵または完全な CA チェーン（中間 CA 証明書からルート証明書までの連結）のいずれかを含む PEM ファイルを指定します。例:

      cat int1.pem int2.pem ... root.pem

後でレジストリ構成を更新するには、作成に使用したものと同じ引数で migctl docker-registry update コマンドを実行します。

migctl docker-registry update gcr registry-name same-flags-as-create

Docker レジストリを構成すると、そのレジストリがデフォルトのレジストリになります。ただし、複数のレジストリが定義されることもあります。レジストリの最新リストを表示するには:

migctl docker-registry list

デフォルトのレジストリ構成（現在移行に使用されている構成）を設定するには、次のコマンドを使用します。

migctl docker-registry set-default registry-name

レジストリ構成を削除するには:

migctl docker-registry delete registry-name

アーティファクト リポジトリの構成

migctl コマンドを使用して、アーティファクト リポジトリを構成します。migctl コマンドを使用すると、リポジトリ構成に対して次の操作を行えます。

  • 作成
  • 更新
  • 削除
  • リスト
  • デフォルトを設定

migctl コマンド create、update、list はすべて、アーティファクト リポジトリに対して継続的なヘルスチェックを行います。実行時に、リポジトリが使用可能かどうかを示すメッセージと、関連するエラー メッセージが表示されます。create または update のヘルスチェックをスキップするには、--async フラグを指定して次のコマンドを実行します。

構成は複数定義できます。Migrate to Containers は、現在デフォルトとして定義されている構成を使用します。migctl artifacts-repo list コマンドを使用して、デフォルトの構成を含む現在の構成を表示します。migctl artifacts-repo set-default コマンドを使用してデフォルト構成を設定します。

次の例は、アーティファクト リポジトリの構成方法を示しています。

  • Cloud Storage

    migctl artifacts-repo create gcs repository-name --bucket-name bucket-name --json-key=m4a-install.json

    ここで

    • repository-name は、アーティファクト リポジトリ構成のユーザー定義名です。

    • bucket-name は、Cloud Storage リポジトリ内の既存のバケットを指定します。既存のバケットがない場合は、バケットを作成するの手順に沿ってバケットを作成します。

      注: Google Cloud のクラスタに Migrate to Containers をインストールすると、Migrate to Containers インストーラにより、次の名前のデフォルト バケットが自動的に作成されます。

      GCP_PROJECT-migration-artifacts

      ここで、GCP_PROJECT は Google プロジェクト ID です。

    • project-id は、Google プロジェクト ID です。

    • m4a-install.json は、サービス アカウントの構成の説明に沿って、Container Registry と Cloud Storage にアクセスするためのサービス アカウントの JSON キーファイルの名前です。

    migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --access-key-id=key-id

    key-id の秘密鍵の入力を求められます。

    または、認証情報ファイルのパスを指定します。

    migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --credentials-file-path file-path

    ここで

    • repository-name は、アーティファクト リポジトリ構成のユーザー定義名です。

    • bucket-name は、S3 リポジトリ内の既存のバケットを指定します。既存のバケットがない場合は、Amazon S3 バケットの操作の手順に沿ってバケットを作成します。

    • aws-region は、リポジトリの AWS リージョンを指定します。処理クラスタとリポジトリは、クラスタがリポジトリにアクセスする権限を持っている限り、それぞれを別のリージョンに配置できます。

    • key-id はアクセスキーを指定します。詳細については、アクセス管理の概要をご覧ください。

    • file-path は、認証情報を含む AWS コンソールからダウンロードされた CSV ファイルへのパスを指定します。

後でリポジトリ構成を更新するには、作成に使用したものと同じ引数で migctl docker-registry update コマンドを実行します。

migctl artifacts-repo update gcr repository-name same-flags-as-create

リポジトリ レジストリを構成すると、そのリポジトリがデフォルトのリポジトリになります。ただし、複数のリポジトリが定義されることもあります。リポジトリの最新リストを表示するには:

migctl artifacts-repo list

デフォルトのリポジトリ構成（現在移行に使用されている構成）を設定するには、次のコマンドを使用します。

migctl artifacts-repo set-default repository-name

リポジトリ構成を削除するには:

migctl artifacts-repo delete repository-name

次のステップ