1. はじめに
モノリシック アプリケーションをマイクロサービス アーキテクチャに移行する理由は何でしょうか。アプリケーションをマイクロサービスに分割することには、次のようなメリットがあります。その多くはマイクロサービスが疎結合であることに起因しています。
- マイクロサービスは個別にテストしてデプロイできます。デプロイ単位が小さいほど、デプロイが容易になります。
- 異なる言語やフレームワークで実装できます。マイクロサービスごとに、ユースケースに最適なテクノロジーを自由に選択できます。
- 異なるチームで管理できます。マイクロサービス間の境界により、1 つのチームが 1 つまたは複数のマイクロサービスを簡単に管理できます。
- マイクロサービスに移行することで、チーム間の依存関係が緩和されます。各チームは、依存しているマイクロサービスの API のみを考慮し、マイクロサービスの実装方法やリリース サイクルなどについて考える必要はありません。
- 障害に対する設計が簡単になります。サービス間に明確な境界があるので、サービスが停止した場合の対処方法を決定しやすくなります。
モノリスと比較した場合、マイクロサービスには次のような欠点があります。
- マイクロサービス ベースのアプリを構成するサービスの相互関係が明確でない場合が多く、システム全体の複雑さは増大する傾向があります。
- モノリスの内部と異なり、マイクロサービスはネットワークを介して通信を行うため、セキュリティ上の問題が発生することがあります。この問題を解決するために、Istio はマイクロサービス間のトラフィックを自動的に暗号化しています。
- サービス間のレイテンシのため、モノリシック アプローチと同じレベルのパフォーマンスを実現するのが困難な場合があります。
- システムの動作は、単一のサービスに起因するのではなく、多くのシステムとシステム間のやり取りによって引き起こされます。このため、本番環境でのシステムの動作を把握することは難しくなります（可観測性が低くなります）。Istio は、この問題の解決策となります。
このラボでは、Google Kubernetes Engine（GKE）でマイクロサービスを実行します。Kubernetes は、コンテナの管理、ホスト、スケーリング、デプロイを行うプラットフォームです。コンテナは移植性の高い手法で、コードをパッケージ化して実行します。それぞれのマイクロサービスを独自のコンテナ内で実行できるので、この手法はマイクロサービスのパターンにも適しています。
このラボでは、既存のモノリシック アプリケーションを Google Kubernetes Engine クラスタにデプロイし、それをマイクロサービスに分割します。
マイクロサービスのアーキテクチャ図
まず、モノリスを一度に 3 つのマイクロサービスに分割します。マイクロサービスには、「注文」、「プロダクト」、「フロントエンド」などがあります。Cloud Build を使用して各マイクロサービスの Docker イメージをビルドし、Cloud Shell 内からトリガーします。その後、Kubernetes Service タイプの LoadBalancer を使用して Google Kubernetes Engine（GKE）にマイクロサービスをデプロイして公開します。各サービスに対してこれを行うと同時に、モノリスからそれらをリファクタリングします。このプロセスでは、モノリスを削除する最後の段階まで、モノリスとマイクロサービスの両方を実行します。
ラボの内容
- モノリスからマイクロサービスへの分割方法
- Google Kubernetes Engine クラスタの作成方法
- Docker イメージの作成方法
- Docker イメージを Kubernetes にデプロイする方法
前提条件
- プロジェクトを作成するための管理者権限を持つ Google Cloud Platform アカウント、またはプロジェクト オーナーの役割を持つプロジェクト
- Docker と Kubernetes の基礎知識
2. 環境設定
セルフペース型の環境設定
Google アカウント（Gmail または Google Apps）をお持ちでない場合は、1 つ作成する必要があります。Google Cloud Platform コンソール（console.cloud.google.com）にログインし、新しいプロジェクトを作成します。
プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。
次に、Google Cloud リソースを使用して Container Engine API を有効にするために、Developers Console で課金を有効にする必要があります。
この Codelab をすべて実行しても費用はかかりませんが、より多くのリソースを使用する場合や実行したままにする場合は、コストが高くなる可能性があります（このドキュメントの最後にある「クリーンアップ」セクションをご覧ください）。Google Kubernetes Engine の料金については、こちらをご覧ください。
Google Cloud Platform の新規ユーザーは、$300 分の無料トライアルをご利用いただけます。
Google Cloud Shell
Google Cloud と Kubernetes はノートパソコンからリモートで操作できますが、この Codelab では Cloud 上で動作するコマンドライン環境である Google Cloud Shell を使用します。
この Debian ベースの仮想マシンには、必要な開発ツールがすべて揃っています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働するため、ネットワークのパフォーマンスと認証が大幅に向上しています。つまり、この Codelab に必要なのはブラウザだけです（はい、Chromebook で動作します）。
- Cloud Console から Cloud Shell を有効にするには、[Cloud Shell をアクティブにする]
をクリックします（環境のプロビジョニングと接続に若干時間を要します）。
Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自の PROJECT_ID が設定されていることがわかります。
gcloud auth list
コマンド出力
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
コマンド出力
[core] project = <PROJECT_ID>
なんらかの理由でプロジェクトが設定されていない場合は、次のコマンドを実行します。
gcloud config set project <PROJECT_ID>
PROJECT_ID が見つからない場合は、設定手順で使用した ID を確認するか、Cloud コンソール ダッシュボードで確認します。
Cloud Shell では、デフォルトで環境変数もいくつか設定されます。これらの変数は、以降のコマンドを実行する際に有用なものです。
echo $GOOGLE_CLOUD_PROJECT
コマンド出力
<PROJECT_ID>
- 最後に、デフォルトのゾーンとプロジェクト構成を設定します。
gcloud config set compute/zone us-central1-f
さまざまなゾーンを選択できます。詳しくは、リージョンとゾーン。
3. ソース リポジトリのクローンを作成する
シンプルなスタートページ、プロダクト ページ、注文履歴ページを備えた架空の e コマース ウェブサイトの既存のモノリシック アプリケーションを使用します。git リポジトリからソースのクローンを作成するだけで、後はマイクロサービスへの分割と Google Kubernetes Engine（GKE）へのデプロイに集中できます。
以下のコマンドを実行して Cloud Shell インスタンス内に git リポジトリのクローンを作成し、適切なディレクトリに移動します。NodeJS 依存関係もインストールするので、デプロイ前にモノリスをテストできます。このスクリプトの実行には数分かかる場合があります。
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
これにより、GitHub リポジトリのクローンが作成され、このディレクトリに移動して、アプリケーションをローカルで実行するために必要な依存関係がインストールされます。このスクリプトの実行には数分かかる場合があります。
4. GKE クラスタを作成する
作業用の開発環境が整ったので、モノリスをデプロイするための Kubernetes クラスタと、最終的にはマイクロサービスが必要です。クラスタを作成する前に、適切な API が有効になっていることを確認する必要があります。次のコマンドを実行して Container API を有効にし、Google Kubernetes Engine を使用できるようにします。
gcloud services enable container.googleapis.com
これで、クラスタを作成する準備ができました。次のコマンドを実行して、3 つのノードを持つ fancy-cluster という名前の GKE クラスタを作成します。
gcloud container clusters create fancy-cluster --num-nodes 3
クラスタの作成には数分かかることがあります。コマンドが完了したら、次のコマンドを実行して、クラスタの 3 つのワーカー VM インスタンスを確認します。
gcloud compute instances list
出力:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Google Cloud コンソールで Kubernetes クラスタと関連情報を表示することもできます。左上のメニューボタンをクリックし、[Kubernetes Engine] までスクロールして、[クラスタ] をクリックします。fancy-cluster というクラスタが表示されます。
これで、最初の Kubernetes クラスタが作成されました。
5. 既存のモノリスをデプロイ
このラボではモノリスのマイクロサービスへの分割について説明することを目指しているため、モノリシック アプリケーションを起動して実行する必要があります。このラボで使用する次のスクリプトを実行して、モノリシック アプリケーションを GKE クラスタにデプロイします。
cd ~/monolith-to-microservices ./deploy-monolith.sh
モノリスへのアクセス
モノリシック アプリケーションの外部 IP アドレスを確認するには、次のコマンドを実行します。
kubectl get service monolith
出力は次のようになります。
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
注: これには、外部ロードバランサと IP をプロビジョニングする必要があるため、ある程度時間がかかります。出力に外部 IP が
<pending> 数分待ってから、もう一度試します。
モノリスの外部 IP アドレスを決定したら、その IP アドレスをコピーします。ブラウザにこの URL（http://203.0.113.0 など）を指定して、モノリスにアクセスできるかどうかをチェックします。
上の画像のように、モノリシック ウェブサイトのスタートページが表示されます。スタートページは、フロントエンド マイクロサービスによって後で提供される静的ページです。これで、モノリスが完全に Kubernetes で動作するようになりました。
6. Orders をマイクロサービスに移行する
既存のモノリス ウェブサイトを GKE で実行できるようになったので、各サービスのマイクロサービスへの分割を開始します。通常、プランニング業務では小さなまとまりに分割するサービスの選定を行います。ビジネス ドメインなどのアプリケーションの特定の部分が対象となります。ここではデモを目的として、簡単な例を作成し、ビジネス ドメイン、注文、プロダクト、フロントエンドに関する各サービスを分割しました。コードはすでに移行されているので、ここでは Google Kubernetes Engine（GKE）でのサービスのビルドとデプロイに焦点を当てます。
新しい注文マイクロサービスを作成する
最初に分割するサービスは、Orders サービスです。提供された個別のコードベースを利用し、このサービス用の個別の Docker コンテナを作成します。
Google Cloud Build を使用して Docker コンテナを作成する
コードベースはすでに移行済みなので、最初のステップは、Google Cloud Build を使用して Orders サービスの Docker コンテナを作成することです。
通常、Docker コンテナを作成するには 2 ステップのアプローチを取る必要があります。具体的には、Docker コンテナをビルドするステップと、ビルドしたコンテナをレジストリに push してそのイメージを保管し、GKE がそこからイメージを pull できるようにするステップです。しかし、作業を楽にすることができます。1 つのコマンドで、Google Cloud Build を使用して Docker コンテナをビルドし、イメージを Google Cloud Container Registry に配置できます。これにより、イメージをビルドして Container Registry に移動するための単一のコマンドを発行できます。手動で Docker ファイルを作成して push するプロセスを確認するには、こちらをご覧ください。
Google Cloud Build は、ディレクトリにあるファイルを圧縮して Google Cloud Storage バケットに移動します。その後、ビルドプロセスでそのバケットからすべてのファイルを取得し、Dockerfile を使用して Docker ビルドプロセスを実行します。Docker イメージのホストを gcr.io として --tag フラグを指定したため、生成される Docker イメージは Google Cloud Container Registry に push されます。
次のコマンドを実行して、Docker コンテナをビルドし、ビルドしたコンテナを Google Container Registry に push します。
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
このプロセスが完了するまでには数分かかります。完了すると、ターミナルに次のような結果が出力されます。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
ビルド履歴を表示したり、プロセスをリアルタイムで確認したりするには、Google Cloud コンソールに移動します。左上のメニューボタンをクリックして [ツール] → [Cloud Build] までスクロールし、[履歴] をクリックします。ここには過去のすべてのビルドのリストが表示されます。リストには、作成したばかりのビルドが 1 つだけ示されているはずです。
ビルド ID をクリックすると、そのビルドの詳細がすべて表示されます。詳細にはログ出力も含まれます。
[ビルドの詳細] ページでビルド情報セクションのイメージ名をクリックすると、作成されたコンテナ イメージが表示されます。
コンテナを GKE にデプロイする
ウェブサイトをコンテナ化して、そのコンテナを Google Container Registry に push したので、次は Kubernetes にデプロイします。
Kubernetes では、アプリケーションは Pod として表されます。Pod は、1 つのコンテナ（または密接に結合されたコンテナのグループ）を表す単位です。Pod は、Kubernetes でデプロイ可能な最小単位です。このチュートリアルでは、各 Pod にマイクロサービス コンテナのみが含まれています。
GKE クラスタにアプリケーションをデプロイして管理するには、Kubernetes クラスタ管理システムとの通信が必要になります。通常、これを行うには、Cloud Shell 内から kubectl コマンドライン ツールを使用します。
まず、Deployment リソースを作成します。Deployment は、アプリケーションの複数のコピー（レプリカと呼ばれる）を管理し、クラスタ内の個々のノード上で実行されるようにスケジューリングします。この場合、Deployment はアプリケーションの 1 つの Pod のみを実行します。これらの処理を行うために、Deployment は ReplicaSet を作成します。ReplicaSet の役割は、指定された数のレプリカが常に実行されるようにすることです。
以下の kubectl create deployment コマンドを実行すると、Kubernetes は 1 個のレプリカを持つクラスタに orders という名前の Deployment を作成します。
次のコマンドを実行して、アプリケーションをデプロイします。
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Deployment を確認する
Deployment が正常に作成されたことを確認するには、次のコマンドを実行します。Pod のステータスが [実行中] になるまで少し時間がかかることがあります。
kubectl get all
出力:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
この出力から、いくつかのことがわかります。現在の Deployment、目的の Pod 数が 1 の ReplicaSet、実行中の Pod を確認できます。すべて正常に作成されていることがわかります。
GKE コンテナを公開する:
アプリケーションを GKE にデプロイしましたが、クラスタの外部からアクセスする方法がありません。GKE で実行するコンテナには外部 IP アドレスがないため、デフォルトでは、このコンテナにインターネットからアクセスすることはできません。Service リソースを使用して、アプリケーションをインターネットからのトラフィックに明示的に公開する必要があります。Service は、アプリケーションの Pod にネットワーキングと IP サポートを提供します。GKE は、アプリケーションの外部 IP とロードバランサ（課金対象）を作成します。
Orders サービスをデプロイしたとき、Kubernetes Deployment を介して内部のポート 8081 に公開しました。このサービスを外部に公開するには、LoadBalancer タイプの Kubernetes Service を作成し、Orders サービス用の外部ポート 80 から内部ポート 8081 にトラフィックをルーティングする必要があります。次のコマンドを実行して、ウェブサイトをインターネットに公開します。
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Service へのアクセス
GKE は、Deployment ではなく Service リソースに外部 IP アドレスを割り当てます。GKE がアプリケーション用にプロビジョニングした外部 IP を確認するには、kubectl get service コマンドを使用して Service を調べます。
kubectl get service orders
出力:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
アプリケーションの外部 IP アドレスを確認したら、その IP アドレスをコピーします。新しい Orders サービスを指すようにモノリスを変更するときに、次のステップで使用できるように保存します。
モノリスを再構成する
Orders サービスをモノリスから削除したため、新しい外部の Orders マイクロサービスを指すようにモノリスを変更する必要があります。
モノリスを分割する場合、単一のコードベースから複数のコード部分を削除し、それらを個別にデプロイします。マイクロサービスは別のサーバーで実行されているため、サービス URL を絶対パスとして参照することはできないため、Order マイクロサービスの新しいサーバー アドレスへのルートが必要です。この場合、分割された各サービスの URL を更新するために、モノリス サービスでダウンタイムが必要になります。マイクロサービスの移行プロセス中にマイクロサービスとモノリスを本番環境に移行する際は、このダウンタイムを考慮してください。
新しい Orders マイクロサービスの IP アドレスを指すように、モノリスの構成ファイルを更新する必要があります。nano エディタを使用して、ローカル URL を新しい Orders マイクロサービスの IP アドレスに置き換えます。構成ファイルを編集するには、次のコマンドを実行します。
cd ~/monolith-to-microservices/react-app nano .env.monolith
エディタを開くと、ファイルは以下のようになっています。
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
REACT_APP_ORDERS_URL を新しい形式に置き換え、その際に IP アドレスを Orders マイクロサービスのものにします。つまり、以下のようになります。
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
CTRL+O、ENTER、CTRL+X の順に押し、nano エディタにファイルを保存します。
このファイルで設定した URL に移動して、新しいマイクロサービスをテストできます。Orders マイクロサービスから JSON レスポンスが返されます。
次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことで、モノリスのコンテナをビルドして GKE クラスタに再デプロイする必要があります。以下のコマンドを実行して、これらのステップを完了します。
モノリス構成ファイルを再ビルドする
npm run build:monolith
Google Cloud Build を使用して Docker コンテナを作成する
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
コンテナを GKE にデプロイする
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
ブラウザでモノリシック アプリケーションの Orders ページに移動して、アプリケーションが新しい Orders マイクロサービスに到達していることを確認します。以下に示すように、すべての Orders ID の末尾は -MICROSERVICE にする必要があります。
7. Products をマイクロサービスに移行する
新しいプロダクト マイクロサービスを作成する
次に Products サービスを移行することで、サービスの分割を継続できます。前のステップと同じプロセスに従います。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。
Google Cloud Build を使用して Docker コンテナを作成する
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
コンテナを GKE にデプロイする
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
GKE コンテナを公開する:
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
注文サービスの場合と同じ方法で、次のコマンドを使用して Products サービスのパブリック IP を見つけます。
kubectl get service products
出力:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
新しい Products マイクロサービスを指すようにモノリスを再構成するときに、次のステップ用に IP アドレスを保存します。
モノリスを再構成する
nano エディタを使用して、ローカル URL を新しいプロダクト マイクロサービスの IP アドレスに置き換えます。
cd ~/monolith-to-microservices/react-app nano .env.monolith
エディタを開くと、ファイルは以下のようになっています。
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
REACT_APP_PRODUCTS_URL を新しい形式に置き換え、その際に IP アドレスを Product マイクロサービスのものにします。つまり、以下のようになります。
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
CTRL+O、ENTER、CTRL+X の順に押し、nano エディタにファイルを保存します。
このファイルで設定した URL に移動して、新しいマイクロサービスをテストできます。Products マイクロサービスから JSON レスポンスが返されます。
次に、モノリス フロントエンドを再ビルドし、ビルドプロセスを繰り返すことで、モノリスのコンテナをビルドして GKE クラスタに再デプロイする必要があります。以下のコマンドを実行して、これらのステップを完了します。
モノリス構成ファイルを再ビルドする
npm run build:monolith
Google Cloud Build を使用して Docker コンテナを作成する
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
コンテナを GKE にデプロイする
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
ブラウザでモノリシック アプリケーションの Products ページに移動して、アプリケーションが Products マイクロサービスに到達していることを確認します。以下に示すように、すべての Products 名の先頭は MS- にする必要があります。
8. フロントエンドをマイクロサービスに移行する
移行プロセスの最後のステップは、フロントエンド コードをマイクロサービスに移動して、モノリスをシャットダウンすることです。このステップが完了すると、モノリスがマイクロサービス アーキテクチャに正常に移行されます。
新しいフロントエンド マイクロサービスを作成する
最後の 2 つのステップと同じ手順で、新しいフロントエンド マイクロサービスを作成します。
以前は、モノリスを再ビルドするときに、モノリスを指すように構成を更新しましたが、フロントエンド マイクロサービスに同じ構成を使用する必要があります。次のコマンドを実行して、マイクロサービスの URL 構成ファイルをフロントエンド マイクロサービスのコードベースにコピーします。
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
完了すると、これまでのステップと同じプロセスが行われます。以下のコマンドを実行して Docker コンテナをビルドし、ビルドしたコンテナをデプロイして Kubernetes Service 経由で公開します。
Google Cloud Build を使用して Docker コンテナを作成する
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
コンテナを GKE にデプロイする
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
GKE コンテナを公開する:
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
モノリスを削除する
すべてのサービスがマイクロサービスとして実行されたので、モノリシック アプリケーションを削除できます。実際の移行では、アプリケーションの新しいフロントエンド マイクロサービスを指すように既存のドメイン名を取得するために DNS の変更なども必要になります。次のコマンドを実行して、モノリスを削除します。
kubectl delete deployment monolith kubectl delete service monolith
作業内容をテストする
すべてが機能していることを確認するには、モノリス サービスの古い IP アドレスが機能せず、フロントエンド サービスの新しい IP アドレスが新しいアプリケーションをホストしている必要があります。すべてのサービスと IP アドレスのリストを表示するには、次のコマンドを使用します。
kubectl get services
出力は次のようになります。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
フロントエンド マイクロサービスの外部 IP アドレスを決定したら、その IP アドレスをコピーします。ブラウザにこの URL（http://203.0.113.0 など）を指定して、フロントエンドにアクセスできるかどうかをチェックします。ウェブサイトは、モノリスをマイクロサービスに分割する前のものと同じである必要があります。
9. クリーンアップ
完了したら、実行したすべてのアクティビティをクリーンアップする最も簡単な方法は、プロジェクトを削除することです。プロジェクトを削除すると、この Codelab 内で作成されたすべてのリソースが削除され、予期しない定期的な請求が発生しません。Cloud Shell で次のコマンドを実行します。ここで、PROJECT_ID はプロジェクト名ではなく、完全なプロジェクト ID です。
gcloud projects delete [PROJECT_ID]
「Y」と入力して削除を確定してくださいメッセージが表示されます。
10. 完了
モノリシック アプリケーションをマイクロサービスに分割し、それらを Google Kubernetes Engine にデプロイしました。
次のステップ
次の Codelab で Kubernetes について詳しく学びましょう。
- Google Kubernetes Engine でのウェブサイトのデプロイ、スケーリング、更新
- Kubernetes で Node.js を使用して Slack Bot を構築する
- Spinnaker を使用した Kubernetes への継続的デリバリー
- Google Kubernetes Engine 上の Kubernetes に Java アプリケーションをデプロイする
参考情報
- Docker - https://docs.docker.com/
- Kubernetes - https://kubernetes.io/docs/home/
- Google Kubernetes Engine（GKE） - https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build - https://cloud.google.com/cloud-build/docs/
- Google Container Registry - https://cloud.google.com/container-registry/docs/
- モノリスからマイクロサービスへの移行 - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke