移行計画のカスタマイズ

移行を実行する前に、移行の作成によってできた移行計画ファイルを確認して、カスタマイズする必要があります。移行計画の詳細は、ソース VM からワークロード コンテナ アーティファクトを抽出するため、およびコンテナ イメージを本番クラスタなどの他のクラスタにデプロイするために使用できる Kubernetes デプロイメント ファイルを生成するために使用されます。

このセクションでは、移行計画の内容と、移行を実行してデプロイ アーティファクトを生成する前に考慮すべきカスタマイズの種類について説明します。

始める前に

  • このトピックでは、すでに移行を作成し、移行計画ファイルが作成されていることを前提としています。

移行計画の編集

migctl ツールまたは Google Cloud Console を使用して移行計画を編集します。

migctl

移行計画をダウンロードしてから編集する必要があります。

  1. 移行計画をダウンロードします。移行計画は、GenerateArtifactsFlow で表されます。

    migctl migration get my-migration
    
  2. ダウンロードした移行計画 my-migration.yaml をテキスト エディタで編集します。

  3. 編集が完了したら、編集した移行計画をアップロードします。

    migctl migration update my-migration --file my-migration.yaml
    
  4. さらに編集が必要な場合は、上記の手順を繰り返します。

Console

YAML エディタを使用して Google Cloud Console で移行プランを編集します。移行計画は、GenerateArtifactsFlow で表されます。

  1. Cloud Console で Migrate for Anthos ページを開きます。

    Migrate for Anthos ページに移動

  2. [移行] タブをクリックして、使用可能な移行を含むテーブルを表示します。

  3. 目的の移行の行で移行の名前を選択し、[詳細] タブを開きます。

  4. [YAML] タブを選択します。

  5. 必要に応じて、移行計画を編集します。

  6. 編集が完了したら、次のいずれかの操作を行います。

    1. 移行計画を保存する。その後、移行の実行に示す手順に沿って、移行を実施し、移行アーティファクトを生成する必要があります。

    2. アーティファクトを保存して生成する。編集内容を使用して、移行アーティファクトを生成し、移行を実施します。このプロセスは、移行の実行で説明する方法と同じです。その後、移行のモニタリングの説明に従って移行をモニタリングします。

CRD

移行計画をダウンロードして編集し、適用する必要があります。移行計画は、GenerateArtifactsFlow で表されます。

  1. GenerateArtifactsFlow の名前を取得します。

    kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}

    名前は generate-artifacts-flow-id の形式で返されます。

  2. GenerateArtifactsFlow を名前で取得して my-plan.yaml という名前のファイルに書き込みます。

    kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml
  3. 必要に応じて、移行計画を編集します。

  4. 次のファイルを適用します。

    kubectl apply -f my-plan.yaml

移行計画のインテントの影響

生成される移行計画の内容は、インテント フラグを使用して作成した移行の種類によって異なります。

このトピックでは、各移行計画セクションの目的について説明します。各セクションでは、そのセクションの YAML に関連するインテント値を示します。インテント フラグの使用の詳細については、移行の作成をご覧ください。

移行から除外するコンテンツの指定

インテント: 任意

デフォルトでは、Migrate for Anthos は、GKE のコンテキストに関係のない一般的な VM コンテンツを除外します。このフィルタはカスタマイズできます。

filters フィールドの値には、移行から除外する必要があるパスがリストされており、コンテナ イメージまたはデータ ボリュームいずれの一部でもありません。フィールドの値には、転送するファイルとスキップするファイルを指定する rsync フィルタルールが一覧表示されます。各パスとファイルの前にマイナス記号が付いていると、リスト内のアイテムを移行から除外する必要があることを示しています。リストは YAML の行の順序で処理され、除外または登録はその順序で評価されます。

詳しくは、rsync のマニュアル ページの「INCLUDE/EXCLUDE PATTERN RULES」セクションを参照してください。

このリストを編集して、パスを追加または削除できます。

  global:
      # Files and directories to exclude from the migration, in rsync format
      filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

データ ボリュームの処理を設定する

インテント: Data または ImageAndData

dataVolumes フィールドは、移行の一部としてデータ ボリュームに含めるフォルダのリストを指定します。このリストは、Data または ImageAndData のインテントを使用して、移行のために編集する必要があります。

デフォルトでは、folders にはプレースホルダの変更が必要な値が含まれています。プレースホルダ値を変更しないと、移行アーティファクトを生成するときに、Replace the folder placeholder with the relevant path の形式でエラーが発生します。

        dataVolumes:

        # Folders to include in the data volume, e.g. "/var/lib/mysql"
        # Included folders contain data and state, and therefore are automatically excluded from a generated container image
        # Replace the placeholder with the relevant path and add more items if needed
        - folders:
          - <folders>

データ ボリュームに含めるフォルダのリストを指定する例を以下に示します。

        - folders:
          - /var/lib/mysql
          - /my-data-folder

移行の名前と名前空間を設定する

インテント: 任意

metadata フィールドを使用して、移行の名前と名前空間を指定できます。デフォルトでは、Migrate for Anthos は移行の作成時に指定した値を使用します(kindapiVersion の値は変更しないでください)。フィールドはすべての intent 値で同一です。

  • name - 移行の名前。
  • namespace - この YAML ファイルで定義された移行の名前空間。v2k-system にします。
  apiVersion: anthos-migrate.cloud.google.com/v1beta2
  kind: GenerateArtifactsFlow
  metadata:
    name: generate-artifacts-flow-id
    namespace: v2k-system

コンテナ イメージの名前を設定する

インテント: Image または ImageAndData

image フィールド値は、移行した VM から作成された 2 つのイメージの名前と場所を定義します。他の名前が望ましい場合は、これらの値を変更できます。

移行中、Migrate for Anthos は移行で使用するために、移行ワークロードを表すファイルとディレクトリを(デフォルトで)Container Registry にコピーします。移行プロセスでは、抽出されたワークロードを GKE で実行可能なイメージに適合させます。

Migrate for Anthos は、(base パスにある)元の VM のファイルとディレクトリをレジストリに保存します。このイメージは、抽出されたワークロード ファイルを含む実行不可能なベースレイヤとして機能し、Migrate for Anthos ランタイム ソフトウェア レイヤと一緒に、実行可能なコンテナ イメージをビルドします。

別々のレイヤを使用すると、必要に応じてベースレイヤと Migrate for Anthos ソフトウェア レイヤを個別に更新できるので、後のコンテナ イメージの更新が簡単になります。

このイメージは実行できませんが、Migrate for Anthos をアップグレードすると、Migrate for Anthos が元のコンテナを更新できるようになります。

basename のフィールド値は、レジストリで作成されるイメージを指定します。

  • base -- ソース プラットフォームからコピーした VM ファイルとディレクトリから作成されたイメージの名前。このイメージは GKE でのデプロイに対応していないため、GKE では実行できません。
  • name -- コンテナに使用される実行可能イメージの名前。このイメージには、ソース VM のコンテンツと、Migrate for Anthos ランタイムの両方が含まれているため、実行可能です。
        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "gcr.io/my-project/centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "gcr.io/my-project/centos-mini"

デフォルトでは、移行のタイムスタンプに対応するタグがこれらの値に自動的に適用されます。このタグの形式は次のとおりです。

MM-DD-YYYY--hh:mm:ss

独自のタグを適用するには、デフォルトのタグをオーバーライドして、以下のように CRD を編集して追加します。

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "gcr.io/my-project/centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "gcr.io/my-project/centos-mini:tag"

デプロイ アーティファクトの Cloud Storage のロケーションを設定する

インテント: 任意

移行中、Migrate for Anthos は Cloud Storage を使用して、後で本番環境クラスタへの VM のデプロイに使用するファイルを保存します。バケットとフォルダの名前は任意のものに変更できます。

  • bucket - アーティファクトを保存する Cloud Storage バケットの名前。
  • folder - アーティファクトを保存する bucket 内部のフォルダの名前。
  • appName - デプロイ ファイルで使用する Kubernetes コントローラに付ける名前。コントローラのタイプは、移行の作成時に intent フラグに指定した値によって異なります。
    • image-and-data 値の場合、結果はこの名前を持つ StatefulSet オブジェクトとなります。
    • image 値の場合、結果はこの名前を持つ Deployment オブジェクトとなります。
        deployment:

         # Review and set the app-name for your StatefulSet or Deployment YAML spec
         appName: app-centos-mini

         # Artifacts are uploaded to the project-default artifacts repository.
         # In order to specify a custom repository, uncomment the lines below and replace the placeholders with the relevant values
         # artifactsRepository:
         #   spec:
         #     bucket: bucket_name
         #     credentials:
         #       type: gcs
         #       secret: secret

         folder: storage-folder-name/

永続ストレージを構成する

インテント: Data または ImageAndData

移行インテントが Data または ImageAndData の場合、移行プランにはデフォルト値を持つ pvc 定義が含まれます。これらの値は、実際のシステムの要件に合わせて変更できます。

   pvc:
     spec:
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
         # Modify the required disk size on the storage field below based on the capacity needed
           storage: 10G

g3doc スタイルの見出し(H1 → H2 など)

サービスリストのカスタマイズ

インテント: Image または ImageAndData

デフォルトでは、Migrate for Anthos は VM をコンテナに移行するときに不要なサービスを無効にします。これらのサービスにより、移行後のコンテナで問題が発生することがあります。また、これらのサービスがコンテナのコンテキストで不要になることもあります。

Migrate for Anthos によって自動的に無効にされるサービスに加え、必要に応じて他のサービスを無効にすることもできます。

  • Migrate for Anthos は、オプションで無効にできるサービスを自動的に検出し、移行計画に一覧表示します。移行したワークロードによっては ssh やウェブサーバーなどのサービスは必要ない場合がありますので、無効にするしないはユーザーの選択となります。必要に応じて、移行計画を編集してこれらのサービスを無効にしてください。

  • Migrate for Anthos は、ソース VM で実行されているすべてのサービスを一覧表示するわけではありません。たとえば、オペレーティング システムに関連するサービスは省略されます。必要に応じて、移行計画を編集して移行先のコンテナで無効にするサービスのリストを追加することもできます。

systemServices フィールドには、Migrate for Anthos で検出されたサービスのリストを指定します。次に例を示します。

    systemServices:
    - enabled: true|false
      name: service-name
    - enabled: true|false
      name: service-name
      ...

サービスを無効にするには、enabledfalse に設定します。

Migrate for Anthos では、オペレーティング システム関連のサービスは除かれるなど、ソース VM で実行されているすべてのサービスを一覧表示するわけではありません。一覧表示リストにサービスを追加することもできます。たとえば、service2cron サービスを無効にするには、次のようにします。

    systemServices:
    - enabled: true
      name: service1
    - enabled: false
      name: service2
    - enabled: false
      name: cron

移行を実行して移行アーティファクトを生成すると、Migrate for Anthos は blocklist.yaml ファイルを作成します。このファイルには、移行計画の設定に基づいて無効にするコンテナ サービスが一覧表示されます。次に例を示します。

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

無効化されているサービスのリストを変更するには:

  • 移行計画に含まれるサービスのリストを編集します。
  • 移行を実行して、更新済みの blocklist.yaml ファイル、deployment_spec.yaml ファイル、Dockerfile などの移行アーティファクトを再生成します。

移行を実行して移行アーティファクトを生成したら、blocklist.yaml ファイルを直接編集して、コンテナ イメージをご自身でビルドし push することもできます。次に例を示します。

  1. blocklist.yaml ファイルを更新します。

  2. コンテナ イメージを再ビルドして push します。

    コンテナ イメージを再構築して push する方法は、ビルド環境によって異なります。次を使用できます。

    1. gcloudクイックスタート: ビルドの説明に従ってイメージをビルドし Container Registry に push します。
    2. docker buildイメージを作成して実行するの説明に従います。
  3. 新しいイメージを再ビルドして push したら、エディタで deployment_spec.yaml ファイルを開き、イメージの場所を更新します。

    spec:
     containers:
       - image: new-image-location
    

    たとえば、gcloud を使用してイメージを再ビルドし、Container Registry に push した場合、new-image-locationgcr.io/my-project/my-new-image:v1.0 になります。

次のステップ