CI をボットの実行環境として使う

はじめに

この記事は whywaita advent calendar 2022 18日目*1の記事です。

adventar.org

こんにちは。nakanokurenai です。
ぼっち・ざ・ろっく!の放送も終わり、もうすっかり寒くなって冬眠したい時期ですが、タスクの大掃除で年末年始が消えそうです。 いったい誰がアドベントカレンダーをブログに転用しようとしたのか。

さて、今年は MMA に寄贈された ISUCON 本を携えて参加*2したり、羽田空港*3で出会ったり、#CookpadTechConf で出会ったりと whywaita さんとの接点が多い年でした。

そんな接点の一つである MMA のSlack に、春ごろ新しく作成されたチャンネルを通知するためのボット、newchan を実装し導入しました。
実行環境をどうするか悩んだ末、GitLab CI で動かすことにしました。この記事ではなぜそうしたのか、どうやっているのか書いてみます。

コードは GitHub に置いてあります。

github.com

なぜ CI なのか?

自由な実行環境で、無料で、データが保存でき、再現性があるため。

自由な実行環境

Slack には API がいくつかあり、それによって実行方法が変わります。

  • Webhook のような形になる Events API。使うなら HTTP での待ち受けが必要です。
  • Socket Mode。WebSocket 接続で Event を受けとる方法で、常時起動が必要です。
  • Web API。必要なときに RPC のように呼び出す方法

HTTP での待ち受けはローカルでの実行しにくさ、ひいては開発しにくさに繋がります。
また WebSocket では接続が切断されたらどうするのか、のような常時接続に起因する問題を考える必要が出てきます。
単にライフサイクルが短いほうが書きやすいものです。

新しいチャンネルが作成されたことはすぐに知ることができなくても遡ればいいだけですから、ある程度早く気付ければいいと考えられます。
よって Web API を使う CLI アプリとして書けると一番簡単だろうと考えました。

CLI が無料で実行でき定期実行もできるとなると、あまり選択肢はなさそうです。 Docker が使え、どんな環境でも用意できる CI が適任に見えてきます。

エラーレポート機能が備わっている

おおよその CI プラットフォームにはコマンド実行に失敗したときに Slack なりに通知する機能があります。 本来はテスト実行に失敗したことを通知するためにありますが、これを使えば Sentry などの外部サービスを使わずともエラーに気付くことができます。

実行ログも保存されますし、なにか導入せずとも終了ステータスを返すだけで通知が来るのは素晴らしいです。

実際のエラー例

データが保存できる

なかなか完全無料ではデータが保存できることは少ない… と感じています。

CI は git リポジトリと同時に動かすものなので、そのリポジトリに直接保存することで最低限データを保存できます。

鍵はデプロイキーとして登録すればリポジトリのみに影響範囲を絞ることができますし、コミットメッセージに [ci skip] のような文字列を入れれば大抵の CI はループは防ぐことができます。
ホストキーをしっかり書きこむことで -o StrictHostKeyChecking=no の bad practice を防ぐこともできます。

詳しくは .gitlab-ci.yml を見てください。

余談ですが、GitHub Actions であれば API 経由でリポジトリを操作することもできます。*4
Git のオブジェクトを直接操作することになるためとっつきにくいですが、鍵を作る必要がない点が素晴らしく、オススメです。

再現性のため

将来、サークルは卒業することになります。 しかし、便利な仕組みは残せるほうがよいはずです。

もし必要になったときに簡単に使え、できる限り再現性のある形で残ると嬉しいと考えると、外部サービスを使うと面倒です。 サーバーレスではいくつかのサービスを組み合わせないと定期実行できなかったり、そもそも従量課金であったりと使いにくさがあります。

かといってサークルで運用されている Linux サーバーは Infrastructure as Code が実践されているわけでもなく、適当に設置するだけではなにがどこで動いているかわからない状態になるだけです。

既にサークルで運用されていて、誰もがアカウントを持っている GitLab にソースコードと共に配置するとよいのではないかと考えました。

CI は設定ファイルで実行内容を記載できますし、それがソースコードと近い位置にあるのでわかりやすいはずです。
GitLab CI の惜しい点は、定期実行の設定は UI から行わなければいけないことです。GitHub Actions であればその定義もファイルで設定できるため、そちらのほうがよりよくはあります。

実際に運用してみて

4/17 から運用を始め、オンプレ GitLab CI が丸ごと使えなくなったことがあった以外には特に目立った問題もなく動作しています。

Git ホスティングサービスを使っていれば誰でも、組織でも使いやすく便利でオススメです。

*1:大遅刻

*2:学外の友人と brand new として初参加。本戦出場

*3:Music Unity 2022 https://mu2022.jp

*4:contents: write 権限を与える必要がある。https://stackoverflow.com/questions/72110199/what-is-contents-write-permission-in-github-workflow