ども、@kimihom です。
この記事は、Heroku Advent Calendar 2021 の 18日目の記事です。ぜひ他の記事も読んでみていただければと思う。
今回は、つい最近 Heroku CI や Pipeline を導入したこと、そしてセキュリティ事情 について記す。
導入前の開発環境
今まで開発効率のテクニックが流行ってるのを聞き流し、目の前の個人開発に没頭してきた。一人でひたすら develop ブランチへプッシュ。STG へは手動デプロイ。最後リリースする時に master(main) へプルリクエストを出して、そのフェーズでの全体コードを一通り確認したら、 master へマージ。この開発体制ならなら以下の開発環境で十分だった。
- テストはローカル環境で実行
git push origin develop で Bitbucket へプッシュ- STG 環境へも 手動で
git push staging develop:master
- プルリクエストからのマージ
- 本番へも
git push production master
当時、プライベートなGit環境は有料だった GitHub を導入する必要性を感じず、Trello のついでに 無料で使える Bitbucket のプライベートリポジトリを長い間使い続けてきた。Bitbucket と Heroku の 2つの場所にそれぞれ push する手間はあったけど、その程度だったので問題だと感じていなかった。むしろ、それの方が安心して開発ができた。
きっかけは開発のチーム化
いよいよ開発環境の改善が必要になってきたのは、1人開発から開発チームとして数人のメンバーが加わったことにある。常に私がコマンドを叩かないと Heroku にデプロイできない状態だと、開発効率が下がることになってしまう。
ちょうど、GitHub も無料の範囲内で Private リポジトリを作れるようになっていた。
そこで、まずは以下の流れを基本とすることにした。
- 私自身、開発の際には develop ブランチから feature, bugfix ブランチなどを切って開発
- GitHub へそのブランチでプッシュ。この時点で Heroku CI でのテスト自動実行
- develop へプルリクエストして、問題なければマージ
- develop の変更があった時点で Heroku CI のテスト自動実行
- テスト成功すれば Heroku へ自動デプロイ、失敗すれば停止
- 結果を Slack へ通知
Heroku CI の利用
Heroku CI を使えば 細かな設定はほぼ不要で簡単に上記手順を追加できた。
まず、Staging 環境と Production 環境の Heroku App をそれぞれ Heroku Pipeline に設置する。
次に プロジェクトのルートに app.json を用意して、テストに必要な環境を記す。
{
"description": "develop でテスト通り次第 Heroku デプロイ",
"environments": {
"test": {
"addons":[ "heroku-postgresql" ],
"formation": {
"test": {
"quantity": 1,
"size": "standard-1x"
}
}
}
}
}
Heroku 側で勝手にどのテストをするか見つけてくれるようで、Rspec の場合は特に何も指定せずにテストが始まっていた。上記の app.json で具体的にどのテストをやるかを指定することもできる。
テスト環境でも環境変数が必要になるが、その設定も 通常の Heroku App と同じようにコードからセット or Settings から ブラウザ上でセットできた。
また、テストが通ったら Staging 環境へデプロイの流れも Heroku 側で設定するだけで動作した。
このおかげで、チーム開発での それぞれが書いてもらったコードをしっかりと読んで、コードに対してのやり取りを GitHub 内でできるようになった。
かつての git push staging develop:master のコマンドは不要になった。"develop へマージされたら勝手に Heroku に上がる" とさえ認識しておけば、git push heroku master しなくても勝手に上がることの違和感はすぐになくなった。
最初は "面倒そうだな" と感じていた新しい開発環境が、ここまで簡単にできるとは思わなかった。これこそ、「さすが Heroku」である。
GitHub の恩恵
それだけでも満足だったけど、GitHub を開くと Security 関連で 通知が出ていた。Dependant alerts というものだった。Dependant alerts のおかげで、Ruby の Gem や Node.js の yarn で使っているライブラリにおいて、秘密性、一貫性、可用性を損なう リスクのあるものが自動で通知が来るようになった。それぞれの通知に段階があり、危険なアラートに関してはすぐ対応を求められるようになった。
さらに、GitHub で各種ライブラリに最新版が出た対た時点で1日に1度の Slack 通知が来るようになった。単にプロジェクトのルートディレクトリに、.github ディレクトリを作り、そこにちょろっとファイル名を記載するだけで動作した。このおかげで、今までは一定の周期で 一括で gem アップデートしてテストしてたのを、毎回新しいリリース内容をチェックして、問題なさそうならすぐに最新へ更新というプロセスを踏むことができるようになった。
Log4j
さて、ものすごくタイムリーに、Log4j の脆弱性に関して話題になっている。これの大きな問題は、自分達は Java と全く関係ないプログラミング言語を使っていたとしても、開発で利用しているライブラリやWebサービス側にも気を配る必要があるという点だ。
まずメインの Heroku 。現状の最新は Salesforce 側のこちらで確認できる。Heroku を使っていれば Heroku Addons 提供者側の詳細を調べていく必要がある。それ以外にも、もちろんAWS の各種サービスや Twilio など、それぞれをしっかりとウォッチする必要がある。
障害と似ていて、障害より危険な状態だ。障害は先方が把握をしていて、いつか治るってことがわかる。だから "ひたすら祈る" っていうのが基本だろう。セキュリティに関しても基本は "各種サービスが セキュリティ対応を完了してもらうことをひたすら待つ" ということかもしれない。しかし、いつまでも来ずにスルーされている可能性もある。その場合は こちらから連絡したり、他の外部サービスを探すということが必要になってくる。
今までに経験したことのないような、世界規模での大規模な改修が必要なこの問題。より世界を安全にという意味で、今後こうしたのは増えていくのだろう。その時に、そのままスルーするのか、我ごととしてしっかりと調査していくのか。これが次世代のセキュリティ対応に必要になってくるのかもしれない。
終わりに
おっと、そもそも今回の記事は Heroku CI の話だった。ありがとう Heroku そして GitHub。この両者の密接な連携によって、チーム開発をより効果的に実施できるようになったと肌で感じることができた。
そして "今" まさに問題となっている Log4j 問題。しっかりと各種連携先まで調査し、対応が必要なら対応する。その姿勢を忘れずに過ごしていこう。Heroku ユーザーの間で、各種アドオンの最新情報を共有していければ幸いである。
恐れるな。さぁ立ち向かっていこう！
