武井(Twitter:@noriyukitakei)です。Serviceについてお話したいと思います。Service環境にこのブログを移行しております。Service上で構築しました。たくさんの機能を低予算で実現してみました。システム構成からご説明致します。今回構築したシステムの構成図は以下のとおりです(図が細かいのでクリックして拡大して見てください)。弊社は以下の2つのブログを運用しており、今回この2つのブログを移行する必要がありました。Machineで稼働していましたが、今回一つのKubernetesクラスターに統合しました。IngressでL7ロードバランシングしています。フロントエンド用Nodeには負荷の低い静的HTML参照の処理を格安のBシリーズのVMで、バックエンド用Nodeには負荷の高い管理画面系の処理をFシリーズのコンピュート優先のちょっとお高めのVMで処理しています。MySQLを使っております。ご覧のとおり、(ほぼ)フルマネージドな環境となっております。それぞれの機能を詳細にご説明してまいります。Service言わずとしれた、Azureが提供するKubernetesのマネージドサービです。今回は2つのノードプールを作成し、それぞれフロントエンド用Node、バックエンド用Nodeと呼ばれるものがプール内で稼働しております。フロントエンド用Nodeは静的なHTML参照などの負荷の低い処理を行います。Cache」というものを使っており、一度ユーザーが参照したものは次回からは静的なHTMLを参照するようにしております。これは比較的負荷の軽い処理であり、これをフロントエンド用Nodeが担当します。このNodeにはBシリーズといわれる、あんまり性能は高くないけど安いVMを使っています。正確なインスタンスサイズはB2sであり、2020年1月9日現在(東日本リージョン)のお値段は、4,538円/月です。バックエンド用Nodeは、管理画面でブログを作成する処理を担当します。これはPHPで動作しますので、比較的処理が重いものであり、このNodeには、ちょっとお高めだけど高性能なFシリーズのVMを使っております。正確なインスタンスサイズはF2s_v2であり、2020年1月9日現在(東日本リージョン)のお値段は、8,928円です。Ingressで行い、URLで振り分けをしております。/wp-admin(管理画面のロケーション)以下のアクセスはバックエンド用Node、それ以外はフロントエンド用Nodeに振り分けています。IngressでSSLの終端も行っています。Ingress用のPodにL4でロードバランシングしています。Ingressによる負荷分散というブログに記載しております。RegistryAzureが提供するDockerイメージ用のプライベートリポジトリです。マネージドサービです。Registryに格納しております。VMWordPressの画像やプラグインは動的に変化するコンテンツですので、何らかの共有ストレージに格納して各Podから参照させる必要があります。Serviceで利用できるものは以下の3つがあります。詳細はこちら最初は1を試しました。Filesは、Azureで利用できるマネージドなファイルサーバーであり、SMBプロトコルを介して通信できます。Windowsからでも簡単にマウント出来て非常に便利です。マネージドなので、仮想マシンにsambaサーバー立てたときのように、面倒くさい管理も不要です。Filesを使ったらなぜかWordPressが激オソになりました。大量の細かいPHPファイルを読み込むのに時間がかかっていたようです。SMBというプロトコルのせいもあるのでしょうか?1ページ読み込むのに8秒くらいかかっていたので、使いものにならなく断念しました。言わずとしれたNFSです。これで激オソが解消されて、激ハヤになりました。́∀`*)ホッしかし、やっぱり今の時代VM使ったら負けみたいな風潮もあるようなないような感じですし、他にマネージドなストレージサービスないかなーと探していたところ、3に行き着きました。東日本リージョンで使える様になったのはつい最近のことらしいので、マジでいいタイミングでした。料金が高いです(T_T)こんなの払いきれません。いうことで結局2に落ち着きました。これが、「タイトルの(ほぼ)フルマネージド」の「ほぼ」が取れない所以です。ここもマネージドにできたら完璧だったのにー。(https://azure.sios.jp/)の2つのブログのコンテンツを格納して、それぞれのPodからマウントしています。図にしますと以下のようになります。WordPressは画像などのコンテンツはwp-contentディレクトリに格納する仕様になっています。(https://azure.sios.jp/)用のPodからそれぞれをNFSマウントします。VMのインスタンスサイズはB2sにしておりまして、2020年1月9日現在(東日本リージョン)のお値段は、4,129円/月くらいになります。MySQL言わずと知れた、Azureが提供するMySQLのマネージドなサービスです。WordPress用のデータベースとして使っています。ユーザーのブログ参照は先程ご説明したようにキャッシュプラグインを使いますので、静的なHTMLにアクセスすることになります。データベースへのアクセスが発生するのは管理画面での作業のみです。データベースへのアクセスは発生しません。vCoreにしております。お値段は、4337円/月です。(https://azure.sios.jp/)用になります。SendGridAzureが提供するメール送信のためのマネージドサービです。Freeでも25,000通/月のメールが送れますので、Freeにしています。構築しよう!!先程ご紹介した環境の構築方法をご説明致します。今後の手順でご紹介するリソースグループ名を始めとした各種名称は、適宜、ご自身の環境に合わせて修正してくださいませ。Registryの構築まずはKubernetesがコンテナを作成するためのイメージを持ってくるレジストリを作成します。通常はDockerHubなどの公開レポジトリを使うのではなく、クローズドなレポジトリを使います。Registryはそんなクローズドなレポジトリを提供してくれます。Azureポータルにアクセスして、「リソースの作成」をクリックします。Registry」が表示されますので、それをクリックします。「作成」をクリックします。「レジストリ名」はレジストリを一意に識別する任意の名称を入力します。後ほどこの値は、レジストリのホスト名の一部になりますので、よく考えて変な名前をつけないようにしましょう。「管理者ユーザー」は有効にしておいて下さい。詳細は後ほど説明します。SKUはとりあえず「Standard」にして下さい。後は、環境に合わせて適宜入力して、最後に「作成」をクリックします。Registryのリソースの作成が完了したら、左部メニューの「アクセスキー」をクリックして、「ログインサーバー」「ユーザー名」「パスワード(2つあるうちのいずれか)」をメモして下さい。ちなみにこのユーザーはテスト用に利用する管理用ユーザーです。Registryへの読み取り権限のみ)を割り当てて下さい。Serviceの構築です。Azureポータルにアクセスして、「リソースの作成」をクリックします。Service」が表示されますので、クリックします。「作成」をクリックします。「クラスター名」はKubernetesクラスターを一意に識別する任意の名称を入力して下さい。「ノードサイズ」は、コンテナが稼働するNodeの仮想マシンのサイズです。サイズの小さいのを選んでおいたほうがお財布に優しいです。後はご自分の環境に合わせて適宜入力して、最後に「確認および作成」をクリックします。入力項目を確認して「作成」をクリックします。かかるので、気長に待ちましょう。kubectlコマンドをインストールします。CLIをインストールしましょう。Macを想定しております。他の環境はここを参考にインストールしてくらはい。azure-cli次にkubectlをインストールします。install-clikubectlコマンドを動かすための認証情報を作成します。Serviceを作成したリソースグループ、norichan-aksはKubernetesクラスター名です。norichan-aksこれで準備は整いました。ノードプールの追加フロントエンド用Nodeはキャッシュされた静的なHTMLを処理するだけですので低価格のVMで、バックエンド用Nodeは管理画面での投稿処理などの高負荷な処理を行うので高価格・高性能なVMを使うと先程ご説明致しました。Serviceのノードプールという機能を使います。ノードプール単位でVMのインスタンスサイズを指定することが出来ます。イメージとしては以下の図みたいな感じです。Serviceのポータルのトップ画面の左部メニューで「ノードプール」をクリックします。「ノードプールの追加」をクリックします。「ノードプール名」に任意の名称、「OSの種類」はLinux、「Kubernetesバージョン」は現時点の最新のもの、「ノードサイズ」はF2s_v2、「ノード数」は2として、「追加」をクリックします。するとノードが以下のように追加されていることが確認できると思います。MySQLの構築Azureポータルにアクセスして、「リソースの作成」をクリックします。MySQL」と入力してエンターを押します。「作成」をクリックします。サブスクリプション、リソースグループはご利用の環境に応じたものを入力します。「サーバー名」はMySQLのホスト名の一部になりますので、慎重に考えてください^^;「管理者ユーザー名」「パスワード」はそのままMySQLのユーザー名とパスワードになります。「場所」はご利用の環境に近いところ、「バージョン」は5.7を選択してください。「サーバーの構成」をクリックしてください。「Basic」のタブをクリックしてvCoreを1にしてください。その他は以下のようにデフォルトのままで「OK」をクリックしてください。先程の画面に戻りますので、「確認および作成」をクリックしてください。「作成」をクリックして、しばらくすれば完了です\(^o^)/SendGridの構築Azureポータルにアクセスして、「リソースの作成」をクリックします。「SendGrid」と入力してエンターを押します。「作成」をクリックします。サブスクリプション、リソースグループ、場所はご利用の環境に応じたものを入力します。「Name」「Password」はSendGridポータルへのログインIDとパスワードになります。Tier」は「Free」を選択してください。details」は名前や会社名などを入力してください。Create」をクリックします。今回の構築に用いるWordPressのDockerイメージは以下のような構成になっております。VMにマウントする予定なのですが、どうやらWordPressのDockerイメージは、Docker起動時に実行されるエントリポイントdocker-entrypoint.shにより、wp-content配下にあるいくつかのプラグインやPHPファイルを上書きしてしまうということが発覚しました。VMのマウントを遅らせることができればいいのですが、そんなことはできそうもないので、docker-entrypoint.shを書き換えることとしました。画像など記事を構成するコンテンツがおいてあるディレクトリソースコードを読んでいると、どうやらDockerfileによって/usr/src/wordpress配下に解凍されたWordPress本体を、/var/www/htmlに展開し直しているようです。それを行っているのが15行目です。15行目で展開される前にwp-content配下のファイルをすべて消してしまえばいいのです。"${targetTarArgs[@]}"なので、16行目を追加しました。Registryへプッシュします。Serverを構築します。VMの構築の仕方は割愛します。VM編)のブログに記載のとおりに構築しております。Serverが一発でインストール出来ます。引数を3つ取りますが、3つ目の引数はNFSサーバーを公開するサブネットを指定します。指定しなければ、全てのサブネットに対して公開されますが、絞りたい場合は、AKSのノードが配置されているサブネットを指定して下さい。restartPersistentVolumeリソースの作成PersistentVolumeのマニフェストを以下のように作成します。先程構築したNFSサーバーのIPアドレスを指定します。先のスクリプトで指定した3つ目の引数のDATA_DIRECTORYを指定します。先程構築したNFSサーバーのIPアドレスを指定します。先のスクリプトで指定した3つ目の引数のDATA_DIRECTORYを指定します。/data適用します。pv.ymlPersistentVolumeClaimリソースの作成PersistentVolumeClaimのマニフェストを以下のように作成します。storageClassNameは必ず空にします。storageClassNameは必ず空にします。pvc.ymlヘルスチェックスクリプトの作成Kubernetesの死活監視(LivenessProbe&ReadinessProbe)のためにヘルスチェックスクリプトを作成します。WordPressはMySQLに接続できないと機能しないので、ヘルスチェックにはMySQLに対して簡単なクエリを投げて成功すれば200、失敗すれば500のHTTPステータスコードを返すようにします。{http_response_code(500);}?>完成したらwp-contentディレクトリ直下に配置します。Sercretリソースの作成WordPressの設定に必要な項目の中で、「データベースへ接続するパスワード」「各種SALT値」を格納したSecretリソースを作成します。XXXXXX適用します。secret.ymlNodeにラベルを付与フロントエンド用Node、バックエンド用NodeにそれぞれWordPress用のPodを1個ずつ割り当てます。そのためにAffinityを使います。Nodeにラベルを付与して、Podをデプロイするときに特定のラベルが付与されたNodeにスケジューリングするようにします。Nodeの情報を取得します。下記のように4つのNodeが表示されます。v1.14.8フロントエンド用Nodeにuser、バックエンド用Nodeにadminというラベルを付与します。(https://azure.sios.jp/)のブログページ(下図(2)と管理画面(下図(4))を構成するDeploymentリソースを作成する必要があります。(https://tech-lab.sios.jp/)のブログページを作成するためのマニフェストを以下のように定義します。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。Cacheプラグインのキャッシュファイル格納先を指定する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたtechlabディレクトリをマウントする。Registryからイメージをpullするためのシークレットをs定義する。env=userというラベルが付与されたNode(フロントエンド用Node)にPodをスケジューリングする。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。Cacheプラグインのキャッシュファイル格納先を指定する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたtechlabディレクトリをマウントする。Registryからイメージをpullするためのシークレットをs定義する。env=userというラベルが付与されたNode(フロントエンド用Node)にPodをスケジューリングする。(https://tech-lab.sios.jp/)の管理画面を作成するためのマニフェストを以下のように定義します。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。Cacheプラグインのキャッシュファイル格納先を指定する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたtechlabディレクトリをマウントする。Registryからイメージをpullするためのシークレットをs定義する。env=adminというラベルが付与されたNode(バックエンド用Node)にPodをスケジューリングする。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。Cacheプラグインのキャッシュファイル格納先を指定する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたtechlabディレクトリをマウントする。Registryからイメージをpullするためのシークレットをs定義する。env=adminというラベルが付与されたNode(バックエンド用Node)にPodをスケジューリングする。(https://azure.sios.jp/)のブログページを作成するためのマニフェストを以下のように定義します。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたossonazディレクトリをマウントする。Registryからイメージをpullするためのシークレットを定義する。env=userというラベルが付与されたNode(フロントエンド用Node)にPodをスケジューリングする。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたossonazディレクトリをマウントする。Registryからイメージをpullするためのシークレットを定義する。env=userというラベルが付与されたNode(フロントエンド用Node)にPodをスケジューリングする。(https://azure.sios.jp/)の管理画面を作成するためのマニフェストを以下のように定義します。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたossonazディレクトリをマウントする。Registryからイメージをpullするためのシークレットを定義する。env=adminというラベルが付与されたNode(バックエンド用Node)にPodをスケジューリングする。ローリングアップデートする際、次のPodの更新に移るまでの間隔を指定する。デプロイのタイムアウトで、この時間過ぎてもデプロイが成功しなければ中止する。RegistryにプッシュしたWordPressのイメージを指定する。Secretリソースに登録したデータベースのパスワードを環境変数に格納する。Secretリソースに登録したSALT値等をを環境変数に格納する。MySQLにSSLで接続するための設定を定義する。確実にRollingUpdateを行うためにApacheをGracefulにShutdownする。ヘルスチェック用の定義をする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Podがサービスインする準備ができているかどうかをチェックする。自前で作成したヘルスチェック用のPHPを指定する。MySQLへのSSL接続が安定するまで時間かかるので、ヘルスチェック開始を4分ほど遅らせる。Serverで作成したボリュームをマウントする。Serverのボリューム上に作成されたossonazディレクトリをマウントする。Registryからイメージをpullするためのシークレットを定義する。env=adminというラベルが付与されたNode(バックエンド用Node)にPodをスケジューリングする。admin作成したマニフェストを適用します。Ingressを作成します。Ingressによる負荷分散」でご紹介したとおりに進めます。Balancerに割り当てるパブリックIPアドレスを作成します。tsv</span>次にHelmをインストールします。ワタクシMacな環境なのでMac前提にお話します。バージョン3からTillerがいらなくなりました。helmHelmの公式レポジトリを追加します。IngressのPodを格納するNamespaceを作成します。Ingressを作成します。IngressのPodを何個作るかを指定します。2個以上として下さい。1個しか作らないと、万が一そのPodが落ちると、サービスがダウンしてしまいます。Serviceを見てみます。Balancerのリソースです。一つのnginx-nginx-ingress-1577021421-default-backendは、後述する負荷分散ルールを定義するマニフェストに定義したパスのどれにも該当しないときに振られるService(ClusterIP)です。BalancerにグローバルIPアドレスが割り当てられているのがわかります。このIPアドレスを外部DNSサービスにAレコードとして登録して下さい。次にNodePortとして公開します(必要なのはClusterIPだけなので、なぜNodePortが必要なのか不明ですが、公式のマニュアルにもそう書いてあります)。(https://azure.sios.jp/)のブログページと管理画面の合計4つのNodePortを作成します。以下のマニフェストを作成します。ossonaz-admin作成したマニフェストを適用します。nodeport.ymlIngressでSSL終端するための証明書と秘密鍵を格納します。server.crtを証明書、server.keyを秘密鍵とします。server.crt以下のマニフェストを作成します。Ingressによる負荷分散ルールを定義するためのものです。ingress.ymlというファイル名で保存します。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。SSL終端するための証明書が格納されたSecertを定義します。この構成では、ワイルドカード証明書で2つのサイトを同じ証明書で終端しています。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。それ用に作成したNodePortに振ります。SSL終端するための証明書が格納されたSecertを定義します。この構成では、ワイルドカード証明書で2つのサイトを同じ証明書で終端しています。azure.sios.jpデプロイします。旧WordPressから新WordPressにデータ移行を行う必要があります。本記事の本質ではないので詳細は割愛させていただきますが、以下の2つのデータを移行するのみで基本的にはOKです。(https://azure.sios.jp/)にアクセスしたら、きちんと表示されました(^o^)管理画面の動作もバッチリでした。気になるお値段は?月額のAzure使用料は以下の通りとなります。Serviceすごいですね。これだけの本格的なクラスタを(ほぼ)フルマネージドで構築できるんです。雑誌等の執筆依頼を受付しております。役に立たなかった1人がこの投稿は役に立ったと言っています。コメントをキャンセルメールアドレスは表示されません。Reserved.本サイトに掲載されている社名、製品名、サービス名等は各社の商標または登録商標です。プライバシーポリシーお問い合わせ。