本記事はMariaDB Corporationより寄稿された記事となります
はじめに
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_* に変更されています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
$ 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 が起動できました。
Master-Slave x2 + MaxScale x2 クラスタ を Helm Chart で実行
以下の GitHub リポジトリにて，MariaDB Server の Master – Slave 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が有効となっていない場合，以下のようなエラーが発生します。
|
1 |
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. |
|
1 2 3 4 5 6 |
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 上で以下のコマンドを実行し，コンテナ・クラスタを作成します(かなり時間がかかります)。
|
1 |
gcloud container clusters create n3 --region=asia-northeast1-a --num-nodes=3 |
正常にクラスタが作成された場合，以下のような出力が得られます。
|
1 2 |
NAME LOCATION MASTER_VERSION MASTER_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 |
以下のコマンドで認証情報を取得します。
|
1 2 3 |
$ 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 にインストールします。
|
1 2 3 4 |
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 します。
|
1 2 |
cd .. git clone https://github.com/mariadb-corporation/mariadb-kubernetes.git |
Helm chart によりMaster-Slaveクラスタをインストール
サービスアカウントの作成，Helm の初期化等を行います。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
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 Master-Slave replication cluster をデプロイします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
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 |
クラスタステータスの確認
|
1 2 3 4 5 6 7 |
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 を実行しています。
|
1 |
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)を実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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用のユーザを作成します。
|
1 2 |
GRANT ALL ON *.* TO maxuser@'%' IDENTIFIED BY 'maxpwd'; FLUSH PRIVILEGES; |
MaxScale 経由で MariaDB に接続してみます。
|
1 2 3 4 5 6 7 8 9 10 |
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 を実行します。
|
1 2 3 4 5 6 7 8 9 10 11 |
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 のうち，一つを停止してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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 で確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 |
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 だったインスタンスが Master となっていることが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 |
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 を削除します。
|
1 2 |
cloudshell$ helm delete n3 --purge cloudshell$ gcloud container clusters delete n3 --region=asia-northeast1-a |
まとめ
今回は MariaDB Corporation 公式 Docker イメージと Helm chart を用いて Master-Slave レプリケーションクラスタと MaxScale を冗長構成としたシステムをデプロイしてみました。まだ開発の初期段階で不安定な面がありますが，簡単な開発テストや検証作業に活用頂ければと存じます(現時点では Helm chart は production 環境では用いないよう留意願います)。
執筆者情報
後藤 智(GOTO Satoru)
2017年6月よりMariaDB CorporationにてAPAC(Asia Pacific)地域におけるプリセールス業務を主に担当。現在は主に日本を担当。
この執筆者の他の記事をよむ
2017年6月よりMariaDB CorporationにてAPAC(Asia Pacific)地域におけるプリセールス業務を主に担当。現在は主に日本を担当。
この執筆者の他の記事をよむ
