モノリス VM の移行 - 移行とデプロイ
処理クラスタを設定して Migrate for Anthos and GKE をインストールしたら、移行準備は完了です。まず、処理クラスタに関連する移行元を追加し、VM の移行計画を生成します。この計画を確認して必要に応じてカスタマイズしたら、Kubernetes アーティファクトを生成し、アプリケーションの残りの部分がすでに実行されている GKE クラスタにデプロイします。
目標
このチュートリアルでは、次の方法を学習します。
- 移行元を追加する。
- VM ワークロードから移行計画を作成する。
- 移行計画を確認してカスタマイズする。
- 移行アーティファクトを生成して GKE クラスタにデプロイする。
始める前に
このチュートリアルは、調査と評価チュートリアルのフォローアップです。このチュートリアルを開始する前に、このページの手順に沿ってモノリス VM 上で調査ツールを実行し、処理クラスタを作成してください。
モノリス VM を停止する
移行中にデータが移動すると、意図しない中断やデータの破損が発生する可能性があります。このような問題を回避するため、移行を実施する前にモノリス VM を停止する必要があります。
Google Cloud Console で、[VM インスタンス] ページに移動します。
ledgermonolith-service
VM の行の左端にあるチェックボックスをオンにします。ページの上部にある [停止] ボタンをクリックして、VM を停止します。
VM が完全に停止するまで待ちます。これには 1~2 分ほどかかります
VM の移行
移行候補の VM が完全に停止したので、移行の準備を開始して、移行を実施できるようになりました。最初に、Compute Engine の移行の指定クラスタとして、処理クラスタを指定するソースを作成する必要があります。その後、VM の完全な移行を開始します。
ソースの追加
Cloud Console で [Migrate for Anthos and GKE] ページを開きます。
[ソース] タブで、[ソースを追加] をクリックします。
プルダウン リストから
migration-processing
クラスタを選択し、[次へ] をクリックします。移行の名前を
ledgermonolith-source
として指定します。[ソースの種類] を [Compute Engine] に設定し、[次へ] をクリックします。
適切なプロジェクトがソース プロジェクトとして選択されていることを確認します。
[サービス アカウントの新規作成] を選択して、移行元として Compute Engine を使用できるようにするサービス アカウントを作成します。
[次へ]、[ソースを追加] の順にクリックします。
移行計画を作成する
Cloud Console で [Migrate for Anthos and GKE] ページを開きます。
[移行] タブで、[移行の作成] をクリックします。
[移行名] に
ledgermonolith-migration
を設定します。前の手順で作成した移行元(
ledgermonolith-source
)を選択します。[ワークロード タイプ] を
Linux Image Based System Container
に設定します。ソースのインスタンス名に
ledgermonolith-service
を設定します。[移行を作成] をクリックします。これには 1~2 分ほどかかります
移行が完了すると、[ステータス] 列に [移行計画の生成完了] と表示されます。
テーブル内の移行の名前をクリックして、詳細ページを開きます。
ledgermonolith-migration
[YAML] タブを選択します。
移行計画の
dataVolumes
で、プレースホルダ<folder>
を VM の PostgreSQL データベースの場所/var/lib/postgresql
に置き換えます。オブジェクトは次のようになります。... 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: - /var/lib/postgresql ...
これにより、移行中のデータベースが確実に維持されるようになります。
移行計画の
deployment
で、サービスの名前がledgermonolith-service
、ポートが8080
、プロトコルがTCP
になっていることを確認します。オブジェクトは次のようになります。... endpoints: - name: ledgermonolith-service port: 8080 protocol: TCP ...
[アーティファクトを保存して生成] をクリックして移行プロセスを開始します。このプロセスには 7~8 分ほどかかります。
この VM に Migrate for Anthos and GKE が生成するアーティファクトは次のとおりです。
- VM プロセスの Docker イメージ。
- 新しく移行したプロセスを実行する StatefulSet と Service。
- コンテナ ランタイムを保持する Namespace と DaemonSet。
- PersistentVolumeClaim と PostgreSQL データベースを保持する PersistentVolume。
移行したワークロードをデプロイする
前のセクションでは、クラスタにデプロイできる一連の Kubernetes リソースにモノリス VM を移行しました。次に、これらのリソースを Bank of Anthos クラスタにデプロイして、新しく移行したソースサービスに適したエンドポイントと通信するようにアプリケーションを再構成し、すべてが機能していることを確認します。
これで移行アーティファクトが生成されました。処理クラスタに接続して、アーティファクトを Cloud Shell 環境にダウンロードできます。
gcloud container clusters get-credentials migration-processing --zone COMPUTE_ZONE --project PROJECT_ID
cd ${HOME}/bank-of-anthos/src/ledgermonolith/
migctl migration get-artifacts ledgermonolith-migration
Bank of Anthos クラスタに接続し、生成された Kubernetes リソースをデプロイします。さらに、クラスタに
migctl
を使用してコンテナ ランタイムをインストールして、新しく移行した Pod を実行できるようにします。gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE
migctl setup install --runtime
kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
Fetching cluster endpoint and auth data. kubeconfig entry generated for boa-cluster. applying resources to the cluster namespace/v2k-system created daemonset.apps/runtime-deploy-node created statefulset.apps/ledgermonolith-service created service/ledgermonolith-service-java created persistentvolumeclaim/data-pvc-0-4e1b2e0e-021f-422a-8319-6da201a960e5 created persistentvolume/pvc-4d41e0f2-569e-415d-87d9-019490f18b1c created
稼働中ではなくなったソースモノリス VM ではなく、新しい Kubernetes Pod を指すように、ソースホストを含む ConfigMap を編集します。
sed -i 's/'.c.PROJECT_ID.internal'//g' ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
すべての Pod を削除して、新しい構成で再作成します。
kubectl delete pods --all
次のコマンドを使用すると、Pod の状態を確認できます。
kubectl get pods
すべての Pod が起動して、動作するまで数分かかることがあります。
NAME READY STATUS RESTARTS AGE accounts-db-0 1/1 Running 0 5m43s contacts-d5dcdc87c-jbrhf 1/1 Running 0 5m44s frontend-5768bd978-xdvpl 1/1 Running 0 5m44s ledgermonolith-service-0 1/1 Running 0 5m44s loadgenerator-8485dfd-582xv 1/1 Running 0 5m44s userservice-8477dfcb46-rzw7z 1/1 Running 0 5m43s
すべての Pod が
Running
に設定されたら、frontend
LoadBalancer の外部 IP アドレスを確認できます。kubectl get service frontend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.79.248.161 ##.##.##.##. 80:31304/TCP 46m
ブラウザを開いて、上で確認した外部 IP アドレスのウェブページにアクセスします(HTTPS ではなく HTTP を使用してください)。
http://EXTERNAL_IP
デフォルトの認証情報でログインすると、トランザクションを確認できるはずです。表示されたトランザクションは、Kubernetes コンテナに移行されたソースのモノリスから送信されています。
次のステップ
VM ワークロードから移行計画を作成してカスタマイズする方法と、VM をコンテナ化されたアーティファクトに移行する方法を確認しました。チュートリアルの次のセクション、最適化に進んでください。
チュートリアルをここで終了する場合は、Google Cloud のプロジェクトとリソースを忘れずにクリーンアップしてください。
クリーンアップ
不要な Google Cloud 料金が発生しないようにするには、このチュートリアルで使用したリソースを、使用し終わったらすぐに削除する必要があります。こうしたリソースとしては、次のものがあります。
boa-cluster
GKE クラスタmigration-processing
GKE クラスタledgermonolith-service
Compute Engine VM
これらのリソースを手動で削除するか、以下の手順に沿ってプロジェクトを削除します。これにより、すべてのリソースが削除されます。