IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた(9.アクセステスト)
はじめに
「IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた」の 最終回、第9回です。
ここでは、 ブラウザからのアクセステストを行うとともに、 kubernetes のスケールアウト機能を見てみたいと思います。
実施内容は以下の通りです。
- ブラウザからのアクセス
- Pod のスケール
- テーブル情報のリセット
- 終わりに
第8回までに準備はすべて終わっていますので、ブラウザからアクセスすればよいだけです。
アクセスの経路は下図のオレンジの矢印です。
ブラウザからのアクセス
ブラウザからアクセスする際の URL は以下のような形式になっています。
http://ノードIP:ポート/コンテキストルート/クラス名
それぞれ以下の通りです。
項目 | 内容 | 確認方法概要 |
---|---|---|
ノードIP | kubernetes ノードのIP | kubectl get nodes -o wide |
ポート | NodePort で指定した公開用ポート | kubectl get svc |
コンテキストルート | アプリ作成の際に指定したプロジェクト名(と同じ) | eclipse のProject (のプロパティ) |
クラス名 | アプリ作成の際に指定したクラス名 | eclipse のProject のツリー |
それぞれ以下のようになっています。
■ノードのIP
# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.77.166.249 Ready <none> 9h v1.17.11+IKS 10.77.166.249 173.xxx.xxx.xxx Ubuntu 16.04.7 LTS 4.4.0-189-generic containerd://1.3.4
(※173.xxx.xxx.xxx の部分です)
■ポート
# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.21.0.1 <none> 443/TCP 9h
liberty-counter NodePort 172.21.135.121 <none> 8080:30080/TCP 53m
(※今回は 30080)
■コンテキストルート / クラス
■ URL
結局、今回の URL は以下の通りです。
http://173.xxx.xxx.xxx:30080/LibertyCounter/Counter
早速アクセスしてみます。
複数回アクセスするとカウンターがアップしていきます。
(複数Pod 状態の際、単純なリロードでは同じPod に行くようです。その場合 ハードリロードを行ってください。(ブラウザによってやり方が異なります。Chrome の場合 Ctrl + F5 ))
Pod のスケール
次に Pod の数を増やしてみます。 第8回で作成した yaml ファイルの replicas を 1->3 に増やしてみます。
# cat liberty-counter_Deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: liberty-counter
name: liberty-counter
spec:
replicas: 3
selector:
matchLabels:
app: liberty-counter
...(略)...
修正した yaml ファイルを apply します。
# kubectl apply -f liberty-counter_Deploy.yaml
deployment.apps/liberty-counter configured
# kubectl get pods
NAME READY STATUS RESTARTS AGE
liberty-counter-56b4795b97-9knbv 1/1 Running 0 114m
liberty-counter-56b4795b97-vflvs 1/1 Running 0 51s
liberty-counter-56b4795b97-vg8vv 1/1 Running 0 51s
Pod が3つになっていることがわかります。
新規 Pod は起動に少し時間がかかります。
その後、アクセスを繰り返すと以下のように負荷分散されていることが見て取れます。
(末尾 9knbv へのアクセスが多いのは、Pod を増やす前に何度もアクセスしていたからです。)
テーブル情報のリセット
今回、Db2 のテーブル情報をリセットする手段を作りこんでいません。
そのため、いろいろアクセスしていると古いデータがたまっていき見づらくなってきます。
参考にテーブル情報をリセットする方法を記載します。(これ以外のやり方もあります)
第5回のサンプルテーブルの作成を参考に、下記の SQL を発行します。
truncate table ユーザー名.test01 immediate
それで、テーブル内のデータが消去されます。
その後またアクセスを行うと、アクセス回数が1 から順次インクリメントされます。
終わりに
「IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた」では、
「クラウドの準備からアプリケーションを乗せて動かすまで」をできるだけシンプルに、
一通りやってみることにより理解を深めることを目指しました。
個人的には実際にやってみることにより一連の記事に書いた以上の様々なことを理解することができ、クラウドでためしてみる、ということのハードルが下がりました。
この一連の記事が、クラウド(特にIBM Cloud)に入門する方にとって少しでも役に立てば幸いです。
この先もまた、別のテーマで何か書いていければと思います。
←:IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた(8.IKS へのコンテナのデプロイ)
↑:IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた(1.概要)
終わった!と見せかけつつ番外編を追加しました!
→ 番外編.コンテナイメージのUpdate
Author And Source
この問題について(IKS + Db2 on IBM Cloud で DBアクセスアプリを動かしてみた(9.アクセステスト)), 我々は、より多くの情報をここで見つけました https://qiita.com/shimauma_Zzzzz/items/1f6943ba4038aeaa4a5d著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .