モノリス VM の移行 - 移行とデプロイ
処理クラスタをセットアップし、Migrate to Containers をインストールすると、移行を実行する準備が整います。まず、処理クラスタに関連する移行元を追加し、VM の移行計画を生成します。この計画を確認して必要に応じてカスタマイズしたら、Kubernetes アーティファクトを生成し、アプリケーションの残りの部分がすでに実行されている GKE クラスタにデプロイします。
目標
このチュートリアルでは、次の方法を学習します。
- 移行元を追加する。
- VM ワークロードから移行計画を作成する。
- 移行計画を確認してカスタマイズする。
- 移行アーティファクトを生成して GKE クラスタにデプロイする。
始める前に
このチュートリアルは、調査と評価チュートリアルのフォローアップです。このチュートリアルを開始する前に、このページの手順に沿ってモノリス VM 上で調査ツールを実行し、処理クラスタを作成してください。
モノリス VM を停止する
移行中にデータが移動すると、意図しない中断やデータの破損が発生する可能性があります。このような問題を回避するため、移行を実施する前にモノリス VM を停止する必要があります。
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
ledgermonolith-service
VM の行の左端にあるチェックボックスをオンにします。ページの上部にある [停止] ボタンをクリックして、VM を停止します。
VM が完全に停止するまで待ちます。これには 1~2 分ほどかかります
VM を移行する
VM を移行する前に、移行元のプラットフォーム(Compute Engine または VMWare)を表す移行元を作成する必要があります。
移行元を追加する
Google Cloud コンソールで [Migrate to Containers] ページを開きます。
[移行元と候補] タブで、[ソースを追加] をクリックします。
[処理クラスタの選択] で、プルダウン リストから移行処理クラスタを選択し、[次へ] をクリックします。
移行元の名前を指定します(例:
ledgermonolith-source
)。[ソースの種類] を [Compute Engine] に設定し、[次へ] をクリックします。
適切なプロジェクトがソース プロジェクトとして選択されていることを確認します。
[サービス アカウントの新規作成] を選択して、移行元として Compute Engine を使用できるようにするサービス アカウントを作成します。
[続行]、[ソースを追加] の順にクリックします。
移行計画を作成する
Google Cloud コンソールで [Migrate to Containers] ページを開きます。
[移行] タブで、[移行の作成] をクリックします。
[移行名] に
ledgermonolith-migration
を設定します。前の手順で作成した移行元(
ledgermonolith-source
)を選択します。[ワークロード タイプ] を
Linux system container
に設定します。ソースのインスタンス名に
ledgermonolith-service
を設定します。[移行を作成] をクリックします。これには 1~2 分ほどかかります
移行が完了すると、[ステータス] 列に [移行計画の生成完了] と表示されます。
テーブル内の移行の名前をクリックして、詳細ページを開きます。
ledgermonolith-migration
[データ構成] タブで、VM の PostgreSQL データベース
/var/lib/postgresql
を移行する新しいボリュームを作成します。構成は次のようになります。volumes: - deploymentPvcName: ledgermonolith-db folders: # Folders to include in the data volume, e.g. "/var/lib/postgresql" # Included folders contain data and state, and therefore are automatically excluded from a generated container image - /var/lib/postgresql newPvc: spec: accessModes: - ReadWriteOnce resources: requests: storage: 10G
これにより、移行中のデータベースが確実に維持されるようになります。[保存] をクリックします。
移行計画の
deployment
で、サービスの名前がledgermonolith-service
、ポートが8080
、プロトコルがTCP
になっていることを確認します。オブジェクトは次のようになります。... endpoints: - name: ledgermonolith-service port: 8080 protocol: TCP ...
[アーティファクトを保存して生成] をクリックして移行プロセスを開始します。このプロセスには 7~8 分ほどかかります。
この VM の Migrate to Containers によって生成されるアーティファクトは次のとおりです。
- 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 --project=PROJECT_ID
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
これらのリソースを手動で削除するか、以下の手順に沿ってプロジェクトを削除します。これにより、すべてのリソースが削除されます。
次のステップ
- 最適化(Day 2)について学習する。