Linux VM の移行計画をカスタマイズする
移行計画を実行する前に、計画を確認して、必要に応じてカスタマイズしてください。移行計画の詳細は、ソース VM からワークロード コンテナ アーティファクトを抽出する際や、コンテナ イメージを本番環境のクラスタなどの他のクラスタにデプロイする際に使用する Kubernetes Deployment ファイルを生成するために使用されます。
このセクションでは、移行計画の内容と、移行を実行してデプロイ アーティファクトを生成する前に考慮すべきカスタマイズの種類について説明します。
始める前に
このトピックでは、すでに移行を作成し、移行計画ファイルが作成されていることを前提としています。
移行計画を編集する
移行計画を編集するには、migctl ツールまたは Google Cloud Console を使用します。
migctl
移行計画をダウンロードしてから編集する必要があります。
移行計画をダウンロードします。Linux ワークロードの移行計画は、LinuxMigrationCommonSpec で表されます。
migctl migration get my-migration
ダウンロードした移行計画
my-migration.yamlをテキスト エディタで編集します。編集が完了したら、修正した移行計画を保存してアップロードします。
migctl migration update my-migration --main-config my-migration.yaml
さらに編集が必要な場合は、上記の手順を繰り返します。
Console
YAML エディタを使用して Google Cloud コンソールで移行プランを編集します。Linux ワークロードの移行計画は、LinuxMigrationCommonSpec CRD で表されます。
Google Cloud コンソールで [Migrate to Containers] ページを開きます。
[移行] タブをクリックして、使用可能な移行を含むテーブルを表示します。
目的の移行の行で移行の名前を選択し、[詳細] タブを開きます。
[YAML] タブを選択します。
必要に応じて、移行計画を編集します。
編集が完了したら、次のいずれかの操作を行います。
CRD
移行計画をダウンロードして編集し、適用する必要があります。Linux ワークロードの移行計画は、LinuxMigrationCommonSpec CRD で表されます。
AppXGenerateArtifactsFlowの名前を取得します。kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration命名パターンは
appx-generateartifactsflow-idの形式で返されます。移行計画を名前で取得し、
my-plan.yamlという名前のファイルに書き込みます。kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml必要に応じて、移行計画を編集します。
ファイルを適用します。
kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id
移行から除外するコンテンツを指定する
デフォルトでは、Migrate to Containers は、GKE のコンテキストに関係のない一般的な VM コンテンツを除外します。このフィルタはカスタマイズできます。
filters フィールド値には、移行から除外する必要があるパスが一覧表示されます。このパスは、コンテナ イメージの一部にはなりません。フィールドの値には、転送するファイルとスキップするファイルを指定する rsync フィルタルールが一覧表示されます。各パスとファイルの前にマイナス記号が付いていると、リスト内のアイテムを移行から除外する必要があることを示しています。リストは YAML の行の順序で処理され、除外または登録はその順序で評価されます。
詳しくは、rsync のマニュアル ページの「INCLUDE/EXCLUDE PATTERN RULES」セクションを参照してください。
サイズが大きすぎて Docker イメージに含めることができないファイルは、YAML ファイルに一覧表示されます。これにより、検討対象となるファイルが 1 GB を超える場合はフラグが設定されます。Docker イメージのサイズが大きすぎるか、15 GB を超えると、移行中に障害が発生する可能性があります。
YAML リストを編集して、パスを追加または削除できます。以下の YAML の例をご覧ください。これには、除外の例と、大きなファイルやスパース ファイルの通知が含まれています。インラインのガイダンスに沿って、次のいずれかを行います。
- 検出されたフォルダを除外するには、コメントを解除してグローバル フィルタのセクションに配置します。
- 検出されたフォルダを永続ボリュームに移動するには、コメントを解除してデータフォルダ セクションに配置します。
同様に、検出されたスパース ファイルも除外または移動することをおすすめします。
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/*"
## The data folders below are too large to be included in the docker image.
## Consider uncommenting and placing them under either the global filters
## or the data folder section.
# - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
# - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
## Sparse files will fail the run of a docker image. Consider excluding the below
## detected files and any other sparse files by uncommenting and placing them in
## the global filters section, or export them to a persistent volume by specifying
## them in the data folder section.
# - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
# - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
コンテナ イメージの名前を設定する
image フィールド値は、移行した VM から作成された 2 つのイメージの名前と場所を定義します。他の名前が望ましい場合は、これらの値を変更できます。
移行中、Migrate to Containers は移行で使用するために、移行ワークロードを表すファイルとディレクトリを（デフォルトで）Container Registry にコピーします。移行プロセスでは、抽出されたワークロードを GKE で実行可能なイメージに適合させます。
Migrate to Containers は、（base パスにある）元の VM のファイルとディレクトリをレジストリに保存します。このイメージは、抽出されたワークロード ファイルを含む実行不可能なベースレイヤとして機能し、Migrate to Containers ランタイム ソフトウェア レイヤと一緒に、実行可能なコンテナ イメージをビルドします。
別々のレイヤを使用すると、必要に応じてベースレイヤと Migrate to Containers ソフトウェア レイヤを個別に更新できるので、後のコンテナ イメージの更新が簡単になります。
このイメージは実行できませんが、Migrate to Containers をアップグレードすると、Migrate to Containers が元のコンテナを更新できるようになります。
base と name のフィールド値は、レジストリで作成されるイメージを指定します。
base-- ソース プラットフォームからコピーした VM ファイルとディレクトリから作成されたイメージの名前。このイメージは GKE でのデプロイに対応していないため、GKE では実行できません。name-- コンテナに使用される実行可能イメージの名前。このイメージには、ソース VM のコンテンツと、Migrate to Containers ランタイムの両方が含まれているため、実行可能です。
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: "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: "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: "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: "centos-mini:tag"
サービスリストをカスタマイズする
デフォルトでは、Migrate to Containers は VM をコンテナに移行するときに、VM 上の不要なサービスを無効にします。これらのサービスにより、移行後のコンテナで問題が発生することがあります。また、これらのサービスがコンテナのコンテキストで不要になることもあります。
Migrate to Containers によって自動的に無効にされないサービスも無効にすることもできます。
Migrate to Containers は、サービスを自動的に検出してそのリストを移行計画に追加しますが、この中には無効にできるサービスもあります。たとえば、
sshやウェブサーバーなどのサービスは、移行後のワークロードで不要となることがあります。サービスが不要かどうかはご自身で判断してください。必要に応じて、移行計画を編集してこれらのサービスを無効にします。Migrate to Containers は、ソース VM で実行されているサービスをすべてリストに追加するわけではありません。たとえば、オペレーティング システムに関連するサービスは省略します。必要に応じて、移行計画を編集して移行先のコンテナで無効にするサービスのリストを追加することもできます。
systemServices フィールドには、Migrate to Containers によって検出されたサービスのリストを指定します。次に例を示します。
systemServices:
- enabled: true|false
name: service-name
probed: true|false
- enabled: true|false
name: service-name
probed: true|false
...
サービスを無効にするには、enabled を false に設定します。
Migrate to Containers では、オペレーティング システムに関連するサービスなど、ソース VM で実行されているすべてのサービスが一覧表示されるわけではありません。ただし、リストにサービスを追加することは可能です。たとえば、service2 と cron サービスを無効にするには、次のコマンドを実行します。
systemServices:
- enabled: true
name: service1
probed: false
- enabled: false
name: service2
probed: false
- enabled: false
name: cron
probed: false
移行を実行して移行アーティファクトを生成すると、Migrate to Containers によって 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 することもできます。次に例を示します。
blocklist.yamlファイルを更新します。コンテナ イメージを再構築して push します。
コンテナ イメージを再構築して push する方法は、ビルド環境によって異なります。次を使用できます。
gcloud: クイックスタート: ビルドの説明に従ってイメージを再ビルドし Container Registry に push します。docker build: イメージのビルドと実行の説明のとおりに実行します。
新しいイメージを再ビルドして push したら、エディタで
deployment_spec.yamlファイルを開き、イメージの場所を更新します。spec: containers: - image: new-image-location
たとえば、
gcloudを使用してイメージを再ビルドし、Container Registry に push した場合、new-image-location はmy-new-image:v1.0になります。
サービス エンドポイントをカスタマイズする
移行計画には、移行されたワークロードによって提供される Kubernetes Service の作成に使用されるポートとプロトコルを定義する endpoints 配列が含まれます。エンドポイント定義を追加、編集、削除して移行計画をカスタマイズできます。
Service エンドポイントごとに、移行計画に次の定義を追加します。
endpoints:
- port: PORT_NUMBER
protocol: PORT_PROTOCOL
name: PORT_NAME
ここで
- PORT_NUMBER は、サービスへのリクエストがルーティングされるコンテナのポート番号を指定します。
- PORT_PROTOCOL には、HTTP、HTTPS、TCP などのポート プロトコルを指定します。すべてのプロトコルの一覧については、サポートされているプロトコルをご覧ください。
- PORT_NAME には、サービス エンドポイントへのアクセスに使用する名前を指定します。Migrate to Containers は、生成されたエンドポイント定義ごとに一意の PORT_NAME を生成します。
たとえば、Migrate to Containers は次のエンドポイントを検出します。
endpoints:
- port: 80
protocol: HTTP
name: backend-server-nginx
- port: 6379
protocol: TCP
name: backend-server-redis
name プロパティの値を設定するために、Migrate to Containers は、ソース VM 名（この例では backend-server）と Service のプログラム名を組み合わせます。生成される名前は、Kubernetes の命名規則と互換性があり、移行計画内で一意です。たとえば、先述の移行計画では、HTTP 経由でポート 80 の Nginx をターゲットとする Service が作成されます。
重複する名前がある場合は、Migrate to Containers によって接尾辞として番号が追加されます。たとえば、Nginx が 2 つのポートに関連付けられている場合、2 番目の定義では -2 接尾辞が name に追加されます。
endpoints:
- port: 80
protocol: HTTP
name: backend-server-nginx
- port: 8080
protocol: HTTPS
name: backend-server-nginx-2
- port: 6379
protocol: TCP
name: backend-server-redis
移行を実行して移行アーティファクトを生成すると、Migrate to Containers によって各エンドポイントの deployment_spec.yaml ファイルに Service 定義が作成されます。
例として、deployment_spec.yaml ファイル内の Service 定義を以下に示します。
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
name: backend-server-nginx
spec:
ports:
- port: 80
protocol: HTTP
targetPort: 80
selector:
app: backend-server
status:
loadBalancer: {}
NFS マウントをカスタマイズする
Migrate to Containers には、生成された移行計画に NFS マウントが含まれます。この情報は fstab ファイルから収集され、移行計画の nfsMounts 配列に書き込まれます。NFS マウント ポイントの定義を追加または編集して、移行計画をカスタマイズできます。
移行計画を生成する際は、Migrate to Containers は次のように動作します。
/sysと/devの NFS マウントを無視します。nfsまたはnfs4以外のタイプの NFS マウントを無視します。
移行計画の各 NFS マウントには、次の形式でサーバーの IP アドレスとローカル マウントパスが含まれます。
nfsMounts:
- mountPoint: MOUNT_POINT
exportedDirectory: DIR_NAME
nfsServer: IP
mountOptions:
- OPTION_1
- OPTION_2
enabled: false|true
ここで
- MOUNT_POINT には、
fstabから取得したマウント ポイントを指定します。 - DIR_NAME には、共有ディレクトリの名前を指定します。
- IP には、マウント ポイントをホストするサーバーの IP アドレスを指定します。
- OPTION_N は、
fstabから抽出したマウント ポイントのオプションを指定します。
たとえば、fstab の次のエントリの場合:
<file system> <mount point> <type> <options> <dump> <pass> 10.49.232.26:/vol1 /mnt/test nfs rw,hard 0 0
Migrate to Containers では、移行計画に次のエントリが生成されます。
nfsMounts:
- mountPoint: /mnt/test
exportedDirectory: /vol1
nfsServer: 10.49.232.26
mountOptions:
- rw
- hard
enabled: false
nfsMounts 配列のエントリを処理するように Migrate to Containers を構成するには、mountPoint エントリの enabled を true に設定します。mountPoints エントリの 1 つ、複数、またはすべてを有効にしたり、エントリを編集できます。また、独自のエントリを追加することもできます。
移行を実行して移行アーティファクトを生成すると、Migrate to Containers が Volumes と volumeMounts の定義と、PersistentVolume と PersistentVolumeClaim の定義を有効な NFS マウントごとに deployment_spec.yaml ファイルに作成します。
例として、deployment_spec.yaml ファイル内の volumeMounts 定義を以下に示します。
spec:
containers:
- image: gcr.io/myimage-1/image-name
name: some-app
volumeMounts:
- mountPath: /sys/fs/cgroup
name: cgroups
- mountPath: /mnt/test
name: nfs-pv
ここで、name の値は、Migrate to Containers によって生成された一意の識別子です。
deployment_spec.yaml ファイル内の PersistentVolumeClaim と PersistentVolume の定義の例を以下に示します。
apiVersion: v1
kind: PersistentVolumeClaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Mi
storageClassName: ""
volumeName: nfs-pv
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
mountOptions:
- rw
- hard
nfs:
path: /vol1
server: 10.49.232.26
Cloud Logging に書き込まれるログデータをカスタマイズする
通常、ソース VM は 1 つ以上のログファイルに情報を書き込みます。VM の移行の一環として、移行されるワークロードを構成して、そのログ情報を Cloud Logging に書き込むことができます。
移行計画を生成すると、Migrate to Containers は、ソース VM のログの宛先ファイルを自動的に検索します。Migrate to Containers によって、検出されたファイルに関する情報が移行計画の logPaths 領域に書き込まれます。
deployment:
...
logPaths:
- appName: APP_NAME
globs:
- LOG_PATH
次に例を示します。
deployment:
...
logPaths:
- appName: tomcat
globs:
- /var/log/tomcat*/catalina.out
移行アーティファクトを生成すると、Migrate to Containers が移行計画から logs.yaml ファイルを生成するようになりました。このファイルには、ソース VM で検出されたログファイルのリストが含まれます。たとえば、上記の logsPath の定義で、logs.yaml には以下が含まれています。
logs: tomcat: - /var/log/tomcat*/catalina.out
この例では、移行されたワークロードをデプロイすると、catalina.out に書き込まれたログ情報が自動的に Cloud Logging に書き込まれます。
ログで、エントリは次の形式で 1 行に表示されます。
DATE TIME APP_NAME LOG_OUTPUT
次の例は、Tomcat からのエントリの形式を示しています。
2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output
ロギングを構成するには、次のいずれかを行います。
移行アーティファクトを生成する前に移行計画を編集し、
logPathsのエントリを追加、削除、または編集します。移行アーティファクトを生成すると、この編集はlogs.yamlファイルに反映されます。移行アーティファクトを生成した後に
logs.yamlを編集して、logsのエントリを追加、削除、または編集します。
移行計画を編集する利点は、アーティファクトを生成するたびに編集内容が logs.yaml に反映されることです。なんらかの理由で logs.yaml を直接編集してからアーティファクトを再生成する場合は、編集内容を logs.yaml に再度適用する必要があります。
Linux v2kServiceManager の正常性プローブを設定する
マネージド コンテナのダウンタイムと準備完了ステータスは、Tomcat ウェブサーバーの移行計画でプローブを指定することによりモニタリングできます。正常性プローブのモニタリングは、移行されたコンテナのダウンタイムを減らし、モニタリングを改善する効果があります。
不明なヘルス状態は、可用性の低下、可用性モニタリングの誤判定、およびデータ損失を引き起こす可能性があります。正常性プローブがなければ、kubelet は、コンテナの健全性を想定することしかできず、準備ができていないコンテナ インスタンスにトラフィックを送信する可能性があります。これにより、トラフィックが失われる場合があります。kubelet は、フリーズされたコンテナを検出することもできず、コンテナは再起動されません。
正常性プローブは、コンテナの起動時に小さなスクリプト ステートメントを実行します。このスクリプトは、成功したプローブの種類をチェックします。これは、使用されるプローブのタイプによって定義されます。期間は移行計画の periodSeconds フィールドで定義されます。これらのスクリプトは、手動で実行または定義できます。
kubelet のプローブの詳細については、Kubernetes ドキュメントの livenessProbe、readinessProbe、startupProbe の構成をご覧ください。
構成可能なプローブには 2 つのタイプがありますが、どちらのプローブも probe-v1-core リファレンスで定義された Probe-v1-core で、container-v1-core の対応フィールドと同じ機能を共有します。
- livenessProbe - livenessProbe は、コンテナを再起動するタイミングを把握するために使用されます。
- readinessProbe - readinessProbe は、コンテナがトラフィックの受信を開始する準備が整うタイミングを認識するために使用されます。プローブが成功した場合にのみ Pod へのトラフィックの送信を開始するには、readinessProbe を指定します。readinessProbe は livenessProbe と同様に機能する場合もありますが、仕様の readinessProbe は、Pod がトラフィックを受信せずに起動し、プローブが成功した後にのみトラフィックの受信を開始することを示します。
調査後、プローブ構成が移行計画に追加されます。プローブは、次のようにデフォルト構成で使用できます。プローブを無効にするには、yaml から probes セクションを削除します。
v2kServiceManager: true
deployment:
probes:
livenessProbe:
exec:
command:
- gamma
- /probe
readinessProbe:
exec:
command:
- gamma
- /probe
initialDelaySeconds: 60
periodSeconds: 5
image:
# Disable system services that do not need to be executed at the migrated workload containers.
# Enable the 'probed' property to include system services in the container health checks.
systemServices:
- enabled: true
name: apache2
probed: true
- enabled: true
name: atd
probed: false
デフォルトでは、すべてのサービス プローブは無効になっています。モニタリングするサービスのサブセットを定義する必要があります。
プローブを使用してコンテナを確認するには、事前定義された 4 つの方法があります。各プローブでは、次の 4 つのメカニズムのいずれか 1 つのみを定義する必要があります。
exec- コンテナ内で指定されたコマンドを実行します。終了ステータス コードが 0 の場合、正常に実行されたとみなされます。grpc- gRPC を使用してリモート プロシージャ コールを実行します。gRPC プローブはアルファ版の機能です。httpGet- 指定されたポートとパスにある Pod の IP アドレスに対して HTTP GET リクエストを実行します。ステータス コードが 200 以上 400 未満の場合、リクエストが正常に終了したとみなされます。tcpSocket- 指定されたポートにある Pod の IP アドレスに対して TCP チェックを実行します。ポートが開いている場合、チェックが正常に終了したとみなされます。
デフォルトでは、移行計画によって exec プローブ方式が有効になります。移行計画に手動構成を使用して、別の方法を有効にします。
デフォルトの readinessProbe を使用しながら、readinessProbe に外部依存関係を追加するには、exec readinessProbe と、ロジックを実装するスクリプトを定義します。
次のステップ
- 移行の実行方法を学ぶ。