はじめまして、フライウィール ソフトウェアエンジニアの米山です。
この度フライウィールでは初となる OSS johari-mirror を公開しました。本記事では johari-mirror の機能や実装に加え、開発から公開に至るまでの背景を紹介いたします。
johari-mirror の紹介
機能
johari-mirror は Kubernetes クラスター内のコンテナを監視し、再起動があった場合にそのコンテナのログや終了コードなどを収集して Slack に通知するツールです。コンテナの異常終了の原因調査に役立てることを目的としています。johari-mirror 自体も Kubernetes 上の pod として稼働させることを前提として開発されています。
以下が Slack 通知の例です。
特徴
- Rust 製
- コンテナのログをファイルとしてアップロードすることで、ログが長くても閲覧できる
- namespace や pod 及びコンテナ名によって通知先を割り振ることができる
- コンテナが連続で再起動した場合は通知の頻度を下げる
名前の由来
クラッシュしたコンテナの情報を通知することに因み、死者の生前の姿を映し出す浄玻璃鏡 (じょうはりのかがみ) から名前を取りました。
インストール方法
johari-mirror を Kubernetes cluster にデプロイする手順を簡単に解説します。詳細及び最新の手順は README をご参照ください。
Slack token の取得・登録
Quickstart | Slack の手順に従い、Slack app を作成し、ワークスペースにインストールします。
Slack Bot User OAuth Token を取得し、Kubernetes secret として登録します。
kubectl create secret generic johari-mirror-slack-api-token \
--from-literal=token=<your-slack-token>デプロイ
deployment/example.yaml を手元にコピーし、環境に合わせて以下の値を書き換えます。
- NAMESPACE: デプロイ先の Kubernetes namespace
- NOTIFICATION_CHANNEL: 通知先の Slack チャンネル名
kubectl apply することで、johari-mirror の pod が起動します。
kubectl apply -f example.yaml開発の背景
フライウィールのインフラ環境
フライウィールでは開発しているほとんどのアプリケーションを Kubernetes cluster 上のコンテナとして稼働させています。Kubernetes ではコンテナがクラッシュした場合に自動で再起動が可能とはいえ、クラッシュした原因を調査することで再発を防止し、サービスの品質を向上させることが望まれます。
johari-mirror 導入以前
johari-mirror の開発以前はコンテナ再起動のアラートは設定されていましたが、原因を調査するには毎回以下のようなステップを踏む必要がありました。
- アラートのメッセージから、再起動が起こった namespace と pod 名を確認する。
- kubectl describe pod や kubectl logs コマンドによってクラッシュ前の状況を調査する。
- クラッシュの原因をインフラ起因/アプリケーション起因などに分類し、適切なチームに修正を依頼する。
当然アプリケーションの種類が増えるにつれて原因調査のコストは増大し、全てのクラッシュについて調査することが難しくなっていました。
johari-mirror 導入後
johari-mirror の開発後は kubectl で一次調査していたような情報が通知から一目で分かるようになり、トラブルの原因調査が大幅にスムーズになりました。また、 Slack メッセージのリンクを引用して「このクラッシュについて調査してもらえますか？」と依頼するような例も見受けられました。このようにクラッシュ時の状況が1つのメッセージにまとまっていることにより、コミュニケーションが円滑になるという利点も生まれています。
公開までの経緯
johari-mirror が社内のクラスタで稼働し定着した頃、「Tech blog の記事として紹介してはどうか」という推薦を受けました。これを受けて、フライウィール固有のロジックなどは含まれていないので折角ならばソースコードも公開できないかと考え、OSS として公開することを提案しました。
記事タイトルの通りフライウィールとしては OSS の前例は無く、法務部門などに一通り確認を取る必要はありましたが、ポジティブなフィードバックを受け無事に承認されました。
公開準備
社内利用と OSS との間を埋めるため、公開前に以下の準備を行いました。
- ライセンスの選定
- 依存パッケージのライセンスを確認の上、 MIT License を選択
- README の整備
- ビルド成果物の公開
- Docker image を GitHub Container registry で公開することにした
- ビルド環境の整備
- 社内では Bazel を使ってビルドしていたが、 Cargo に移植
- GitHub Actions でテストと Docker image の build/push を実装
まとめ
本記事では、フライウィールで開発した OSS johari-mirror の機能及び開発・公開の過程を紹介しました。johari-mirror が Kubernetes ユーザーの助けとなり、またこの記事が OSS 公開を検討している企業の方の参考となれば幸いです。
