つくったので、一人反省会します。かなり長いです。

リポジトリ


gitbucket-monitoring-plugin です。

なんでつくったん?


私が使用しているVPSのリソース状況を監視したかったのがきっかけです。貧弱VPSなので、監視用のソフトを導入するわけにもいかず…。VPSには既にGitBucketを導入しており、以前からScalaを勉強したいという思いもあったので、Scalaの勉強がてらにGitBucketのプラグインで実現できないかな…と。

何ができるの?


管理者向けのプラグインです。GitBucketを動かしているマシンの下記の情報を表示します。

  • OSの情報(バージョン、ディストリビューション、アーキテクチャ)
  • 環境変数
  • Dockerで動かしてるかどうか
  • 起動時間、起動後の経過時間
  • CPUコア数、CPU使用率、メモリ関連の情報、カレントパーティションの容量・使用量
  • ロードアベレージ
  • プロセス情報(Running, Sleepling, Stopped, Zombie)
  • Javaプロパティ一覧、JVMメモリ情報

また、LogBackの設定が有効の場合はLogBackの設定情報とGitBucketのログを表示できます。
スクリーンショットなどの詳しい情報はリポジトリみて下さい。

対応OS


基本、Linuxベースで作ってます。各プラットフォームに応じたコマンドをブッ叩いて結果をパースして表示しているだけです。

Linux

Debian8Ubuntu16.04で動作するのは確認しています。(UbuntuがDebian派生とかいうツッコミはなしで…)どのディストリビューションでも動作すると思われるコマンドを使用していますが、ディストリビューションやカーネルのバージョンによっては一部取得できない項目がある or 表示がおかしくなる項目があるかもしれません。

Windows

Windows10で動作するのは確認してます。ただし、一部取得できない項目があります。PowerShellが入ってればほとんどの情報は取得できるはずです。今時PowerShell入ってないとかはないと思うので…。

Mac

基本的に動くはずです。ただtopコマンドを使用している項目(CPU使用率やロードアベレージ)は取得できないと思います。どうも調べた限りではMacのtopコマンドはLinuxと表示結果が違うようなので…。Macは持ってないのでテストできてないですが、たぶんほとんどの情報は取得できると思います…。たぶん…。だってMac持ってないんだもん…。

作るにあたって苦労した点とか


以下、作る過程で苦労したところとか書いてみます。ただの一人反省会です。

設計

私の設計能力(どころかプログラミング能力全般的に)はかなりウンポコなので、どう設計していいかかなり迷いました。始めは機能(マシンの情報、リソース取得…など)ごとにクラスを作成して、その中でプラットフォーム(Linux、Mac、Windows)ごとに分岐させて、コントローラで機能ごとにインスタンス生成するということをやっていました。しかし、これはおかしいのではないかと思い、プラットフォームごとにクラスを分けた上で、各機能は全てtraitで作成してそいつをプラットフォームのクラスにmixinすることにしました。ただ、ホントにそれでよかったのかどうかいまだにわかりません。

コマンド叩きまくり問題

このプラグインは基本的にsys.processを使用してひたすらプラットフォームごとのコマンドをブッ叩いて、結果をパースして表示しているだけなのですが、コレ、ちゃんと探せばライブラリがあったりするのではないかと思いました。ライブラリがあれば、わざわざプラットフォームごとにゴチャゴチャとコマンドをブッ叩かずに済んだのではないかという気もします…。コード書き始めた以上は引くに引けなくなって、結果的に全部sys.processでコマンドをブッ叩きまくるという結果になってしまいました…。

Windows対応問題

数あるGitサーバの中でもWindowsに対応しているのはGitBucketだけだと思います。 GogsやGiteaもWindowsで動作するというご指摘を頂きました。ありがとうございます。適当なこと書いて申し訳ありません…。

私も前職の時にはLinux全くさわったことがなかったのでWindowsで動くGitサーバという理由でGitBucketを選択しました。ですので、Windowsのユーザは多いのではないかと思い、Windowsでも動作するようにしたいという想いがありました…。しかし、Linuxではあっさり取得できる情報も、Windowsでは簡単にはいかない…。非常に困りました。特にcmdだけで取得するとかムリ臭いんですよ(主にパースの問題)。結果、sys.processを使用してcmd経由でPowerShellをブッ叩くという方法で対応しましたが、PowerShellでリソース情報を取得するという情報がそんなにないですし、そもそもPowerShell使ったことないし…。で、PowerShellの使い方やコマンドを調べるのにかなり時間を使いました。ぶっちゃけ、私が使用しているVPSのOSはUbuntuですし、Windows上で動かすメリットどころか必要性すらなかったので、対応させるのにはかなりの労力とストレスがありマクリスティでした。テストめんどくせぇし…。途中でWindows対応は放り投げようかと思いました。でもやっぱりWindowsユーザは多そうだし、頑張ったよ。頑張ってWindowsでも取得できるだけの情報は表示するようにしました。ただ、一部の情報の取得に非常に時間が掛かったり、取得できない情報があったりします…。これ以上はムリ。

JavaなのかJVMなのか…

JavaのプロパティやJVMのメモリ情報を表示するようにしているのですが、なにせJavaほぼやったことないマンなので、Javaと表すべきなのかJVMと表すべきなのか迷いました。当初JVMという表記にしていましたが、Windowsでの検証のためにTomcatをインストールして、Tomcatのコンソールを確認するとJavaというタブで統一されていたのでJavaで統一しました。Javaに統一したものの、これちょっと違うんじゃないかな…?感があります。たぶん、JavaプロパティとJVMメモリという区別のような気がしてなりません…。まぁ、大正義Tomcatがそうなってたしな…。

こんな情報まで表示していいのか…

当初はマシンのリソース(CPUとかメモリ情報とか)を表示するだけのつもりだったのですが、結果的に環境変数とかも表示するようにしました。ただ、こういった情報を表示させてよいのかどうか非常に迷いました。迷ったのですが、JenkinsとかSonarQubeでも管理者だとそういった情報も見ることができるので、別にええかなという判断で表示することにしました。

Either使いすぎ問題

Eitherメッチャ便利やん!と思ってEitherを使い始めた…のはいいんですが、結果的に「モデル->コントローラ->ビュー」とEitherで投げまくることになり、結果的にこれで良かったのかどうかが解りません…。ただ、ちゃんと取得できなかった場合にメッセージ投げるには便利だし…うう~ん…。という感じです…。

例外処理

fatalNonfatalを区別しておらず、全てキャッチして前述のEitherを使用して放り投げまくってます…。せめてログに出力するようにしないといけないなぁ…。と思いながらもやってません…。ちゃんとやらねば…。

永遠のリファクタリング

と、上記のようなことをやっていると、延々とリファクタリングが続いてしまいまして、永久にリリースできそうになかったので、見切りをつけてサッサとリリースすることにしました。いや、なんかいろいろおかしい超絶ウ〇コードのは解ってるんですが、今の実力だと永久に解決できそうになく、精神を消耗してしまいそうなのでリリースして一旦落ち着くことにしました。なおすのはもっと経験積んでからでええやん。…的な。だって、永久にリリースできなさそうだったし…。

ホットデプロイ

正式に実装されていないのですが、GitBucketにはホットデプロイという機能を実装する予定があるようです。通常、プラグインのインストールにはGitBucketを再起動しないといけませんが、ホットデプロイを使用すると再起動しなくても管理者メニューからプラグインのインストール・アンインストールが可能になります。このことをTwitterで教えて頂きました。これにより、プラグインの検証がかなり速く行えるようになりました。

ただ、このホットデプロイを実装しているブランチではプラグインのURLのフィルタ条件が変更されています。初めは通常のリリース版を使用して開発していたのですが、ホットデプロイを利用するようにした直後にプラグインが表示されずに、フィルタに変更が加わっていることに気付くのに少し時間が掛かりました。なお、現時点でホットデプロイを実装したバイナリは配布されていないのでコードをクローンして自分でビルドする必要があります。

どのバージョンまで対応させるのか…

非常に迷いました。GitBucketは月に一回リリースされますし、チンタラやってたら互換性がなくなってしまうのではないか…。竹添さんのブログを見て4.10で大きく変更が加わっていそうだったので、それ以降のみ対応する方針にしました。いや、頑張れば4.9以前も対応できそうだったのですが、環境の準備とかテストがめんどくさいですしね…。いちおう、現時点で4.10~4.13までで正常に動作するのは確認してます。

プラグイン登録依頼


もともと作り始めた時点からGitBucket Community Pluginsへの登録依頼を行おうと思っていました。…のですが、いざ出来上がったコードを見たら…。う~ん、この超絶ウ〇コードのプラグインを登録依頼に出してよいのか…?かなり迷ったのですが、せっかく作ったものなので登録依頼だしました。

リポジトリのオーナーのMcFoggyさんが忙しそうというのはGitBucketのリポジトリのやり取りを見て解っていたので登録に時間が掛かるだろうな、というのは予想していたのですが…

  • なんせコードが超絶ウ〇コなので、その面で登録して頂けないかもしれない…
  • マズイ機能が実装されていると判断されて登録して頂けないかもしれない…
  • 登録して頂けないなら…直接状況をお伺いしたほうがいいかな…。でも急かすようで、それは失礼だし…
  • 向こうも無下に断れないのかもしれない…こちらから取り下げした方がいいかな…

そういった点でずっとハラハラしていました。無事登録して頂けてよかったです。感謝しかないです。特にaadrianさんには登録をして頂いた上に、私のウ〇コな概要説明の英語をいい感じに要約して頂いてありがとうございます。ホントに感謝しかないです。

所感とか


もう長くなってきたので箇条書きで書きます。

  • 使った範囲の言語仕様は解った
    • 逆に使ってないところはわからない
  • プラグインとはいえ、C#以外で初めて一から作ったので多少の自信はついた
  • サンプルコード(プロダクト)を探すのに苦労した
    • 結局、GitBucket本体のコードばっかり見ていた
  • 他の人のソースコード読むのは勉強になった(Scalaに限った話ではないですが)
  • 作りながら覚える方がモチベーション的には良かった
    • ただし、作りながらだとどっかで詰まる
  • 思ったほど情報(日本語)がなく、他の言語に比べて調べるのに時間が掛かった
    • どこかでガッツリと書籍読まないと今後ムリな気がする
  • Linuxのリソース・パフォーマンス周りのコマンドは大体わかった
  • PowerShellの使い方もなんとなくわかった
  • 自分の英語能力がウ〇チ過ぎてヤバい(読むのも書くのも)

次やりたいこと


GitBucket向けのプラグインで「こういうのを作ってみたい」というのはまだあるのですが、自分でサーバサイドからフロントエンドまでやってみたいという思いがあるので、しばらくはそちらの方をのんびりやろうと思います。もちろんScalaで。