Terraform リファクタしてみた〜そしてAtlantisへ〜

弊社（Voicy）もサービス開始から7年経ち、レガシーな部分も散見されます。私はSREとして今年の6月に入社したばかりなので、７年間の歴史の10分の１もいないわけですが・・・
入社した当初に動いていたプロジェクトとして、Terraformのリファクタがありました。
それについて本日は書いていきたいと思います。

レガシーな部分

VoicyのTerraformの何がレガシーか？

バージョン

まず、Terraformのバージョンが古いです。
本日現在 1.6.6 が最新で、1.7.0 の rc1 も出ています。
リファクタし始めた当初、バージョンは 0.12.x でした。
弊社はAWSを使用しているので、aws モジュールとの絡みもあるのですが、新しくしなくても動いているというのがいけないんでしょうね。

構造的問題

次に、構造の問題です。

.
└── dev_stage_prod
    ├── main.tf
    ├── main.tf_dev
    ├── main.tf_stage
    ├── main.tf_prod
    ├── output.tf
    ├── provider.tf
    ├── variable.tf
    └── vpc.tf

terraform は plan や apply を実行する際に、main.tf を参照して実行するわけですが、環境がいくつかある場合、やり方がいくつかあります。terraform 的にはワークスペースを使用するというが、一応推奨されていた方法ではないかと思います。

ですが、この環境、main.tf が環境ごとに用意されており、実行する際に、編集・コピペして使用する感じになっていました。

この手法の、メリット・デメリット挙げてみます。

[メリット]
- 環境ごとに main.tf をコピー・編集するだけで、環境ごとに異なる構成をプロビジョニングできる
- 構成がシンプル

[デメリット]
- 環境ごとに main.tf をコピー・編集する必要があり、手間がかかる
- 環境ごとに main.tf があるので、誤った環境のものを適用する可能性がある

リファクタの方法

リファクタの方法も色々ありますし、さまざまな検討をしました。

どんな方法があるか？

例えばですが・・・

- ディレクトリ構造の利用
- ワークスペースの使用
- 変数ファイルの活用 
- モジュールの使用
- 環境変数の使用
- 分岐戦略の採用

どの方法を採用したか？

メリデメを検討した結果、Voicyで採用されたのは、ディレクトリで環境分けをし、shared モジュールを使用するが、シムリンクは採用しないという方針となりました。

.
├── dev
│   ├── main.tf
│   ├── provider.tf
│   └── variable.tf
├── prod
│   ├── main.tf
│   ├── provider.tf
│   └── variable.tf
├── shared
│   ├── iam.tf
│   ├── network.tf
│   ├── output.tf
│   └── variable.tf
└── stage
    ├── main.tf
    ├── provider.tf
    └── variable.tf

この方法のメリデメ

それでは、この方法のメリット・デメリットも確認していきましょう。

- ディレクトリ分けすることで、環境分けが明確
- shared モジュール採用により、共通部分は共通部分で重複を排除できる
- コピペで失敗することがない

後はリファクタするのみ

元々の構造から、新しい構造への変更は、なかなか大変な作業です。
shared モジュールへの変更もあり、作業量的にもかなりなものでした。
ですが、必要な部分のリファクタが終わり、次はバージョンアップですね。。。

バージョンアップはなぜ行う？

リファクタするだけであれば、バージョンアップはサポート切れとかを考えなければ必要ない作業です。
いや、やった方がいいのは確かです。
では、なぜやるか？

Terraform も CI/CD したいよね

今までローカル実行を行なってきた Terraform なのですが、CI/CD やっていきたいよねという話になりました。で、何を使うかの検討を行ったのですが、最終的に Atlantis を使用することになりました。

Atlantis とはなんぞや？

Atlantisとは、Terraformを以下のように進化させるツールです。
https://www.runatlantis.io/

- プルリクエスト駆動のワークフロー：PRで自動実行できる
- 自動化されたプランと適用：plan/apply の自動実行
- チームのコラボレーションと透明性：チーム内でレビューできる
- セキュリティとアクセス制御：実行承認
- 状態管理の簡素化：ローカルで状態管理する必要がない
- 柔軟性と拡張性：様々なカスタマイズが可能
- 履歴の追跡と監査：証跡が取れる

いや、便利よね。

バージョンアップ関係ある？

Atlantis を github 上で実行すると、SecretManagerから読み込みしているセキュリティ情報が、github 上に残ってしまうのです（0.12.xとかだと・・・）。バージョンアップ必須です。

- 0.12.x ダメダメ
- 0.13.x ダメダメ
- 0.14.x sensitive に対応

ということで、とりあえず 0.14.x にあげることになりました。

0.14.x でもダメ

0.14.x は sensitive に対応はしているのですが、tfstate には残ってしまうという問題が出てしまいました。ということで、もう一段階あげて、0.15.x　へとバージョンアップを行い、一応の問題解決が見られました。

Atlantis 入れてどう？

Atlantis入れてどうなった？という部分です。

良い部分

よかった点をあげていきたいと思います。

- github 上で実行することで、証跡が残る
- 誰が実行したかわかる
- 実行前レビューをするようになる

微妙な部分

若干微妙な部分についても

- 権限周りは絞りきれない
- ローカルから実行しようと思えばできる
- 自動 apply はこわい

今後

今後ですが、引き続きのバージョンアップや、自動 apply などやっていきたいと思っています。

We're hiring

絶賛、エンジニア（だけではなく）募集してます。
カジュアル面談もやっていますので、お待ちしています。