MariaDB 公式 Docker イメージ を試す

本記事は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* に変更されています。

正常に最新版の 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が有効となっていない場合,以下のようなエラーが発生します。

コンテナ・クラスタの作成

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

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

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

Helm クライアントのインストール

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

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

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

mariadb-kubernetes リポジトリのclone

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

Helm chart によりMaster-Slaveクラスタをインストール

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

Helm chart を用いて MariaDB Master-Slave replication cluster をデプロイします。

クラスタステータスの確認

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

pod に対して MariaDB monitor を実行

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

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

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

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

maxctrl list servers の実行

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

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

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

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

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

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

Helm chart のアンインストールとコンテナ・クラスタの削除

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

まとめ

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

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがMariaDBに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次