まとめ
- PRごとにプレビュー環境を構築する仕組みをEKSで実装した
- プレビュー環境のコンテナイメージにはアプリケーションのソースコードを含めず、コンテナ起動時にGitHubからクローンするようにした
- コンテナの起動後は定期的にブランチをポーリングし、
git pullするようにした。pnpn devのホットリロードと組み合わせることでブランチにプッシュしてから30秒程度でプレビュー環境に反映されるようにした
プレビュー環境をどう構築するか
PRごとのプレビュー環境構築の仕組みは様々なチームがそれぞれ実装している。mirage-ecs のようにOSS化している事例もある。僕が今所属しているフライルでもプレビュー環境がほしくなり、最初はECSベースで実装した。
ECSベースの初代プレビュー環境はCDKとecspressoを組み合わせたものである。GitHub Actionsからシェルスクリプトを呼び出し、CDKとecspressoでPRごとにECSサービスと周辺のリソース、コンテナイメージ作成する。そしてPRクローズ時にスタックを消す、という構成である。これはこれで動作していたのだが、2つほど課題を抱えていた。
1つめの課題はプレビュー環境の立ち上げとコミットの反映が遅い、ということである。PRごとにCDKのスタックをデプロイする必要があるし、コンテナイメージもプロダクション相当のものをデプロイしていたのでイメージビルドに時間がかかる。コミット反映時もイメージをビルドし直すため、反映までに時間がかかりすぎてストレス源となっていた。
2つめの課題はCDKとecspressoを組み合わせた仕組みのメンテナンスがやや難しいということである。プレビュー環境追加時にロードバランサーの設定を更新するような仕組みで複雑だったし、プロダクションやステージングとも違う構成のためサービスやプロダクト追加時に壊れることがあり、追従が必要となっていた。
これらの課題を解決するため、二代目としてEKSを用いたプレビュー環境として作り直した。1つめの課題に対する打ち手として、プレビュー環境の構築時にコンテナイメージのビルドを行わず、コンテナ起動時にGitHubからクローン・定期的なポーリングと git pull を行うようにした。2つめの課題についてはプレビュー環境ごとリソースやルーティング機能をKubernetesの中に置くことで運用しやすくした。
コンテナイメージを都度ビルドしない
プレビュー環境に何を求めるか。極端なことをいえば、プロダクションやステージングと同等の構成で動作確認できると最高ではある。しかし、それはコストやリソースの観点からあまり現実的ではないだろう。つまり、プレビュー環境はプロダクション・ステージングよりも制限された環境となり、どこまで制限するかはプレビュー環境に何を求めるか次第である。
フライルでは、プレビュー環境は複雑すぎない機能実装やちょっとしたUIの変更などの動作確認を主目的としている。つまり、プロダクションに近いインフラ上で動かしてみないと動作確認しづらい機能追加や、インフラの変更が絡むような変更は対象外ということである。これはつまり、ローカル開発に近いといえる。
初代環境では都度コンテナイメージにソースコードを含めていたが、冷静に考えるとローカル開発に近い環境でわざわざイメージを都度ビルドする必要はない。素朴にGitHubからクローンすればいいということになり、ベースイメージを1つ用意してその中でクローン・ポーリング・プルするようにした。

この仕組みに変えることで、特にコミット追加時のイメージビルド・プッシュ・コンテナ再作成のオーバーヘッドがなくなったことが大きい。UIのちょっとした修正に数分以上待つのは非効率なので、とても快適になった。
Kubernetesの活用
プレビュー環境アクセス時の認証、それぞれのプレビュー環境へのルーティング、プレビュー環境そのものといったリソースをKubernetes内で動かすようにした。ECS時代はALBの設定を変更していたが、EKSを使うことでNamespace内にIngressリソースを作ればルーティング可能となるし、各種カスタムリソースとコントローラーでAWS上のリソースも管理できる。Kubernetesのマニフェストに統一でき、シンプルになったと感じている。

おわりに
Kubernetesを活用したプレビュー環境の仕組みを紹介した。プレビュー環境はある種のプラットフォームなので、Kubernetesと相性がいい。今回は既存の仕組みを組み合わせて作ったが、もし必要であればCRD・カスタムコントローラーで拡張できるのもうれしい。イメージのビルドとプッシュ、プルが結構ボトルネックになっていたのでそれを解決できたのもよかった。普段のデプロイでもここに時間がかかっているので、本番環境もgit pullできればいいのにと思った。
PR
このページで紹介した仕組みは筆者が所属するフライルで作成しました。フライルではソフトウェアエンジニアを募集中です。このような活動に興味がある方はぜひご連絡ください。XのDM、メール、その他媒体何でもOKです。