初めて自作OSSツールを業務コードに入れた話

メリークリスマス(素振り)。 入社と同じタイミングで始まったラジオの放送回数で入社からの週数を把握しています、入社114週のSRE所属の今*1です。
最近の趣味はパネルでポンです。

この記事はKAYAC Tech Advent Calendar 2021 8日目の記事です

OSSへの憧れ

もともと学生時代からLinuxが好きで、ユーザーたちで一つのモノを作るOSSという文化に憧れを持っていました。
OSや低レイヤーへの好奇心はあったものの難しかったので(意識が低い)、趣味でLinuxを触っている知識が活かせそうなサーバー、インフラ辺りのレイヤーのお仕事としてカヤックのSREとして*2雇っていただけました。

そしてカヤックには、我らが藤原組長を始めとする先輩社員の皆様のOSSツール(隙間家具など)が至る所で利用されていました。
社内でも話す機会もあまり無いので言っていないのですが、ぼくの中のOSS像の変化と感動は静かにじわじわと身に染みていました。OSSといえばLinuxや、そこまで巨大ではなくともmpdやxmonadなど(趣味がバレる)ある程度成熟した、ユーザー数も多いもののイメージがどうしても強かったのですが、藤原組長の隙間家具OSSはどれも単機能で小さく、言ってしまえばユーザーも自分たち(社内)がメインターゲットだったようなものばかりでした。
しかし、藤原組長のカンファレンスへの登壇やその反応を見ると、同じ悩みを持っていたユーザーがたしかにツールに興味を持ち、実際に利用している様子を見ました。ぼくが入社する前から利用されていたツールの機能追加・仕様の追従や、課題が生まれてから解決に必要な新たなツールが作られるまでの様子を見たりもしました。

「あぁ、今ではこんなに馴染んだツールもこんな感じで生まれてくるのか…」と思いました。

ぼくもつくる

さて、弊社では社内でのやりとりに主にSlackを利用しています。ぼくはSlackが大好きです。

SlackにはAPIが充実していますが、仕様の移り変わりもありました。
かつてSlackへの投稿といえばincoming webhookが主流でした。エンドポイントを一つ発行すればcurlでjsonを投げるだけで好きなチャンネルに好きなアイコンとユーザー名で投稿することができました。 しかしSlack Appへの移行により、発行するwebhookは1本につき投稿先チャンネルは固定、icon/usernameは変更不可能になり、厳密で管理が行き届くように、そして自由度は下がりました。

現在の主なSlackへの投稿方法はOAuth Tokenを利用するものです。 Slack Appへpermissionを設定し、厳密にアクセスできる機能を管理できます。

Access tokens | Slack

chat:write.customizeを付与することにより、icon/usernameも指定して投稿できるようになります。 しかし、incoming webhookと違ってOAuth Tokenでの認証を通す必要があり、旧来のようにcurlでおてがる投稿ができなくなりました。 普段業務や趣味ではGolangを使うことが多いため、slack-goを利用することでicon/username指定のSlack投稿は軽率にできるのですが、それ以外の場合につらくなります。
特にshellから軽率にslackに投稿したい機会が多くあるのですが、軽率に扱えず結構つらくなります。

Slackのbotはアイコンやユーザー名を自由に設定できて雑になんでも作れるのが楽しいのに……。

そこでSlack App OAuth Tokenでicon/username指定付きで軽率にSlackに投稿できるCLIツール、slack-quickpostをつくりました。

github.com

お遊びで作ったツールでしたが、自分が困っていた場所を埋めるためのツールなので当然業務上で困っていた場所にも入れたくなりました。なので入れました、というお話が本エントリです。前置きが長くなりました。

ちっちゃいツールとはいえ、初めて個人で作ったものを業務で扱うものに入れるのはなかなか緊張しました。相談して返ってくるのは「いれちゃダメそう」か「まぁ入れても良いんじゃない?」というふわふわした答えなので、最終的に組み込む判断は自分でエイヤとやるしかないので。

そうして入ったslack-quickpostは定期実行バッチのステータス通知、デプロイ環境で誰が作業しているかを把握/記録する通知に軽率に利用されています。

デプロイ環境デプロイユーザーの .bash_profile

export SLACK_TOKEN=`xorb-XXXXX`
case $(hostname) in
    *develop*)
        # devチャンネル
        export SLACK_CHANNEL=YYYYYYY
        ;;
    *)
        # operationチャンネル
        export SLACK_CHANNEL=ZZZZZZZ
        ;;
esac
slack-quickpost \
        --channel ${SLACK_CHANNEL} \
        --username ログイン通知 \
        --text "login $(logname) in $(hostname)" \
        --icon ":relieved:"

のような感じで書いておけば、ログイン時にslackにログが記録されます。リモートでもなんとなーく誰がproduction環境を変更できる権限を扱い始めたかを把握できるため便利です。権限に応じたチャンネルに投稿されるようにすると、作業時に「それもしかして建てる環境間違えてない?」というミスに気づける点もお気に入りです。

f:id:tkonsoy:20211207132215p:plain
ログイン通知

これは余談ですが、slackの表示は同一ユーザーが連続で書き込んだ場合にはユーザー名とアイコンが省略されます。botも同様で、連続で通知を送ると見づらくなることが多々あります。 icon/usernameを変えると、同一bot(Slack App)からの投稿が連続しても表示が省略されない、という仕様があるので、見分けがつきやすくなって便利です。
あくまで表示上のbot名なので、Slack内検索のユーザー名としては使えないので、もし後から検索したいような内容であれば本文に検索できる文字列を設定することをおすすめします。

業務利用コードに入って感じたこと、安定の大事さ

当然ながら、業務利用しているツールが突然動かなくなったり挙動が変わったりすると大変です。時々外部のツールを利用していると朝突然動かなくなった、テストが通らなくなった、なんてことがありますが、自分で作って導入したツールでそんなことが起きたらチームメンバーの進捗とぼくの心に絶大なダメージを喰らいます。

そうならないように、世の中のツールは安定したものを配布する仕組みがたくさんあります。gitのバージョンを切ってリリースにして静的バイナリを置く、ビルド済みのdocker imageを配布するなど、使う側としては当然のように扱っていた仕組みを自分が壊さないように意識するのも初めてでした。
我が家にはかれこれ6年ほどRaspberryPiが住んでいて生活必需品になっているのですが、中のコードは自分しか使わないので平気で破壊的な変更デプロイはするし、ある朝動かなくなっていて目覚ましが鳴らず寝坊した、なんてこともあるほど雑運用に慣れ切っていたのです。

slack-quickpostは静的バイナリを配布しています。業務利用しているのも静的バイナリを引っ張ってきています。小さな小さなツールですが、緊張を感じられたのは良い経験だったな、と思った2021年の出来事でした。

以上、SREの今でした。

*1:今は名字なのですが、前回ブログで「以上、カヤックの今でした」という表記はカヤックSREチームの現状を伝えるレポーターみたいだと社内FBを頂きました。名字です。

*2:厳密にはSREという役職はインフラとは違いますが、触るレイヤーが近いというニュアンスで。