Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ

Hatena Engineer Seminar #4

Feb 7th, 2015

Profile

• id: Songmu (ソンムー)
• おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
• https://metacpan.org/author/SONGMU
• 趣味はCPANizeです
• はてな チーフエンジニア
• 東京オフィス
• はてなでGoとScala始めました

オープンソースにしているもの

https://github.com/mackerelio/

僕が入社してからやったこと/やろうとしていること

• テストをオープンにする
• ビルドをオープンにする
• リリースをオープンにする

mackerel-agent

• https://github.com/mackerelio/mackerel-agent
• Goで書かれたユーザーのサーバーにインストールされる常駐プログラム
• シングルバイナリが吐けるのでセットアップが簡単
• マルチプラットフォーム対応が比較的容易
  • OSX/Windowsでも動作可能(現状サポート外)
• 常駐プロセスを書くことに向いている
• フットプリントが小さく監視対象のサーバーのパフォーマンスに影響を及ぼさない

OSSにする理由

• 公開しない理由がない
• ユーザー環境で動くものだからソースを開示する

ユーザーがハックできる余地を残しておく

• エンジニア的には嬉しい
• ユーザーと一緒にサービスを作っていく
• 最近同様の事例が多い

Travis CIの場合

• コンテナのcookbookを公開していてp-rを受け付けている

github-servicesの場合

• サービス連携部分のコードが公開されている
• 自分がやってるサービスとgithubとの連携コードを自分で書ける

ソースをオープンにして第1段階クリア

• パッチ受け入れ体制
• ちゃんとリポジトリを回していく必要がある
  • p-r放置したりすると厳しい
• 逆にメンテナンスコストがかかっては本末転倒

何故githubにホストするか

• contributeしてもらう体制を作りやすい
  • メールでパッチのやりとりとかお互いにとって労力がかかる
• 一番スムースにパッチのやりとりができる
• レビューのやりやすさ

どのようにパッチ受付体制を整えるのか

• 放置してはいけない
• pull requestは公平に扱う
• レビュー体制
• CIが必要

CI

• テストがコケてたら「とりあえず直して」って言える
• CIがないとお互いパッチのクオリティーを担保できない
• パッチのアクセプト基準も曖昧になり不公平感も生まれる
• 客観的なクオリティを共有できるようにしておく
• オープンなCI環境を使う
• 外部サービスを使う

Travis CI

• 使い慣れている
• encryptの仕組みとかが便利
• gitでtagをトリガにしてジョブが実行可能
  • 他のCIサービスにまだない

mackerel-agentのCIでやってること

• go vet/golint (コードフォーマットの検査)
• go test
• coverageの計測
• cross build可能かどうか
• Travisの他に社内Jenkinsも用意
  • Travisのコンテナでは取得できないメトリックがあるため

golintをCIする

• golintは指摘項目があっても終了ステータスが0なのでエラー扱いにならない
  • golintはコーディング規約的な推奨事項なのでエラー扱いじゃないのは妥当

ただ、些細なコーディングスタイルの違いで議論したくないのでgolintで警告が出たらCIがコケるようにしたい

#!/bin/sh
rm -f .golint.txt
for os in "linux" "darwin" "freebsd" "windows"; do
    GOOS=$os golint ./... | tee -a .golint.txt
done
test ! -s .golint.txt

Coveralls

• goverallsを使ってcoverallsにカバレッジを投稿
• 参考 -> http://www.songmu.jp/riji/entry/2015-01-15-goveralls-multi-package.html

Windows対応

• AppVeyorでCI/CD
• テスト & インストーラー作成
• 検証環境に限りがあるのでCIを充実させたい気持ち

レビュー体制

• agentは社内の人間の誰かがレビューしている
• 開発チームのp-rも他の誰かがレビュー
• 業務時間内の社内リソースをどう割り当てるか
• 「気がついた時にやる」に今はなっている
• あまり仕組み化できていない

mackerel-agent-plugins

• AWS EC2 CPU Credit
• AWS ELBSSSS RDS
• Apache2
• Elasticsearch
• HAProxy
• JVM
• Linux procs
• memcached
• MongoDB
• MySQL
• Nginx
• PHP-APC
• Plack
• PostgreSQL
• Redis
• SNMP
• Squid
• Varnish

多くのplugin

• 社外のユーザーさんが機能追加してくださっている
• リリースフローはagentよりも進んでいる部分がありagent側にバックポートしたい
  • リリースプロセスをオープンに
  • パッケージのTravis上でのビルド

リリースプロセスをオープンに

• make releaseコマンドでリリースpull requestを自動作成
  • versionのbump up
  • changelogを自動生成
• レビュー後マージボタンでマージ

パッケージの自動ビルド

• releaseマージコミットに対してtravisが自動でtagを打つ
• tagを打たれたcommitに対してTravisがビルド成果をrelease

仕組み

Perlでツール作成(標準モジュール縛り)

• tool/releng
  • 手元で打つ。リースp-rを作成してくれる
• tool/autotag
  • Travisから叩く。マージコミットにタグを打ってくれる

ツールをテストする

• perl tool/releng でスクリプトが動いて prove tool/relengするとテストが走るおもしろ機構
• 一枚のPerlスクリプトの中にテストも書かれてる
• ドキュメントとテストコードつきのPerlスクリプトを書く方法
• $ENV{HARNESS_ACTIVE}を見て分岐
• ちゃんとテストを書けるのは安心

• シェルスクリプトが複雑化すると大変

    if (!$ENV{HARNESS_ACTIVE}) {
        main();
    } else {
        # When called via `prove`, tests will run.
        run_tests();
    }
  

tool/releng

• 次のバージョンの決定
• ファイルを置換しまくり
• ブランチ作成
• Changelog自動生成
• push
• p-r作成
• https://github.com/mackerelio/mackerel-agent-plugins/pull/45

tool/autotag

• マージコミットかどうか判断
• マージコミットの場合マージ元のブランチ名を取得
• ブランチ名をもとにバージョンを指定
  • e.g. ブランチ名がbump-version-0.5.0 -> v0.0.5

Travisにtagをgit pushさせる

• travis encrypt-fileで暗号化したdeploy keyをリポジトリにコミット
• Tavis上で溶かす
• .ssh に無理やり配置
• git remote set-url origin git@github.com:mackerelio/mackerel-agent-plugins.gitでリモート書き換え
• push!
  • 永久機関作成に注意
• https://github.com/mackerelio/mackerel-agent-plugins/blob/master/.travis.yml#L13-L21
• github tokenを使う手もあるが、github tokenは細かい権限設定が難しい

課題

• 社内で検証できないミドルウェアの動作確認をどうするか
• リリースサイクル
• どこまでをコアに同梱するか
• コアのpluginとoptionalなプラグインの分離

まとめ

• ソースをオープンにすることでユーザーと一緒にサービスを作る
• Travisなど外部サービス利用する
  • テスト環境をオープンに
  • リリースサイクルをオープンに
• 自動化するツールもテストできるようにしておく