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

Category：実践編

2020.05.17

目次 [非表示]

はじめに
Kubectl の使い方
Azure Files のマウントポイントについて
Kubernetes への WordPress デプロイ
まとめ

はじめに

インフラ側の準備が整ったので、いよいよ Kubernetes 上に WordPress を構築します。
公式の Docker イメージを利用して、WordPress の初期設定画面を表示させるところまでを行います。

Kubectl の使い方

Kubernetes の API を実行してくれるコマンド、kubectl を使ってオブジェクトを作成していきます。使い方は、これだけです。

`1`	`$ kubectl apply -f <マニフェスト.yaml>`

簡単に説明しておきます。

マニュフェスト (yaml) からオブジェクトを作成します。
“apply” はオブジェクトの状態によって、新規作成、更新、削除を判断して実行してくれます。

あとは、作った後に kubectl get を使って、ちゃんと出来たか確認します。問題がある場合は、kubectl describe で詳細を確認します。
このあとは基本的に、「マニフェストファイルを作成する」「kubectl apply を実行して、オブジェクトを作成する」をひらすら繰り返していきます。この流れを覚えてください。

`1`	`$ kubectl get <オブジェクトの種類> <オブジェクト名>`

`2`	`$ kubectl describe <オブジェクトの種類> <オブジェクト名>`

kubectl の実行環境は、AKS に接続できる環境であればどこでも構いません。
今回は、ローカル環境に kubectl をインストールするのが面倒なので、Azure Cloud Shell (bash) を使います。

どこからでもいいので、Azure ポータルの画面右側にある Shell アイコンをクリックします。
クリックすると、自動でストレージアカウントが作成され、Shell の実行環境にログインできます。(初回は結構、時間がかかります。)
この環境には、Azure CLI など一通りのコマンドが用意されています。

Azure Cloud Shell にログインできたら、以下のコマンドを実行して、AKS のクラスタに接続するための認証を行ってください。

`1`	`$ az aks get-credentials --resource-group <myResourceGroup> --name <myAKSCluster>`

Azure Files のマウントポイントについて

WordPress をデプロイする前に、Azure Files のマウントポイントについて補足しておきます。
(Kubernetes とは関係ないため、読み飛ばしても構いません。)

通常、WordPress の冗長化を行う場合は、外部ストレージのマウントポイントとしてドキュメントルートを指定します。
これにより、WordPress に関連するファイルを一式、サーバ間で共有することができます。
しかし、NFS のようなネットワークファイル共有を利用する場合、パフォーマンスの低下が発生します。
ユーザがアクセスするたびに、ネットワーク越しに php が実行されるわけですが、どうしてもこの部分でディスク I/O がボトルネックになってしまうためです。
(特に、Azure Files は SMB プロトコルをマウントしているため、NFS よりもパフォーマンスは低下してしまうようです。)

これの回避策として、今回はマウントポイントをドキュメントルート配下の wp-content に限定することにします。
これにより、プラグインや画像などのコンテンツは Azure Files 上に保存されます。代わりに、コアファイルの修正・アップデートを行う際は、Docker イメージの中に含めなくてはなりません。

Kubernetes への WordPress デプロイ

認証情報・接続情報

データベースのパスワード情報を設定します。
パスワードなので、Key, Value の組を暗号化してストアするオブジェクト、”secret” を利用することにします。

まずは、マニフェストファイルを作成します。
vim などを利用して yaml ファイルに以下を書き込み、保存します。
“WORDPRESS_DB_PASSWORD” は wordpress イメージ内で定義されている環境変数です。その下の “WORDPRESS_AUTH_KEY” から “WORDPRESS_NONCE_SALT” はシークレットキーとソルトと呼ばれるもので、管理画面へのログイン時に利用する Cookie を生成するものです。通常は自動で生成されて wp-config.php に書き込まれるのですが、今回は wp-config.php を Azure Files 上に配置しないため、全てのコンテナで同じ値を取れるよう、ここで指定します。(コンテナごとにこの値がバラバラだと、セッション維持ができなくなったしまいます。)また、格納するパスワードは Base64 でエンコードする必要があります。

1apiVersion: v1
2kind: Secret
3metadata:
4  name: db-secret
5type: Opaque
6data:
7  WORDPRESS_DB_PASSWORD: bzRlNzF5byFrYXNoaQ==
8  WORDPRESS_AUTH_KEY: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
9  WORDPRESS_SECURE_AUTH_KEY: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
10  WORDPRESS_LOGGED_IN_KEY: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
11  WORDPRESS_NONCE_KEY: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
12  WORDPRESS_AUTH_SALT: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
13  WORDPRESS_SECURE_AUTH_SALT: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
14  WORDPRESS_LOGGED_IN_SALT: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt
15  WORDPRESS_NONCE_SALT: Q01HYiBid21JUS1aYGZCTFBEZ1hRZVYxPCEoKW58WF0+Vy1UVjFRb1pvOzRyNGhld0xZUWYt

※ 参考 (Base64 でのエンコード)

`1`	`$` `echo` `-n` `'mypassword'` `\| base64`

保存した yaml ファイルに対して、kubectl apply を実行し、オブジェクトを作成します。

1rworks@Azure:~$ kubectl apply -f db-secret.yaml
2secret/db-secret created
3 
4rworks@Azure:~$ kubectl get secret db-secret
5NAME TYPE DATA AGE
6db-secret Opaque 1 8s

次に、接続先の情報を作成します。
こちらは、暗号化する必要のない Key,Value の組なので、configmap オブジェクトを利用します。

wp-config.yaml を作成します。

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: wp-configmap
5data:
6  WORDPRESS_DB_NAME: wordpress
7  WORDPRESS_DB_USER: wpadmin@wordpress-db-rworks
8  WORDPRESS_DB_HOST: wordpress-db-rworks.mysql.database.azure.com

オブジェクトを作成します。

1rworks@Azure:~$ kubectl apply -f wp-config.yaml
2configmap/wp-configmap created
3 
4rworks@Azure:~$ kubectl get configmap wp-configmap
5NAME DATA AGE
6wp-configmap 3 16s

ストレージ

まずは、Azure Files のパラメータを指定します。これは、”StorageClass” オブジェクトを利用します。(apiVersion がこれまでと異なります。マニフェストで指定する項目も異なることに注意してください。)

“azurefiles” という名前で、一番安い「標準のローカル冗長ストレージ」クラスを作成しましょう。azure-files-sc.yaml を作成します。
マウントする際の所有者を “www-data” にしておかないと、プラグインのアップロードができなくなるので、注意してください。また、パフォーマンス向上のため、キャッシュも有効にしておきます。

1kind: StorageClass
2apiVersion: storage.k8s.io/v1
3metadata:
4  name: azurefiles
5provisioner: kubernetes.io/azure-files
6mountOptions:
7  - dir_mode=0777
8  - file_mode=0777
9  - uid=33                  # ← apache の実行ユーザ (www-data)
10  - gid=33
11  - mfsymlinks
12  - nobrl
13  - cache=strict            # ← cache を有効に
14parameters:
15  skuName: Standard_LRS

オブジェクトを作成します。

1rworks@Azure:~$ kubectl apply -f azure-files-sc.yaml
2storageclass.storage.k8s.io/azurefiles created
3 
4rworks@Azure:~$ kubectl get storageclass azurefiles
5NAME        PROVISIONER                AGE
6azurefiles   kubernetes.io/azure-files   34d

次に、「PersistentVolumeClaim」と呼ばれる、外部ストレージを動的にプロビジョニングするためのオブジェクトを作成します。これにより、Azure Files から必要な分だけストレージを利用することができます。さきほど作成した “azurefiles” オブジェクトから 5GB 分をプロビジョニングする、という設定にしてみます。
azure-files-pvc.yaml を作成します。

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: azurefiles
5spec:
6  accessModes:
7    - ReadWriteMany
8  storageClassName: azurefiles
9  resources:
10    requests:
11      storage: 5Gi

オブジェクトを作成します。

1rworks@Azure:~$ kubectl apply -f azure-files-pvc.yaml
2persistentvolumeclaim/azurefiles created
3 
4rworks@Azure:~$ kubectl get pvc azurefiles
5NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
6azurefiles Bound pvc-937e9fd7-579e-11ea-b5a7-12252093dbe6 5Gi RWX azurefiles 48s

サービス

エンドユーザがアクセスするためのエンドポイントを作成します。
“Service” オブジェクトを利用して、Azure Load Balancer を使うように設定します。

service.yaml を作成します。

1apiVersion: v1
2kind: Service
3metadata:
4  name: wordpress
5  labels:
6    app: wordpress
7spec:
8  ports:
9    - port: 80
10  selector:
11    app: wordpress
12    tier: frontend
13  type: LoadBalancer
14  loadBalancerIP: 20.44.xxx.xxx  # ← Azure で取得したグローバルアドレス

service オブジェクトを作成します。

1rworks@Azure:~$ kubectl apply -f service.yaml
2service/wordpress created
3 
4rworks@Azure:~$ kubectl get service wordpress
5NAME        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
6wordpress   LoadBalancer   10.0.143.24   20.44.xxx.xxx   80:31121/TCP   20m

ここで Azure Load Balancer へのグローバルアドレス割り当てが行われます。

Deployment

いよいよ、コンテナ本体を作成します。”Deployment” オブジェクトとして、以下のような設定を作成します。

ReplicaSet は2つ
イメージ “WordPress” を利用
wp-config, secret オブジェクトからデータベース接続情報、シークレットキーを読み込む
Azure Files を /var/www/html/wp-content にマウント

1apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
2kind: Deployment
3metadata:
4  name: wordpress
5  labels:
6    app: wordpress
7spec:
8  replicas: 2                                 # ← Pod の数
9  selector:
10    matchLabels:
11      app: wordpress
12      tier: frontend
13  strategy:
14    type: Recreate
15  template:                                   # ← template となる Pod の定義
16    metadata:
17      labels:
18        app: wordpress
19        tier: frontend
20    spec:
21      containers:
22      - image: wordpress
23        name: wordpress
24        envFrom:                              # ← MySQL への接続情報と認証情報を全て読み込み
25        - configMapRef:
26            name: wp-configmap
27        - secretRef:
28            name: db-secret
29        ports:
30        - containerPort: 80
31          name: wordpress
32        volumeMounts:
33        - name: wordpress-persistent-storage
34          mountPath: /var/www/html/wp-content            # ← Azure Files のマウントポイント
35      volumes:
36      - name: wordpress-persistent-storage
37        persistentVolumeClaim:
38          claimName: azurefiles                # ← pvc の名前

オブジェクトを作成します。

`1`	`works@Azure:~$ kubectl apply -f deployment.yaml`

`2`	`deployment.apps/wordpress created`

WordPress サイトが無事にできたか、Azure Load Balancer のグローバルアドレスにアクセスしてみます。インストール画面が表示されたら、成功です。

以下の通り、Pod が2つ、動いていることが分かります。

1rworks@Azure:~$ kubectl get pod
2NAME                         READY   STATUS    RESTARTS   AGE
3wordpress-776f579889-6d859   1/1     Running   0          9m12s
4wordpress-776f579889-vxjpf   1/1     Running   0          9m34s