ここ数年くらい放置していた個人サイトを、技術検証も兼ねてリニューアルした。
といってもメインコンテンツはブログなので、個人サイトのほうはトップページとお問い合わせフォームくらいしかないのだが、
- Visual Studio Codeの活用。
- 同じくWSLとコンテナ（Docker）も利用してのローカル開発環境の整備
- ヘッドレスかつサーバーレスなfront(Next.js)とback(Python)の分離
- TerraformによるIaC
- GitHub Actionsを使ったCI/CD
を行ったかなりの意欲作である。
ほとんど裏側の話のため、利用者にはあまり関係がないのがさみしいところだ。
やってみた感想
Visual Studio Code
Visual Studio Codeがさらにすばらしくなっている。元々Visual Studio大好きだったので使い勝手もよく似ている点も個人的にうれしいところ。
LinterやFormatter等のツールとも連携できるのはもちろん、コンテナ上でのリモート開発までできると来ており、文句なし。
WSLとコンテナ（Docker）も利用してのローカル開発環境の整備
ながらくVagrantを使っていたのだが、Docker desctopを使うために鞍替えした。コンテナを使うと設定や通信がやや複雑化するものの、気軽に立ち上げて気軽に捨てられる他、いつ立ち上げても同じ（おおむねは）環境が用意できるのは安心感がある。一人で開発している場合でも便利だが、チーム開発では威力を発揮してくれるに違いない。
ヘッドレスかつサーバーレス
安い、安い、実際安い。月200円いくかどうかというところじゃなかろうか。
しかも早いし堅牢である。FrontendがCloudFront+S3、BackendがAPI Gateway + Lambdaなので、ちょっとやそっとスパイクしても――してほしいものだが――ダウンどころか遅延さえしないであろう。もっともその場合はコストに反映されるのだが、それでも全てEC2で賄うことを考えれば全然安いほうであろう。
かねてから十全にS3へのオフロードをしたいと思っていて、Hugoを使いつつ頑張っていたのだが、やや使い勝手に欠ける面が無きにしも非ずだった。今回は割と満足いく使い勝手になった気がしている。ある程度の規模があるプロジェクトだと、おそらく素直にコンテナ＋Fargateの構成が開発効率がよいと思うが（思いっきりマイクロサービス化するならともかくとして）、小規模なプロジェクトだとAPI Gateway+Lambdaは素晴らしい選択肢になると感じる。
ただ一方で、API GatewayのリソースをTerraformで構築するのは、業務用の本番環境にはお勧めしたくない選択肢という感があった。開発・運用で頻繁に更新をかける類のリソースはTerraformと相性がいまいち良くない。
TerraformによるIaC
コードとして書き上げるまでに本当に本当に本当に手間がかかるのだが、一方で、設定の統一が大変行いやすいというメリットは捨てがたい。雑にTerraform applyを欠けただけでも設定がすっきり統一されるのは爽快である。また、どのようなリソースをどの流れで作ったのか、確実にドキュメント化されているという安心感があるのも管理上見逃せない。コンソール上でポチポチ手作業で作るのは臨時の作業くらいなものであった。むしろこれまでに手作業で作ったリソースもTerraform化を進めたくらいである。
作業効率の不利さもコードの再利用が進めば軽減できるのではないかと期待している。今回、あとで流用できるようにコードはほぼ全部Publicリポジトリで公開するつもり。
GitHub Actionsを使ったCI/CD
CodePipelineも便利なのだが、GitHub Actionsはgitなのにディレクトリ単位でCI/CDの起動を管理できる点が見逃せない。LambdaについてはMonorepo構成を取ったので――さすがに関数ごとにリポジトリを切りたくなかった――これは嬉しい点。
おそらく個人サイトのほうはそこまで頻繁に更新しないのでメリットが目立たないが、頻繁に更新するのなら（すべきなのだが）CI/CDで自動化できているとやはり楽。しかも手作業がないのでオペミスの心配もない。構築するまでが大変だが、いったん構築できてしまえば大変幸せになれる印象。
