Kubernetes で WordPress サイトを公開してみる (Azure 環境構築編) | クラウド導入・システム運用ならアールワークスへ

Category：実践編

2020.05.16

はじめに
全体の構成
Azure 環境の構築
まとめ

はじめに

前回の記事では、Kubernetes についてざっと説明をしました。

今回は、Azure が提供している Kubernetes のマネージドサービス、”AKS” を使って、
実際に WordPress サイトを公開してみます。

これによって、Kubernetes の使い方を理解してもらえればと思います。

全体の構成

まず、大前提として Docker イメージはステートレスでなければなりません。

コンテナは常にイメージから作成されるため、イメージに反映されていないデータ更新はコンテナ作り直しのタイミングで消えてしまいます。

WordPress のステートレスでない部分は、

画像、プラグインなどのファイル
データベース

の2つです。

クラウド上に Kubernetes を構築する場合、これらの格納先として、マネージドサービスのストレージやデータベースを利用することが一般的です。

今回は Azure のストレージサービス「Azure Files」とデータベースサービス「Azure SQL Database for MySQL」を利用します。

また、アプリケーションのフロントエンドを HTTPS として公開するには、Azure Application Gateway などの L7 ロードバランサーが必要です。
ただ、DNS の設定や証明書の用意など、本筋から外れてしまう作業が多いので、今回は HTTP で公開することにします。これは、AKS 作成時にクラスタと一緒に作成される Azure Load Balancer (L4ロードバランサー)を使うと簡単です。

Azure 環境の構築

AKS

さっそく、AKS を作成してみます。

Azure portal にログインして、”Kubernetes サービス” を開きます。
[Kubernetes サービスの作成] をクリックします。

クラスタの名前やノードサイズ、ノード数などを指定します。

ここでいうノードとは、クラスタを構成する仮想マシンのことです。今回はテスト用となので、最小スペックで “2” 台とします。

次は、スケーリング機能の設定です。クラスタの負荷状況に合わせて、ノードが増えたり減ったりします。スケーリング機能はマネージドサービスの醍醐味なので、”VM Scale Sets” を有効にしておきましょう。

AKS にアクセスする際の認証設定です。デフォルトのままにしておきます。

ネットワーク構成です。
[ロードバランサー] 項目があることから分かるとおり、自動的に Azure Load Balancer が作成されて、AKS クラスタと連携します。また、AKS は Azure のネットワークである VNet 上に作成されます。[ネットワーク構成] を “Basic” にすると、VNet を自動で作成してくれます。AKS を配置する VNet には様々な前提条件を満たさなければならないため、自動で作ったほうが無難です。[HTTP アプリケーションのルーティング] を “はい” にしておくと、簡易的な Ingress コントローラが利用できるようになります。今回は Ingress ではなく、Service を使いますので、どちらでも構いません。

[監視] [タグ] はデフォルトのままで OK です。最後に内容を再確認し、クラスタを作成します。

できました。

Azure Load Balancer も作成されています。

“仮想ネットワーク” の画面から、AKS 専用の VNet が作成されていることを確認してみます。”aks-vnet-23520908″ という /8 の VNet の中に、”aks-subnet” という /16 のサブネットが作成されています。

Azure SQL Database for MySQL

Azure SQL Database for MySQL を作成して、AKS から接続できるようにします。作成するのは簡単なのですが、ネットワーク周りで少しポイントがあります。

Azure SQL Database for MySQL を作成する際、配置する VNet を指定する必要はありません。というより、指定することができません。
PaaS ですので、どのネットワークに作成されたかはわからず、接続先となるエンドポイントだけが払い出されます。ユーザは、これにインターネット経由で接続することになります。

ただ、セキュリティのことを考えると、インターネット経由でデータベースに接続するのは心配です。
これの解決策として、”サービスエンドポイント経由の接続” と “プライベートエンドポイント経由の接続” という2種類の接続方法が提供されています。

https://docs.microsoft.com/ja-jp/azure/mysql/concepts-security#network-security

“サービスエンドポイント経由の接続” では、特定の VNet から Azure ネットワーク内を経由して Azure SQL Database for MySQL に接続を行います。設定は接続元となる VNet 側で行います。
“プライベートエンドポイント経由の接続” では、プライベート IP を返すエンドポイントが払い出され、これに対して接続を行います。設定は、接続先となる Azure SQL Database for MySQL 側で行います。
どちらもインターネットを経由することなく Azure SQL Database for MySQL にアクセスができ、今回のケースでは違いはありません。個人的には後者のほうが直感的に理解しやすいため、今回はプライベートエンドポイントを利用することにします。
(似たような概念ですが仕組み、ネットワーク構成は全く異なります。出来ることも異なりますので、用途に合わせて選んでください。なお、プライベートエンドポイントのほうが後からリリースされたサービスです。)
はじめに、Azure SQL Database for MySQL を作成します。

サーバ名と場所、MySQL エンジンのバージョン、価格レベル (スペック)、ユーザ情報くらいしか指定することがありません。完全な PaaS といった感じです。なお、残念ながらプライベートエンドポイントは、価格レベルが「汎用」タイプもしくは「メモリ最適化」タイプでないと対応していません。

できました。

次に、作成した Azure SQL Database for MySQL に対して、プライベートエンドポイントを作成します。
[プライベートエンドポイント] のメニューを開きます。

名前とリージョンを指定します。

プライベートエンドポイントを割り当てるリソースを選択します。先程、作成した Azure SQL Database for MySQL を指定します。

接続元となる VNet を選択します。プライベートエンドポイントは、この VNet 内に作成され、これを経由して Azure SQL Database for MySQL に接続することになります。Azure SQL Database for MySQL のインターフェイスとして、プライベート IP が割り振られるわけではないので、注意してください。

確認して、作成します。

できました。
Azure SQL Database for MySQL のエンドポイントに対して、プライベート IP が割り当てられています。先述のとおり、このプライベート IP は AKS が存在する VNet 内のアドレスになっています。

最後のダメ押しとして、プライベートエンドポイント以外からのアクセス許可設定が出来ないようにします。
Azure SQL Database for MySQL のメニューから [接続のセキュリティ] を開きます。
アクセス許可設定が何も入っていないので、このままでもインターネット経由のアクセス、及び、サービスエンドポイントからの接続はできません。(なお、プライベートエンドポイントからの接続はアクセス許可設定の影響を受けません。)
ここで、[Deny public network access] を “はい” にすると、許可設定がロックされ、設定の追加ができなくなります。
合わせて、[SSL 接続を強制する] は “無効” にしておきましょう。

これで、AKS から Azure SQL Database for MySQL に接続できるようになりました。ここで一旦、接続確認をしたいところですが、初期設定のままではクラスタノードにログインできないため、確認は一番最後にします。

Azure Files

Azure Files は SMB プロトコルでアクセスできる、マネージドファイル共有サービスです。Kubernetes で利用する際に、Azure 側での設定は必要ありません。
Kubenetes 側で呼び出すと、自動でストレージアカウント(ユーザが利用できるストレージのリソース)が作成され、外部ストレージとしてマウントされます。
なお、ストレージ内のファイルは Azure ポータルから閲覧することもできます。