はじめに
前回のブログでは、無事に WordPress サイトの公開までたどり着けました。
しかし、実際のサービスでは、構築したら終わりではなく、その後の運用のほうが大事です。そして、Kubernetes はむしろ、運用のほうで本領を発揮します。
今回は、運用のなかでも特に以下にポイントを絞って、Kubernetes の機能をみてみます。
- アプリケーションのアップデート
- Pod に障害が発生した際の自動復旧
- スケールイン、スケールアウト
アプリケーションのアップデート
本番環境で新しいアプリケーションをリリースすることは非常に大変な作業です。
システムやアプリケーションによっては、ダウンタイムが発生するために、メンテナンス時間を設けなくてはいけないこともあります。
Kubernetes では、ダウンタイムなく、安全にアプリケーションのアップデートを行うことができます。
一例として、公式のイメージに少しだけ修正を加えたものをリリースしてみます。
前回の記事では wp-content 以下を Azure Files による共有領域としました。
実は、WordPress の Docker イメージは毎回、起動時にドキュメントルート以下にファイルを展開するため、
共有領域内のファイルを上書きしてしまいます。
(デフォルトファイルに修正を加えていない限り、影響はありませんが。)
これを解消するために、公式の Docker イメージをカスタマイズしてみましょう。
Azure Container Registory の準備
カスタマイズしたイメージを保管するためのレジストリを用意しましょう。
今回は、Azure にて用意されている Azure Container Registory (以下、ACR) を利用します。
ACR の画面を開きます。
レジストリ名やリージョンを選択します。
できました。
最後に、AKS から ACR にアクセスできるようにします。
これにより、マニュフェストにてレジストリ内のイメージを指定するだけで、AKS 上にデプロイすることができます。
1 | rworks@Azure:~/build$ az aks update -n wordpress-cluster -g wordpress --attach-acr rworks |
イメージのカスタマイズ
Docker ライブラリから、Dockerfile と docker-entrypoint.sh をダウンロードします。
https://github.com/docker-library/wordpress/tree/bf85cc7bf33afbbfadd86ba79b3d8ad325289057/php7.3/apache
1 | rworks@Azure:~/docker/wordpress$ ls |
2 | docker-entrypoint.sh Dockerfile |
docker-entrypoint.sh は、Docker の起動時に実行されるスクリプトです。
このなかに、WordPress の初期設定を行うコマンドが羅列してあります。
ここに、「展開する前のファイル群から wp-content ディレクトリを削除する」行を追記します。
1 | if [ "$user" != '0' ]; then |
3 | targetTarArgs+=( --no-overwrite- dir ) |
5 | + rm -rf /usr/src/wordpress/wp-content |
6 | tar "${sourceTarArgs[@]}" . | tar "${targetTarArgs[@]}" |
編集した docker-entrypoint.sh を反映させたイメージを、ビルドして、ACR にプッシュします。
“az acr build” コマンドを利用すれば、Azure 側でビルドが行われ、そのまま ACR にプッシュしてくれます。
ローカルにビルドするための環境を用意する必要はありません。
1 | rworks@Azure:~/build$ az acr build --image wordpress:v1 --registry rworks -- file DockerFile . |
2 | Packing source code into tar to upload... |
3 | Uploading archived source code from '/tmp/build_archive_922bf1d4cc1a431f9250e90182156ebf.tar.gz' ... |
4 | Sending context (349.000 Bytes) to registry: rworks... |
5 | Queued a build with ID: ce1 |
7 | 2020/04/13 14:53:56 Downloading source code... |
10 | registry: rworks.azurecr.io |
13 | digest: sha256:d9b24db8c01cf917cc17aeb48118a32293eb6fbf597a0b5154e9a51fd12c4257 |
15 | registry: registry.hub.docker.com |
16 | repository: library/wordpress |
18 | digest: sha256:191d5caf4ef5b8c57721ade777820f3267654325f7902b2ccd377ceeba1c3fe2 |
21 | Run ID: ce1 was successful after 1m4s |
“rworks.azurecr.io/wordpress:v1” を指定して pull できるようになりました。
カスタマイズしたイメージのデプロイ
deployment.yaml を書き換えて、新しいイメージをデプロイしてみましょう。
deployment.yaml の image を ACR 上のイメージに書き換えます。
4 | - image: rworks.azurecr.io/wordpress:v1 |
deployment を更新します。
1 | rworks@Azure:~$ kubectl apply -f deployment.yaml |
2 | deployment.apps/wordpress configured |
古い Pod が削除されるのと同時に、新しい Pod が作成されます。
既定では、このようにローリングアップデートが行われます。
2 | rworks@Azure:~$ kubectl get pod |
3 | NAME READY STATUS RESTARTS AGE |
4 | wordpress-5f59c6698b-cdjkq 0/1 ContainerCreating 0 0s |
5 | wordpress-5f59c6698b-jh2r4 1/1 Running 0 5s |
6 | wordpress-7b95946f7c-gdm8b 1/1 Running 0 88s |
7 | wordpress-7b95946f7c-vgnt4 1/1 Terminating 0 88s |
8 | rworks@Azure:~$ kubectl get pod |
9 | NAME READY STATUS RESTARTS AGE |
10 | wordpress-5f59c6698b-cdjkq 1/1 Running 0 14s |
11 | wordpress-5f59c6698b-jh2r4 1/1 Running 0 19s |
12 | wordpress-7b95946f7c-gdm8b 1/1 Terminating 0 102s |
13 | wordpress-7b95946f7c-vgnt4 1/1 Terminating 0 102s |
14 | rworks@Azure:~$ kubectl get pod |
17 | rworks@Azure:~$ kubectl get pod |
18 | NAME READY STATUS RESTARTS AGE |
19 | wordpress-5f59c6698b-cdjkq 1/1 Running 0 42s |
20 | wordpress-5f59c6698b-jh2r4 1/1 Running 0 47s |
23 | rworks@Azure:~$ kubectl get rs |
24 | NAME DESIRED CURRENT READY AGE |
25 | wordpress-5f59c6698b 2 2 2 51s |
26 | wordpress-7b95946f7c 0 0 0 2m14s |
万が一、アプリケーションに問題が生じた場合は、簡単にロールバックができます。
マニュフェスト deployment.yaml を編集前のものに戻して、再度、kubectl apply を実行します。
deployment を更新します。
1 | rworks@Azure:~$ kubectl apply -f deployment.yaml |
2 | deployment.apps/wordpress configured |
Pod は新しいものに置き換わっていますが、レプリカセットは一番初めのものに戻っていることが分かります。
2 | rworks@Azure:~$ kubectl get pod |
3 | NAME READY STATUS RESTARTS AGE |
4 | wordpress-7b95946f7c-d826x 1/1 Running 0 23s |
5 | wordpress-7b95946f7c-q7b2l 1/1 Running 0 29s |
8 | rworks@Azure:~$ kubectl get rs |
9 | NAME DESIRED CURRENT READY AGE |
10 | wordpress-5f59c6698b 0 0 0 11m |
11 | wordpress-7b95946f7c 2 2 2 12m |
このように、ダウンタイムのないアプリケーションのアップデートを簡単に行うことができます。
(削除される Pod と作成される Pod のタイミングによってはダウンタイムが発生することもあるので、パラメータは調整する必要があります。)
CI ツールと連携することで、アプリケーションのアップデートを完全自動化することも可能です。
Pod に障害が発生した際の自動復旧
Pod には Probe (ヘルスチェック) を設定することができ、Probe に失敗した際には自動で復旧させることができます。
Probe の方法には、”livenessProbe” と “readinessProbe” の2つのタイプがあります。
Probe 失敗後のアクションに違いがあり、前者は Pod の再作成が行われ、後者はサービスからのトラフィックが停止します。
デフォルトでは、livenessProbe が有効になっています。
今回は、livenessProbe を利用することにします。”httpGet” を指定することで、パス / の HTTP ステータスコードをチェックすることにします。
deployment.yaml の “template” 内に、以下の行を追加します。
9 | - image: rworks.azurecr.io/wordpress:v1 |
24 | + initialDelaySeconds: 30 |
Pod と MySQL の間に何らかの問題が発生し、一時的に接続できなかった場合を想定します。
wp-config のデータベース接続情報を書き換え、擬似的にこの状況を再現してみます。
1 | rworks@Azure:~$ kubectl exec -it wordpress-69b76dc56f-q4tgz /bin/ bash |
2 | root@wordpress-69b76dc56f-q4tgz:/var/www/html |
3 | root@wordpress-69b76dc56f-q4tgz:/var/www/html |
4 | define( 'DB_HOST' , 'hoge' ); |
上記の変更後、すぐに自動的に Pod が再作成されました。
EVents を見てみると、HTTP ステータスコード 500 が返ってきたことにより、Probe が失敗したあと、コンテナの再作成が行われていることがわかります。
Pod はマニュフェストから再作成されますので、当然、wp-config.php も元の正しい設定になっています。
1 | rworks@Azure:~$ kubectl get pod |
2 | NAME READY STATUS RESTARTS AGE |
3 | wordpress-69b76dc56f-5srbh 1/1 Running 0 5m28s |
4 | wordpress-69b76dc56f-q4tgz 1/1 Running 1 5m33s |
7 | rworks@Azure:~$ kubectl describe pod wordpress-69b76dc56f-q4tgz |
11 | Type Reason Age From Message |
12 | ---- ------ ---- ---- ------- |
13 | Normal Scheduled 2m10s default-scheduler Successfully assigned default/wordpress-69b76dc56f-q4tgz to aks-agentpool-23520908-vmss000000 |
14 | Warning Unhealthy 20s (x3 over 40s) kubelet, aks-agentpool-23520908-vmss000000 Liveness probe failed: HTTP probe failed with statuscode: 500 |
15 | Normal Killing 20s kubelet, aks-agentpool-23520908-vmss000000 Container wordpress failed liveness probe, will be restarted |
16 | Normal Pulling 18s (x2 over 2m8s) kubelet, aks-agentpool-23520908-vmss000000 Pulling image "rworks.azurecr.io/wordpress:v1" |
17 | Normal Pulled 18s (x2 over 2m6s) kubelet, aks-agentpool-23520908-vmss000000 Successfully pulled image "rworks.azurecr.io/wordpress:v1" |
18 | Normal Created 17s (x2 over 2m6s) kubelet, aks-agentpool-23520908-vmss000000 Created container wordpress |
19 | Normal Started 17s (x2 over 2m5s) kubelet, aks-agentpool-23520908-vmss000000 Started container wordpress |
このように、Kubernetes は障害発生時に自動で復旧することが分かりました。
これにより、常にマニュフェストで定義したとおりの状態が保たれます。
スケールイン、スケールアウト
Pod のスケールイン、スケールアウトは簡単です。
deployment.yaml の replicass の値を変更するだけです。
deployment を更新します。
1 | rworks@Azure:~$ kubectl apply -f deployment.yaml |
2 | deployment.apps/wordpress configured |
Pod が倍になりました。
1 | rworks@Azure:~$ kubectl get pod |
2 | NAME READY STATUS RESTARTS AGE |
3 | wordpress-f6997b7bc-4fdzt 1/1 Running 0 7s |
4 | wordpress-f6997b7bc-6ttrn 1/1 Running 0 7s |
5 | wordpress-f6997b7bc-7tqnv 1/1 Running 0 15m |
6 | wordpress-f6997b7bc-q4jth 1/1 Running 1 15m |
今回は手動で Pod の数を調整しましたが、オートスケール設定を行うことも可能です。
まとめ
コンテナの運用する際にポイントとなる、3つの機能について見てみました。
このように、Kubernetes はコンテナの運用を行う上での強力なツールとなることが分かっていただけたのではないでしょうか。
実際に本番環境にて運用する際には、さらに細かい調整が必要になりますが、一連のブログで「Kubernetes とは何なのか」「Kubernetes では何が出来るのか」をいただき、Kubernetes 利用の手助けになれば幸いです。
Tag:
コンテナ
Kubernetes