MariaDB 公式 Docker イメージ を試す

spacer

2018年10月から MariaDB Corporation がビルドする Docker イメージが公開されています。

New Certified Docker Images + Kubernetes Scripts Simplify MariaDB Cloud Deployments

今回は MariaDB 製品の Docker イメージに関して解説致します。

“Docker Official Images”

以前から Docker Hub にて,MariaDB Server の Docker イメージが公開されていますが,こちらには MariaDB Corporation は関与しておらず,Docker, Inc. がビルドしているイメージになります。

https://hub.docker.com/_/mariadb

判断基準としては,

  • MariaDBのアシカのロゴが古い(茶色,ヒゲがある)
  • MariaDB Server のイメージのみ

というところになります。

MariaDB Corporation 公式 Docker イメージ

これに対して MariaDB Corporation がビルド,公開している Docker イメージ は以下のリポジトリにあります。

https://hub.docker.com/u/mariadb

Docker, Inc. のリポジトリとの違いとしては,以下の項目が挙げられます。

  • MariaDBロゴが最新
  • MariaDB Server だけでなく,以下の3つの基本イメージが提供されている
    • mariadb/server
    • mariadb/columnstore
    • mariadb/maxscale
MariaDB Serverイメージのテスト

Docker が利用可能な実行環境で,MariaDB Server 10.3 を実行してみます。なお,環境変数が MYSQL_* ではなく,MARIADB_* に変更されています。

$ docker run -d -e MARIADB_ALLOW_EMPTY_PASSWORD=1 mariadb/server
Unable to find image 'mariadb/server:latest' locally
latest: Pulling from mariadb/server
6cf436f81810: Already exists
987088a85b96: Already exists
b4624b3efe06: Already exists
d42beb8ded59: Already exists
b1574e654b02: Already exists
47cef0578899: Already exists
ca5235c48a07: Already exists
1afc65bf1100: Already exists
4a7202153c67: Already exists
afde27354d1c: Already exists
0cb9b5028d59: Already exists
03d869bcab00: Already exists
983b304fe2cf: Already exists
0abf579f27cb: Already exists
Digest: sha256:b5762c478d38ae54c464e3ab63e10e0c3f951633ed7619d52fa3c22bcf36218a
Status: Downloaded newer image for mariadb/server:latest
9aa256dc66acee2a71f63d90c7c39d53e8233b96200ab50772eda61bc136d3f8

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
9aa256dc66ac        mariadb/server      "docker-entrypoint.s・   30 seconds ago      Up 30 seconds       3306/tcp            flamboyant_ride

$ docker exec -it 9aa256dc66ac mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.3.13-MariaDB-1:10.3.13+maria~bionic mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

正常に最新版の MariaDB Server が起動できました。

Primary-Replica x2 + MaxScale x2 クラスタ を Helm Chart で実行

以下の GitHub リポジトリにて,MariaDB Server の Primary-Replica x2 + MaxScale x2 構成の Helm Chart が公開されています。

https://github.com/mariadb-corporation/mariadb-kubernetes/tree/master/mariadb-enterprise

今回はこれを用いて GKE(Google Kubernetes Engine) 上で MariaDB Server をデプロイしてみます。

projectの作成

project, ゾーン, GKE クラスタ名は以下を用いるものとします。

  • project: mariadb-helm-1904
  • GCP zone: asia-northeast1-a
  • GKE cluster name: n3

なお,project では,Billing, Kubernetes API が有効になっている必要があります。必要なAPIが有効となっていない場合,以下のようなエラーが発生します。

ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Kubernetes Engine API is not enabled for this project. 
Please ensure it is enabled in Google Cloud Console and try again: 
visit https://console.cloud.google.com/apis/api/container.googleapis.com/overview?project=xxxxx-xxxxx to do so.
ERROR: (gcloud.services.enable) FAILED_PRECONDITION: Billing must be enabled for activation in project 'XXXXXXXXXXXXX' to proceed.
- '@type': type.googleapis.com/google.rpc.PreconditionFailure
  violations:
  - description: "billing-enabled: Project's billing account is not found. https://console.developers.google.com/project/XXXXXXXXXXXXX/settings"
    subject: 'XXXXXXXXXXXXX'
    type: serviceusage/billing-enabled
コンテナ・クラスタの作成

Google Cloud Shell 上で以下のコマンドを実行し,コンテナ・クラスタを作成します(かなり時間がかかります)。

gcloud container clusters create n3 --region=asia-northeast1-a --num-nodes=3

正常にクラスタが作成された場合,以下のような出力が得られます。

NAME  LOCATION           Primary_VERSION  Primary_IP    MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
n3    asia-northeast1-a  1.11.7-gke.4    34.85.xx.xx  n1-standard-1  1.11.7-gke.4  3          RUNNING

以下のコマンドで認証情報を取得します。

$ gcloud container clusters get-credentials n3 --region=asia-northeast1-a
Fetching cluster endpoint and auth data.
kubeconfig entry generated for n3.
Helm クライアントのインストール

Helm の GitHub リポジトリから最新版の Helm をダウンロード,/usr/local/bin にインストールします。

mkdir download
cd download
wget https://storage.googleapis.com/kubernetes-helm/helm-v2.13.0-linux-amd64.tar.gz
sudo tar xvf helm-v2.13.0-linux-amd64.tar.gz -C /usr/local/bin --strip-components=1 linux-amd64/helm

なお,Helm 最新版は以下からダウンロード可能です。

https://github.com/helm/helm/releases

mariadb-kubernetes リポジトリのclone

Google Cloud Shell のホームディレクトリに mariadb-kubernetes リポジトリを clone します。

cd ~
git clone https://github.com/mariadb-corporation/mariadb-kubernetes.git
Helm chart によりPrimary-Replicaクラスタをインストール

サービスアカウントの作成,Helm の初期化等を行います。

cd ..
cloudshell$ kubectl create serviceaccount -n kube-system tiller
serviceaccount/tiller created

cloudshell$ kubectl create clusterrolebinding tiller-binding --clusterrole=cluster-admin --serviceaccount kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller-binding created

cloudshell$ helm init --service-account tiller
$HELM_HOME has been configured at /home/foo/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

cloudshell$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "mariadb" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

Helm chart を用いて MariaDB Primary-Replica レプリケーションクラスタをデプロイします。

cloudshell$ helm install mariadb-kubernetes/mariadb-enterprise --name n3 --set VOLUME_SIZE=1G
NAME:   n3
LAST DEPLOYED: Sat Mar 16 12:14:15 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME               DATA  AGE
n3-mariadb-config  5     1s

==> v1/Deployment
NAME          READY  UP-TO-DATE  AVAILABLE  AGE
n3-mdb-mxs    0/2    2           0          1s
n3-mdb-state  0/1    1           0          1s

==> v1/Pod(related)
NAME                           READY  STATUS             RESTARTS  AGE
n3-mdb-ms-0                    0/2    Pending            0         0s
n3-mdb-mxs-5d7695c49-dcjrf     0/2    Init:0/1           0         0s
n3-mdb-mxs-5d7695c49-kbpfg     0/2    Init:0/1           0         0s
n3-mdb-state-6755978b7d-8btzw  0/1    ContainerCreating  0         0s

==> v1/Secret
NAME               TYPE    DATA  AGE
n3-mariadb-secret  Opaque  4     1s

==> v1/Service
NAME          TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)            AGE
n3-mariadb    ClusterIP  10.31.245.250         4006/TCP,4008/TCP  1s
n3-mdb-clust  ClusterIP  None                  3306/TCP           1s
n3-mdb-state  ClusterIP  10.31.241.192         80/TCP             1s

==> v1/StatefulSet
NAME       READY  AGE
n3-mdb-ms  0/3    1s
クラスタ・ステータスの確認
cloudshell$ kubectl get pods
NAME                            READY     STATUS     RESTARTS   AGE
n3-mdb-ms-0                     2/2       Running    0          1m
n3-mdb-ms-1                     0/2       Init:1/2   0          22s
n3-mdb-mxs-5d7695c49-dcjrf      2/2       Running    0          1m
n3-mdb-mxs-5d7695c49-kbpfg      2/2       Running    0          1m
n3-mdb-state-6755978b7d-8btzw   1/1       Running    0          1m

pod の ログの確認は以下のように行います。この例では,n3-mdb-ms-0 に対して kubectl logs を実行しています。

cloudshell$ kubectl logs n3-mdb-ms-0 --container=mariadb-server


pod に対して MariaDB monitor を実行

以下のように kubectl exec を用いて,docker exec のように pod に対してコマンドを実行することができます。この例では n3-mdb-ms-0 に対して mysql(MariaDB monitor)を実行します。

cloudshell$ kubectl exec -it n3-mdb-ms-0 -- mysql
Defaulting container name to mariadb-server.
Use 'kubectl describe pod/n3-mdb-ms-0 -n default' to see all of the containers in this pod.
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 216
Server version: 10.3.13-MariaDB-1:10.3.13+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

MariaDB Server 10.3.13 GA が稼働していることが確認できました。以下のSQL文を実行し,MaxScale用のユーザを作成します。

GRANT ALL ON *.* TO maxuser@'%' IDENTIFIED BY 'maxpwd';
FLUSH PRIVILEGES;

MaxScale 経由で MariaDB に接続してみます。

cloudshell$ kubectl run mariadb-client -i --tty --image=mariadb/server:10.3 \
 --restart=Never -- mysql -h n3-mariadb -P4006 -umaxuser -pmaxpwd
If you don't see a command prompt, try pressing enter.
MariaDB [(none)]> SELECT @@hostname;
+-------------+
| @@hostname  |
+-------------+
| n3-mdb-ms-1 |
+-------------+
1 row in set (0.002 sec)

n3-mdb-ms-1 に接続していることが確認できました。

maxctrl list servers の実行

MaxScale が実行されているいずれかの pod に対して maxctrl list servers を実行します。

cloudshell$ kubectl exec -it n3-mdb-mxs-5d7695c49-dcjrf \
 --container=maxscale -- maxctrl list servers
┌────────────┬────────────┬──────┬─────────────┬─────────────────┬───────────┐
│ Server     │ Address    │ Port │ Connections │ State           │ GTID      │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.0.12 │ 10.28.0.12 │ 3306 │ 0           │ Slave, Running  │ 0-3000-11 │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.1.8  │ 10.28.1.8  │ 3306 │ 0           │ Slave, Running  │ 0-3000-11 │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.2.6  │ 10.28.2.6  │ 3306 │ 0           │ Master, Running │ 0-3000-11 │
└────────────┴────────────┴──────┴─────────────┴─────────────────┴───────────┘

正常にレプリケーションが行われているようです。

MariaDB Server インスタンスの障害をテスト

3インスタンス稼働している MariaDB Server のうち,一つを停止してみます。

cloudshell$ kubectl get pods
NAME                            READY     STATUS      RESTARTS   AGE
mariadb-client                  0/1       Completed   0          6m
n3-mdb-ms-0                     2/2       Running     0          21m
n3-mdb-ms-1                     2/2       Running     0          20m
n3-mdb-ms-2                     2/2       Running     0          20m
n3-mdb-mxs-5d7695c49-dcjrf      2/2       Running     0          21m
n3-mdb-mxs-5d7695c49-kbpfg      2/2       Running     0          21m
n3-mdb-state-6755978b7d-8btzw   1/1       Running     0          21m

cloudshell$ kubectl delete pod n3-mdb-ms-0
pod "n3-mdb-ms-0" deleted

しばらくすると,1インスタンスが Down となっていることが maxctrl list servers で確認できます。

cloudshell$ kubectl exec -it n3-mdb-mxs-5d7695c49-dcjrf \
 --container=maxscale -- maxctrl list servers
┌────────────┬────────────┬──────┬─────────────┬────────────────┬───────────┐
│ Server     │ Address    │ Port │ Connections │ State          │ GTID      │
├────────────┼────────────┼──────┼─────────────┼────────────────┼───────────┤
│ 10.28.2.7  │ 10.28.2.7  │ 3306 │ 0           │ Down           │           │
├────────────┼────────────┼──────┼─────────────┼────────────────┼───────────┤
│ 10.28.0.12 │ 10.28.0.12 │ 3306 │ 0           │ Slave, Running │ 0-3000-11 │
├────────────┼────────────┼──────┼─────────────┼────────────────┼───────────┤
│ 10.28.1.8  │ 10.28.1.8  │ 3306 │ 0           │ Slave, Running │ 0-3000-11 │
└────────────┴────────────┴──────┴─────────────┴────────────────┴───────────┘

さらに時間をおいて maxctrl list servers を実行してみますと,さきほど Down だったインスタンスが Primary となっていることが確認できます。

cloudshell$ kubectl exec -it n3-mdb-mxs-5d7695c49-dcjrf \
 --container=maxscale -- maxctrl list servers
┌────────────┬────────────┬──────┬─────────────┬─────────────────┬───────────┐
│ Server     │ Address    │ Port │ Connections │ State           │ GTID      │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.2.7  │ 10.28.2.7  │ 3306 │ 0           │ Master, Running │ 0-3000-11 │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.0.12 │ 10.28.0.12 │ 3306 │ 0           │ Slave, Running  │ 0-3000-11 │
├────────────┼────────────┼──────┼─────────────┼─────────────────┼───────────┤
│ 10.28.1.8  │ 10.28.1.8  │ 3306 │ 0           │ Slave, Running  │ 0-3000-11 │
└────────────┴────────────┴──────┴─────────────┴─────────────────┴───────────┘
Helm chart のアンインストールとコンテナ・クラスタの削除

検証作業が完了しましたので,以下のコマンドを Cloud Shell で実行し,Helm chart と container cluster を削除します。

cloudshell$ helm delete n3 --purge
cloudshell$ gcloud container clusters delete n3 --region=asia-northeast1-a
まとめ

今回は MariaDB Corporation 公式 Docker イメージと Helm chart を用いて Primary-Replica レプリケーションクラスタと MaxScale を冗長構成としたシステムをデプロイしてみました。まだ開発の初期段階で不安定な面がありますが,簡単な開発テストや検証作業に活用頂ければと存じます(現時点では Helm chart は production 環境では用いないよう留意願います)。