この記事は、「Speee Advent Calendar 2016」の5日目です。
4日目は、id:nisshieeより、「Turbolinks再考」です。
今日は、Terraformの構成について再度考えたいと思います。
先日書いたブログで、hashcorpが公開しているTerraformのbest-practiseについて読み解きました。
ブコメでもいくつかあった「つらそう」という意見
つらさにも種類があるとは思うのですが
僕が実際にベストプラクティスを読んでいて思ったのは
- モジュールが2階層構造になっており、抽象化されたモジュールを読み解くのがしんどい
- モジュール単位で変数定義が必要なため、3回変数宣言をしなければならないのがめんどくさい
という2点。
ただこれも、多くのリソースを抽象化して管理したり、ファイルの肥大化を防ぐ意味では有用であろうという結論を出していました。
実際にはオーバースペックだった
いざ使ってみると、仕事である程度の規模のインフラを管理する場合には役立つこのベストプラクティスも
個人で数台のインスタンスを立てて、とりあえずwebサービスが動く構成にするには
少しオーバーだなと感じることが多かったのです。
そもそも、Terraformを使ってAWSのインフラ管理を楽にしたいと思って導入しているのに
- まずは必要なリソースをmoduleに切り出して
- 変数定義をmoduleの数だけ書いて
- terraform getやplanで動作の確認をして
と、ちょこっとインスタンスを立ち上げるだけの作業が非常に大きくなっていき
結果Terraformの準備に時間がかかる本末転倒な結果になってしまいました。
例えばマイクロな構成でEC2インスタンスだけ立てるならブラウザでポチポチやればいいじゃん。とも思ったのですが
運用するサービスが分かれている場合、最低限ネットワークは分離したかったりするので EC2 1台立てるのに必要な VPC, subnet, route table, gateway...etcを考えるとやはりTerraformを使ってコマンド1発で構築したい。
軽量Terraformテンプレートを製作
そこで
- hashcorpのベストプラクティスほど大きくなく
- ありがちな構成を整えた
Terraformのテンプレートを作り始めました。
構成はこのような感じ
├── micro
│ ├── micro.tf
│ └── terraform.tfvars
└── modules
├── compute
│ └── ec2
│ └── ec2.tf
└── network
├── route_table
│ └── route_table.tf
├── security_group
│ └── security_group.tf
├── subnet
│ └── subnet.tf
└── vpc
└── vpc.tf
このテンプレートで生成可能なのは「80番ポートだけ空いた、インターネットに疎通可能な1台のEC2インスタンス」です。
各リソースを操作可能なIAMユーザーを用意して、EC2用のキーペアだけ作成しておけばコマンド一発で立ち上がります。
読み始める場合は /micro/micro.tfからスタートし、各moduleをのぞいてもらえるとわかりやすいと思います。
※これからいくつも構成のテンプレートを用意しようと思っているので、最小構成の意味でmicroと命名しています。
この構成の利点は
- 階層が減ることで各moduleの見通しが良くなる
- 変数定義の回数を減らせる (micro.tfと各moduleの2回)
の2点です。
ベストプラクティスでは存在したcomputeモジュールなどの、1段階リソースを抽象化したモジュールを廃止し、直接リソースを定義したモジュールに変数を渡すことで
構成を1階層減らしました。
これによって構成がシンプルになり、小規模な環境を準備する際のコストが減らせるかと思います。
またベストプラクティスに比べて、Terraform初心者に読んでもらうときにも非常に優しくなっていますね。
反面、この構成だとPRO/STG/DEVのような開発環境に分けてコードを記述することには対応させていないのですが
その場合はmicroディレクトリの下に環境ごとのディレクトリを作って、tfファイルとtfvarsファイルを置けば対応可能かと思います。
この先の展望
このリポジトリは「個人がAWSでWebサービスを始めるときに使えるよくある構成のテンプレート集」化していこうと思います。
仕事をしていても感じるのですが
Webサービスをつくるときに「絶対するであろう作業」が自動化されていないことで、各個人の時間が吸い取られていくので
これを解決することで、より価値提供のための開発に集中できるはずです。
まずはよくある構成を充実させて、そのうちコンテナを使った構成などにも対応できればと思っています。
