Terraformを運用するにはTerraform Cloudが一番楽だった。
仕事でも個人でもTerraformを使用してきました。
TerraformでのIaCは非常に簡単なので重宝してます。
今回は、作ったTerraformをどのようにデプロイ(apply)するのかについて検証しました。
localでterraform apply
人こそが最強のci/cdツールである。そんな感じですね。
localで実行するときはapplyするの時間が無駄ですね。(terminalをじっと眺めてしまうので)
監査とかが絡んでくると権限の分離とかが必要になってくるのでそういうときはリリースする人を立ててしばらく手動でお願いしたりする。
github actionでterraform apply
公式が書いてあるドキュメント通りにやったら一瞬です。
公式のものを少しいじって、planとapplyを分離してましたが、やってみると意外と使いづらいところがあります。
terraformのstateが増える度にgithub actionを作る
公式のgithub actionをあまりいじらないで使う場合はgithub actionをそれぞれ量産してく必要があります。地味に面倒。なんど作り忘れたことでしょうか。
修正差分からterraform applyを実行するディレクトリを決める。
対象のファイルのパスを取得して、ファイル名を削除したパスに整形した後にディレクトリ移動して実行する。
複雑さはそれほどでもないので書いてしまってもいいです。
問題は、そのときに依存関係もうまく解決する必要があることです。terraformはremote stateを使って、他のstateに依存したstateを構築することができます。実際よく使うことになると思います。
複数のterraform stateを修正する差分がコミットされた場合、実行順番を考えないとエラーになってしまうかもしれません。
権限問題
github actionからawsやgcpに接続する場合に各プロバイダのsecretを設定する必要があります。github actionはそのリポジトリへの書き込み権限を持つ人であれば誰でも修正可能なので本番環境へのapplyするsecretを使用すると、悪意のある社内ユーザーにsecretを盗まれてしまいます。github enterpriseユーザーであればgithub environmentと言う機能を使用して、actionの実行に承認機能をつけられるので抜き取りへの対処が可能です。毎回特定のユーザーの承認待ちという状況が発生しますが。。
他のCI/CDツール
AWS CodebuildやGCPのCloud Buildでもほぼ同じ問題が発生します。
Terraform Cloudとは
hasicorp社が提供しているterraformの継続的デリバリーを提供するクラウドサービスです。
特徴はいくつかあります。
まず、stateの保存がterraform cloudにできること。dynamodbやs3などを構築することなく、サクッと使えてしまいます。
GitHubと連携した継続デリバリーの設定が可能
- どのリポジトリ
- どのブランチ
- どのファイル
- どこのディレクトリでterraformコマンドを実行するか
これらの要素をGUI上でぽちぽち設定できます！
安全なsecretの管理
terraform cloud上にterraformのvariableを設定できます。secretはsensitiveに設定するとterraform cloud上にも表示されないので変に抜き出されることはありません。
依存するstateの更新
terraformのstateはremote stateの機能を使用することで依存関係を持ってしまいます。そんな時もstateAが更新されたらstateBを更新するというような挙動を設定できます!
５人まで無料
個人で使うなら多要素認証を設定して使用できます。
有料プランならSAML 2.0のSSOも設定できるのでわーい。導入しやすいぞ！
付録
既存のterraformを移行しようとしたのですが、
awsのs3とか、sqsのようにアクセスポリシーをもつサービスの構築がaccess deniedで失敗してしまいます。
たぶん、アクセスポリシーを全て許可のようにしたらうまくいくんだろうけどちょっとわからない。。。
とりあえず、個人開発は全てGCP系のサービスを使っているので問題はないけれどちょっと気持ち悪い。
まとめ
ということで、長く記載しましたが、Terraform Cloudが一番楽でした。すこしでも開発生産性を上げるのが後々に聞いてきます！
Discussion