持続可能な大学研究室計算機環境を構成した
うちの研究室にあるサーバや個々のマシンは，教官と院生によって連綿とメンテされてきました。しかし，ドキュメントがほとんどないため去年は引き継ぎが大変でした。そこで，コマンドを 2,3 回叩くだけでほぼすべてのメンテができ，最低限のドキュメントでも引き継ぎが可能な環境を構成しました。今後，GitLab CI/CD を追加しようと思っています。
研究室の計算資源環境
うちは天体物理の研究室で，デスクトップ PC を流用した数台のサーバと，個々の学生が日常的に使うためのデスクトップ PC が 20 台弱ほどあります。ネットワークを構成しているマシンは，これらのなかでサーバと卒研生のマシンで，合わせて 10 台前後と規模としてはそれほど大きくありません。しかし，ドキュメントやスクリプトが十分に用意してあるとはいいがたいものでした。実際，去年にやった引き継ぎではかなりいろいろな苦労をしました。
そこで，最終的に Ansible, Prometheus, Docker, Slack を用いた環境を単一の GitLab.com プライベートリポジトリに構成しました。ちなみに OS は主に Ubuntu です。
Ansible
当初の状態ではいちいち人間が 1 台 1 台の面倒を見なければならず，流石にそれはつらかろうということで，まず Ansible で卒研生用のマシンを管理することにしました。ちょうど春に OS を Debian から Ubuntu に入れ替えようという話になったため，OS のインストールと SSH，あと Ansible を使うのに必要なちょっとした設定以外はすべて Ansible でやってみました。
卒研生用のマシンでは既に NIS と NFS が運用されていたため，まずこれらの設定を自動化しました。また NFS と mozc は lockfile まわりで相性が悪いので，それの対応も行いました。他にもたくさんのこまごまとした設定を Ansible Playbook で一括してできるようになりました。
サーバの設定も，すべてではありませんが Ansible での構成を進めています。Ansible は冪等性が大抵の場合あるので，1 回まともな Playbook を書けば誰がどう実行しようとも安心できるのが良いです。
Ansible は，これだけでほぼ完結するくらい便利だと思います。基本的な設定だけでなく，何か追加でやりたくなったときにコマンド一発で情報をとってきたり，何か追加したりできるのはとても楽です。
Prometheus
各マシンの設定が手軽にできるようになったので，次は監視を整えました。最初は Zabbix を試してみましたが，UI が好みではなかったので Prometheus に乗り換えました。Prometheus 自体はメトリクスの収集とアラート発火だけをやってくれるので，可視化に Grafana を，アラート管理と発出に Alertmanager を，実際に人間がアラートを受け取るのには Slack を用いています。
Prometheus, Grafana, Alertmanager はどれも Docker で動かしています。設定ファイルはバインドマウントし，各アプリケーションのデータ永続化は Docker Volume でやっています。Prometheus と Alertmanager の通信は Docker network 内で行われています。これらの設定を docker-compose ファイルに書いておき，運用者が実際にやるのは docker-compose up -d のみです。
Prometheus, Grafana, Alertmanager の組み合わせを使う利点は，設定ファイルを YAML 等で書いておくことで，いつでも設定が再現された環境が実行されるという点だと思います。GUI で設定する必要がないです。（Zabbix もテキストベースで設定する方法がないわけではないです。）
GitLab.com
以上の構成をはじめは GitHub のいくつかのリポジトリで管理していましたが，最終的に 1 つの GitLab.com リポジトリに集約しました。 GitLab.com は GitLab 普及を目的としたサービスで，GitLab の基本機能がすべて無料・無制限です。なかでもプライベートグループとプライベートリポジトリが無料・無制限というのが大学の研究室にとって非常にありがたい点です。（ちなみに GitHub も学生ならプライベートリポジトリを無制限につくれますが，引き継ぐことを考えるとオーガニゼーションまで必要です。）
現在の運用では，管制塔となるサーバに人間が入って deploy key を用いていちいち git pull しています。またコードのテストをまったくしていません。GitLab では CI/CD が組み込まれているため，今後は GitLab CI/CD を用いてテストからデプロイ/デリバリーまで自動化したいと考えています。
HEASoft を Ubuntu 16.04 にインストール
HEASARC の HEASoft を Ubuntu 16.04 にインストールしました。
HEASARCのインストールアウトラインと、 Debian 系インストールマニュアルを参考にしました。 前者のほうが詳細なので基本的にそれを読めばあまり滞りなく進みます。
前提として、操作はすべて bash でおこなっています。
ソースをダウンロード
まずはソースをダウンロードします。 お誂えのバイナリをインストールしてもよいのですが、 最新のソースを自分でビルドするほうが心配が少ないと思います。
STEP 1 - Select the type of software:
SOURCE CODE DISTRIBUTION (Recommended):
のところで Source Code のラジオボタンにチェックを入れると、
様々なアーキテクチャのリストが表示されます。
その中から自分の使いたいプラットフォームのものを選ぶことができます。
これはソースをダウンロードする上では不要な操作ですが、
HEASARC 側がユーザ統計をとるために用意しているものです。
全部入りソースをダウンロードするだけならページ上部にある
Complete HEASoft source code (all mission & general-use software)
というリンクを wget するなどしてダウンロードできます。
圧縮されたソースは2GB程度あるので、回線にもよりますがダウンロードには数時間かかります。 今回は２時間かかりました。
必要なパッケージをインストール
ソースをダウンロードしているあいだに、必要なパッケージをインストールしておきます。 Debian 系マニュアルにあるとおり、以下のコマンドでインストールすることができます。
$ sudo apt-get -y install libreadline6-dev $ sudo apt-get -y install libncurses5-dev $ sudo apt-get -y install xorg-dev $ sudo apt-get -y install gcc g++ gfortran $ sudo apt-get -y install perl-modules $ sudo apt-get -y install python-dev
Ubuntu 16.04 の場合、これらのうちのいくつかはすでにインストールされています。
ソースを解凍する
ソースのダウンロードが終わったら、それを解凍します。
$ gunzip -c heasoft6.21src.tar.gz | tar xf -
全部入りソースの圧縮ファイルをダウンロードした場合は上のようなファイル名です。 解凍には１分程度かかります。
ビルドの設定をする
解凍してできたディレクトリに入ります。
$ cd heasoft-6.21/BUILD_DIR/
いまから configure するのですが、Debian 系のマニュアルを読むと setenv,export コマンドでコンパイラのパスを丁寧に環境変数に設定しています。
この操作は必ずしも必要ではないですが、コンパイラが正常に参照されていないエラーが出た場合や、
独自にコンパイラを指定したい場合に行います。
bash では以下のコマンドで行います。
パスは環境によりますが、マニュアルにある以下のパスはすべて which したときのパスと一致していました。
$ export CC=/usr/bin/gcc $ export CXX=/usr/bin/g++ $ export FC=/usr/bin/gfortran $ export PERL=/usr/bin/perl $ export PYTHON=/usr/bin/python
では設定をします。何もオプションをつけずに実行すると、heasoft は先ほど展開した heasoft-6.21 にインストールされます。インストール先は --prefix=インストールしたいディレクトリの絶対パス で指定できます。
今回は /opt/heasarc/heasoft にインストールすることにしました。ツールは
/usr/local/heasoft などにインストールするのもありだと思いますが、
FHSに準拠するならば /usr/local内にパッケージやベンダーごとのディレクトリをつくるべきではないそうです。
$ ./configure --prefix=/opt/heasarc/heasoft > config.out 2>&1 &
これは、 configure が標準出力するログをエラー含めて config.out に書き込んでいます。
末尾に&がついているので、処理はバックグラウンドで走ります。
何が起きているか見たい場合は、以下のコマンドで config.out の末尾行を監視できます。
$ tail -f config.out
tail コマンドは Ctrl+c で終了します。
configure が終わったあとに何かしらのコマンドを実行すると、直後に
[1] 終了 configure
のように表示されます。 設定が無事に終わったでしょうか？ config.log の最終行が
configure: exit 0
であれば正常に終了したことを意味しています。 0以外で終了した場合は、 多分エラーがあります。 config.log を読みといて、調べてもわからなければヘルプに連絡することになると思います。
ビルドする
ビルドします。
$ make > build.log 2>&1 &
これも先ほどと同様に make の標準出力をログに残しつつバックグラウンドでコンパイルしています。
tailでログを監視するのも同様にできます。
終わったら、エラーがないかチェックしましょう。
$ grep -G -e "\*\*\*" build.log | less
これは、ログ内で***を含む行をlessに渡しています。
less以外にもmoreなど色々と読む手段はあるので好きな方法でやってください。
インストールマニュアルによれば、
char *** ...__PRETTY_FUNCTION__," ***...
という内容に言及したエラーは無視していいそうです。
インストールする
ビルドしたものを設置します。
今回は /opt/heasarc/heasoft にインストールすることにしたので、
権限的に sudo が必要でした。
$ sudo make install > install.log 2>&1 &
終わったら先ほど同様の方法でエラーを確認しましょう。 無事インストールできたら、インストール先は以下のようなディレクトリ構造になっています。
$ tree -L 1 /opt/heasarc/heasoft/ /opt/heasarc/heasoft/ ├── Xspec ├── attitude ├── demo ├── ftools ├── heacore ├── heagen ├── heasim ├── heatools ├── hitomi ├── image ├── integral ├── nustar ├── spectral ├── suzaku ├── swift ├── tcltk └── x86_64-unknown-linux-gnu-libc2.23 $ tree -L 1 /opt/heasarc/heasoft/x86_64-unknown-linux-gnu-libc2.23/ /opt/heasarc/heasoft/x86_64-unknown-linux-gnu-libc2.23/ ├── BUILD_DIR ├── bin ├── fguipfiles ├── headas-init.csh -> BUILD_DIR/headas-init.csh ├── headas-init.sh -> BUILD_DIR/headas-init.sh ├── help ├── include ├── lib ├── man ├── refdata ├── share ├── syspfiles └── xrdefaults
初期化
膨大なパスを通してくれるシェルスクリプトを実行します。以下の内容を ~/.bashrc に記述します。
HEADAS=/opt/heasarc/heasoft/x86_64-unknown-linux-gnu-libc2.23 export HEADAS alias heainit=". $HEADAS/headas-init.sh" heainit
１行目でHEADASという変数にスクリプトがある場所を代入して、
２行目でそれを環境変数にし、
3行目では . コマンドによって初期化スクリプトが設定する環境変数をカレントシェルでも使えるようにする、
という処理をエイリアス heainit に設定しています。
これにより、ログオンしたら heainit を実行すると適切なパスが設定されるようになっています。
しかしターミナルを起動するたびに必ずコマンドを打つのは不合理なので、
heainit を実行してくれるよう４行目に書いています。
Done
以上でHEASoftのインストールは終わりです。
Gentoo のインストールで気をつけたいこと
研究室のPCに Gentoo をインストールしてみました。 カーネルのビルド設定などでちょっと右往左往したので、最低限気をつけたいポイントについて。
USB
最近のマザーボードはUSB端子はあってもPS/2コネクタはないことが多いです。USB 3.0、2.0両方のサポートをオンにしておいたほうがいいでしょう。僕はここで失敗してキーボードが反応しませんでした。ハンドブックの記述は若干古いので、wikiのカーネルコンフィグレーションガイドをよく読んで下さい。
Ethernet
ネットワークアダプタはベンダー固有のサポート項目をオンにする必要があります。ネットワーク関係はハンドブックでは1行しか触れられていないので見過ごしやすいかもしれません。 lspci で最後のほうにネットワークアダプタのメーカーと名前が表示されるので、そのベンダーをデバイスドライバのイーサネットサポートのリストから探してください。僕はこれを見落としてネットにつながりませんでした。
またフォーラムで見かけた情報で定かではないのですが、gigabit ethernet コントローラのように高速なネットワークアダプタはPHYまわりのサポートが必要だとか。
メディアを抜くタイミング
これはビルド設定とはまったく関係ないのですが、Ubuntu などの親切なディストロをインストールしたときのことを思い出すと、インストールメディアを抜くのは reboot コマンドによってマシンが再起動し始めてから、BIOS/UEFI によってブートが始まるまでのあいだです。 reboot コマンドの前にメディアを抜いてしまって、コマンドが効かなくなり裏技によって再起動したのはなかなかおもしろい経験でした。
Now dismiss
ちなみに Gentoo のインストールそのものは、LiveUSB を使って最小構成なら1時間かからずできるようになりました。 desktop プロファイルなどを選択した場合は、@world の更新だけでも1時間ほどかかるのでそれほど短時間では終わらないです。
USB と ethernet の設定さえ正しければ、キーボードが動いてネットにつながるということです。たとえカーネル設定がひどいものだったとしても、この2つさえ動いていれば、あとはカーネルの設定を変更してまたビルドすればいいだけです。
僕はきれいなデスクトップが欲しくて結局 Ubuntu (まだ Unity) をインストールし直しましたが。
