大分更新をさぼってしまいました。アプリ開発にJenkinsを使い始めて1年以上立ちました。今やJenkinsはインフラと課しているので、メンテナンスが重要になってきました。
容量が足りない
Unityを扱うようなジョブの場合、ビルド毎に大量のバイナリファイルが生成されるので古いビルドやキャッシュを適切に不要になったタイミングで削除しないとすぐにストレージがフルになってビルドできなくなります。ジョブの数が増えるにつれてこの問題は深刻な問題となりました。
容量を食う主な要素は、
- ビルド成果物(実際にそれを後で使うもの)
- ビルドキャッシュ(ビルドが終わってしまったら、消しても困らないもの)
- ジョブ用にcloneされたレポジトリ
でした。
富豪的な対策(でかいストレージを買う、サーバー台数を増やす)には限界があるので、それ以外の対策を考えると
- ビルドキャッシュをためないようにする
- ワークスペースを共通化する
- Dropboxを活用する(gitになんでもかんでもpushしない)
があります。1, 2については割と当たり前な内容しかないので省略して、ポイントは3です。最近githubからもコミットに容量制限を付けるというような発表があったところですが、Dropbox等を活用してgitレポジトリのサイズを小さくすれば、複数のジョブからレポジトリを参照しているような場合に効果があります。
これらの対策に加えて、地味に定期的な再起動にも一定の効果があります。なにがリークしているのか原因はわからないですが、朝から晩までジョブをまわし続けているとメモリ使用量がどんどん増大していき、ページアウトした内容が数GB〜数十GBオーダーでストレージを圧迫していきます。これは再起動することによって解放されます。
停止できない
最早重要なインフラとなった現在、Jenkinsサーバーを止めることによる開発・リリースへの影響は小さいと言えません。ただし、メンテナンスのために起動・停止を行う場面は避けられないので、Jenkinsサーバーの起動停止も可能な限りスムーズにやりたいところです。
Jenkinsの中身は基本的にすべてwarファイルにおさまっているので、コマンドラインから普通にjavaコマンドを使ってサーバーの起動・停止ができますが、OSが再起動してしまった際の自動起動を考慮すると、基本的にはlaunchdを使うべきです。
homebrewが楽。しかし
Jenkinsは今時点でもかなり開発のペースが早いシステムです。バグがあったりセキュリティ面でのアップデートもあるので、なるべく最新版にアップデートしておきたいものです。
Jenkinsの実行ファイルは基本warファイルだけなので、毎回最新のwarファイルを上書きする形でアップデートをしていってもそんなに手間ではないのですが、上述のlaunchdの設定等も考えるとコマンド一発でインストール+設定を行ってくれるhomebrewを使ったインストールが楽です。パッケージの更新の追随も遅くないので、アップデートの手間を考えてもhomebrewでインストールするのは悪くないアイデアです。
問題は、アップデートの度にLaunchAgent用のplistが更新されてしまうことです。現実的に重い処理を走らせたり、外部からもアクセス可能な状態で運用をしなければいけない場合はhomebrewでインストールされるデフォルトの設定での運用は難しいので、plistの中身を調整する必要がある場合がほとんどだと思うのですが、これがアップデートの度に戻ってしまうので、アップデート前に内容をコピーしておく等注意が必要です。
