Ansible による CentOS マシンの構築・OS 設定の管理一元化の試み〇長屋 貴量自然科学研究機構 分子科学研究所

技術推進部

１．はじめに
自分は分子科学研究所にて、Linux マシンの Web サーバーのセットアップ及びメンテナンスを数十台について行っている。これらマシンの詳細な設定を、別に控える、あるいはその設定を元に全く同一のマシンを作成する方法として、Ansible の存在を知ったため、実際に試行した結果を記す。

２．きっかけ自分は研究所の研究室・部門の要請から、CentOS 7 / OracleLinux 8 / RockyLinux 9 の Web サーバー(Apache のみ；nginx はない)のセットアップを行い、維持管理を行っている。また、利用している CMS(Contents Management System) は WordPress か Drupal か、あるいは単なる HTML ファイルを設置するか、程度であり、バラエティに富んでいるわけではない。また、分子科学研究所が属している 自然科学研究機構のセキュリティルールでは、所外に公開するような重要なサーバーについては、構成カタログの作成を義務付けている。
この構成カタログには、管理者は誰か／利用しているソフトウェアは何か という事を記載すれば十分であるが、ただ、この構成カタログを見ただけでは、詳細な設定の中身はどうなのか、という事はわからない。
このような状況下、自分は 2018 年の技術研究会に、構成をまとめられるソフトウェアを試したいと発表していた[1]。
その後、数年前に Chef の解説本[2]を見つけ、中を読んでみたが、エージェントをインストールするのが前提となっており、また、設定の記述方法が独特であり、自分には理解しづらいと感じた。
その後、職場の上司より、こんなソフト／書籍がある、と渡されたのが、Ansible の解説本であった[3]。
上司は既に一通り Ansible の使い方・設定方法は理解した、と言われており、では私も行ってみよう、というのがきっかけだった。
Ansible は有名な RedHat 社がバックについており、利用が廃れるのは他と比べてそんなに早くはないと感じた。
各マシンで設定する内容として、自分が扱っている OS は RedHat 系列であるため、Web サーバーとして設定する内容は似通っている。CMS を使うのであれば、データベースサーバーとして MySQL/MariaDB を使い、PHP を使うのであれば、OS 標準か、別のレポジトリ/必要なバージョンのものを入手する、という追加は発生するが、追加後に行う設定はやはり似通っている、という特色がある。

３．構成／設定方法の概要
３.１ マシンの初期設定/インストール
計算科学研究センターでは仮想基盤(KVM)を運用しており、この基盤上であれば仮想マシンの作成、クローン、削除は（実マシンに比べ）容易である。
インストールする OS が決まれば、定型的にディスクのパーティション、最低限の OS 構成でマシンをセットアップする。
（この部分は、Ansible などで設定を統一するものではない）

３.２ Ansible で SSH ログインできるよう設定
Ansible は、対象マシンに SSH ログインすることで各設定を確認・抽出、設定変更する。他ソフトのように、エージェントを追加インストールすることはない。そのため、対象マシン上で、su コマンドで管理者になれるようアカ
ウントの作成・権限の追加、および秘密鍵・公開鍵で SSHログインできるよう、設定を行う。
なお、管理者(root アカウント)で SSH ログインすれば、設定は容易になるだろうが、近年では root で直接ログインするのは避けるのが常識化しているため、この設定を入れている。
３.３ 実際に Ansible で設定を反映させる
SSH でログインできるようになれば、Ansible サーバー
図 1 実行時の画面例
側で、ansible のコマンドを実行する。
Ansible は、Web サーバーというロールであれば Web サーバー(=Apache)の設定を流し込んだり、データベースサーバー(=MariaDB)であれば MariaDB 用の設定を流し込んだり、という流れになっている。また、サーバー間で共通な設定もあれば、サーバー毎に異なる設定（例えば ホスト名）には、サーバー毎に異なる という設定を、何らかのファイルに記載すれば、よい。
具体的なコマンドとしては♯ ansible-playbook -i production rocky9.yml --check --diff --limit='draco'である。このコマンドの実行結果が 図 1 である。
上記のコマンドのオプションについて、
 -i : ホストの一覧が記載されている、インベントリファイルが何か を指定
 rocky9.yml : 構成する内容が記載されたファイル。今回は RockyLinux9 での共通の設定を記載している rocky9.yml を指定した(自作)。
 --check : 構成を記載したファイル内容と、実機の設定と一致しているかチェックするのみで、本当に設定を変更しないようにする。
 --diff : 構成ファイル内容と実機がどう違っているのかを表示させるオプション。
 --limit=’???’ : インベントリファイルには、対象マシンを複数列記できるが、何も指定しないと全部のマシンを対象に取ってしまう。通常は、新しく構築したマシン（今回は draco という名のマシン）について構成をチェックすれば十分であるため、対象はこのマシンだ と指定するオプションである。
３.４ Apache サーバー構築にかかった時間
全く新規なマシンを apache サーバーにするためにかかった時間は、（OS インストール完了後、）
 自分がコマンドをたたいて 1 つずつ設定している場合、数時間程度かかったり、設定し忘れた点がある事に後から気が付いたり、という事があった。
 Ansible 利用時では、5 分もかからず、構成の設定どおりのサイトができ、大幅なスピードアップとなった。
 （仮想マシンをクローンする方法だと、コピー元のマシンの設定がほとんどコピーされるため、ホスト名を変更し、DB 上のデータを削除することで完了するため、30 分程度で完了した。
）
３.５ 課題Ansible に触れてわかった課題として、まず最初に、構成内容を記載した .yml ファイルを準備するのが、非常に大変であった。一度作成できてしまえば、後は転用が効き、また新バージョンの OS が登場しても、大幅な書き換えは必要ない と考えるが、最初の壁を乗り越えるのが困難だった。この問題に関しては、上司が先に作成した .yml 構成を利用させていただいた。
また、構成する対象の OS によって設定のチェック時間に差が出るのだろうかと思ったが、大きく異なることはなかった。SSH 接続でチェックしているので、OS の差異よりは、何の構成の設定(Aapche なのかデータベースなのか)をチェックするか による時間差の方が大きい、という事を実体験した。

４．まとめ・考察
Ansible は最初の一歩は踏み出せたと考える。展開している公開サーバーを全て構成の対象にするのはまだできないが、実現すれば、機構のルールにある構成カタログよりも、詳細な設定が残せるうえに、同じ OS 設定でマシンを構築するのも手短になる、という感触を得た。
ただ、全く同じ用途のマシン、例えば WordPress をホストするマシンで有れば、仮想マシンをクローンする方が早いようにも感じた。
また、最初の構成ファイルの作成は非常に手間がかかった。
今回は Web サーバーおよびメーリングリストサーバーについて構成ファイルを作成したが、例えばDNS サーバーであれば、また 1 から作成すると考えると憂鬱になる。ただ、構成ファイルは、Ansible のサイトにて、例が存在すると参考文献[3]に記載があり、それを援用できるか、試してみたい。
また、構成を確認・反映させる以外に、対象マシンで単にコマンドを実行させることも可能と分かった。こちらを使えば、現在自分が SSH 接続を複数並列実行することで得ている各マシンの情報 [1]をAnsible で代用して入手する事ができるわけであり、自分以外の関係者にノウハウを展開するのが容易になるはず、とも考える。

参考文献
[1]

「CentOS 系サーバー60 台と Web サイト 30 ヵ所にインストール済プログラムの一覧作成」長屋 貴量 (2018)[2]

日経 Linux(月刊) のいずれか であるが該当冊子が不明[3]

Ansible 構成管理入門 山本 小太郎 技術評論社 (2017)