はじめに
クラスタ構成の MariaDB Server の開発・テスト環境を構築するのは同じ作業を何度も行う必要があり，手作業で行う場合，単純な作業ミスも起こりやすく，非常に非効率です。
そこで今回は Ansible を用いて自動的に MariaDB クラスタを構築する手順を解説致します。
Ansible とは
Ansible は Red Hat が開発するオープンソースの構成管理ツールで，元々は Ansible, Inc. により開発されていましたが，2015年10月に Red Hat により買収されています。
Playbook と呼ばれる YAML 形式のファイルで構成を記述します。競合ソフトウェアとは異なりエージェントレスですので，SSHでログインできればリモートホストの構成を変更することが可能です。
Vagrant とは
Windows / macOS 上で Linux 仮想マシン(VM)を複数起動する場合は Vagrant を Ansible と併用するのが非常に便利です。Vagrant では box と呼ばれる仕組みがあり，主要なLinuxディストリビューションのイメージがありますので，各VMにOSをインストールする手間が省けます。なお，Vagrant は Hashicorp により開発されています。
例えば，以下の Vagrantfile を用意したディレクトリで vagrant up を実行すると，最小構成の CentOS 7 をインストールした VM を作成，起動することができます。
Vagrantfile:
|
1 2 3 4 5 |
# -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| config.vm.box = "centos/7" end |
また，複数のVMをデプロイするのも非常に簡単です。
Vagrant が対応する Hypervisor(providerと呼ばれます) は以下のものがあります。
- VirtualBox
- Hyper-V
- Docker
- VMware (有償オプション)
なお，今回の実行環境では VirtualBox が非常に不安定なため，VMware Workstation 15 Pro を利用します。
テスト環境
以下のテスト環境を用いました。
| ホスト | OS: Windows 10 Pro 1803 |
|---|---|
| Ansible 2.5.2 | |
| Vagrant 2.2.2 | |
| Hypervisor: VMware Workstation 15 Pro | |
| ゲストVM | OS: CentOS 7.6.1810 |
| MariaDB Server 10.3.13 x 2 (Primary/Replica) | |
| MariaDB MaxScale 2.3.4 x 1 |
Vagrantfile
VM(仮想マシン)の構成(vCPU数，メモリサイズ)，OS，IPアドレス等を記述する Vagrantfile は以下のものを用いました。
|
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 |
# -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure(2) do |config| config.vm.box = 'centos/7' # config.vm.provider :virtualbox do |vb| # vb.memory = 1024 # vb.cpus = 1 # end config.vm.provider :vmware_workstation do |v| v.vmx['memsize'] = '1024' v.vmx['numvcpus'] = 1 end 1.upto(1) do |i| config.vm.define "mxs#{i}" do |node| node.vm.hostname = "mxs#{i}" node.vm.network :private_network, ip:"192.168.2.23#{i}" end end 1.upto(2) do |i| config.vm.define "server#{i}" do |node| node.vm.hostname = "server#{i}" node.vm.network :private_network, ip:"192.168.2.10#{i}" end end config.vm.provision 'ansible_local' do |ansible| ansible.playbook = 'provisioning/provision-replica.yml' end end |
Hypervisor として VirtualBox を用いる場合は，コメントアウトされている箇所の # を削除，反対に config.vm.provider :vmware_workstation do |v| … end のセクションをコメントアウトします。
上記の Vagrantfile では，合計 3台の CentOS 7 VM (メモリ: 1GB, vCPU: 1)を起動します。
Ansible Playbook
Ansible では Role という概念があり，Ansible で構成管理されるホスト毎に Role を割り当て，Role 毎に構成を変えることができます。今回は以下のようになっています。
| ホスト名 | Role | 役割 |
|---|---|---|
| mxs1 | maxscale | MaxScale |
| server1 | primary | MariaDB Primary Server |
| server2 | slave | MariaDB Replica Server |
メインの Playbook は以下のようになります。
|
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 |
- hosts: all vars: locale: en_US.UTF-8 keymap: jp106 zone: Asia/Tokyo become: yes user: vagrant roles: - common - hosts: mxs1 become: yes user: vagrant roles: - maxscale - hosts: server1 become: yes user: vagrant roles: - primary - hosts: server2 become: yes user: vagrant roles: - slave |
Vagrantfile に以下の記述がありますので，Playbook は provisioning ディレクトリに provision-replica.yml というファイル名で保存されています。
|
1 |
ansible.playbook = 'provisioning/provision-replica.yml' |
Vagrant による Ansible Playbookの実行
Vagrantfile で Ansible Playbook が指定されていますので，プロビジョニングを開始するには，Vagrantfile, provisioning ディレクトリがある ディレクトリで以下のコマンドを実行するだけです。
|
1 |
vagrant up |
Windows 上で Vagrant からプロビジョニングする場合，VM は一つずつシーケンシャルに実行されます。Linux 上で Ansible のみを用いる場合は並列実行されますので，以下のようなケースでは実行順に配慮する必要があります。
- Primary/Replica レプリケーションにおいて，Primary の GTID を取得後，Replica でレプリケーションを開始
- Galera Cluster において，最初のノードで galera_new_cluster を実行後，他ノードで mariadb service を開始
vagrant up 実行後，各 VM の構成の RECAP が以下のように，unreachable=0 failed=0 となっていれば，プロビジョニングは正常に完了しています。
|
1 2 3 4 5 6 7 8 |
PLAY RECAP ********************************************************************* mxs1 : ok=26 changed=23 unreachable=0 failed=0 PLAY RECAP ********************************************************************* server1 : ok=25 changed=22 unreachable=0 failed=0 PLAY RECAP ********************************************************************* server2 : ok=35 changed=13 unreachable=0 failed=0 |
各 VM への SSH ログイン
プロビジョニングされた各 VM へは，vagrant ssh コマンドを用いて SSH ログインできます。例えば mxs1 にログインするには vagrant ssh mxs1 を実行します。
これにより，パスワード入力なしに vagrant ユーザとして SSH ログインすることが可能で，vagrant ユーザは sudo で root にスイッチする権限を持っています。
|
1 2 3 4 5 6 7 8 9 10 |
$ vagrant ssh mxs1 Last login: Mon Mar 18 16:13:23 2019 from 192.168.8.2 [vagrant@mxs1 ~]$ maxctrl list servers ┌─────────┬───────────────┬──────┬─────────────┬─────────────────┬─────────┐ │ Server │ Address │ Port │ Connections │ State │ GTID │ ├─────────┼───────────────┼──────┼─────────────┼─────────────────┼─────────┤ │ server1 │ 192.168.2.101 │ 3306 │ 0 │ Master, Running │ 0-101-4 │ ├─────────┼───────────────┼──────┼─────────────┼─────────────────┼─────────┤ │ server2 │ 192.168.2.102 │ 3306 │ 0 │ Slave, Running │ 0-101-4 │ └─────────┴───────────────┴──────┴─────────────┴─────────────────┴─────────┘ |
maxctrl list servers の出力より，Vagrant / Ansible を用いて自動的に MaxScale + Primary/Replica クラスタをプロビジョニングできたことが確認できました。
まとめ
前回のブログ投稿にて，GKE(Google Kubernetes Engine)上に Helm Chart を用いて Primary/Replicaクラスタをデプロイする手順について解説いたしましたが，public cloud の使用料金が問題となる場合，/etc/maxscale.cnf や /etc/my.cnf.d/ 配下の設定ファイルを調整しながら開発・テストを行いたい場合には，ローカルVMを用いるメリットがあるかと存じます。
そうした要件がある場合は，Vagrant / Ansible を用い Primary/Replica クラスタを自動的に簡単にプロビジョニングすることで実行構築作業を効率化可能であることが確認できました。
なお，今回用いた Vagrantfile, Ansible Playbook 一式は以下の GitHub リポジトリにあります。
https://github.com/goto-satoru/ansible-provision-mariadb-primary-replica-cluster
