ぼくは新しい技術を学ぶときは、たいてい以下の戦略を取ります。
- 公式ドキュメントを読む
- 当該技術に対する書籍を読む
- 仕様があれば、その仕様 (RFC 等)に目を通す。ただし心が折れない程度に。
目的は以下 2 つの要素の獲得です。
- 体系だった技術知識の獲得
- 曖昧にでも、その技術の全体像を手に入れたという自信
Blog エントリや Stack Overflow、Qiita にはもちろんいつもお世話になっているのですが、 どうしても「これで全体像は理解できたのだろうか」という不安感が自分にはつきまといます。 公式ドキュメント、書籍でそこを手に入れたい。 Terraform を学び始ぶと決めたときの 1 つの心配は「書籍ってあるのかな」でした。あった。
初心者〜中級者向けの内容ということでしたが、そのとおり、初心者のぼくにとってもわかりやすい内容でした。 IAM から ECS まで多数の .tf のサンプルが織り交ぜられた内容で、「実践」の冠に相応しい書籍だと感じます。
実際に AWS リソースをどう作るのかだけでなく、個々の環境に対する .tf の管理方針やコンポーネントの分割指針等の設計思想、 .tf へのコードフォーマットやバリデーションと言ったプラクティス、tfstate の管理方針など、読んでおいてよかった系の内容がふんだんでした。
コンポーネントの分割指針
まず心に残ったのはコンポーネントの分割指針についてです。 ちょうど悩んでいたところだったので、渡りに船でした。 開発者の「感覚」ではなく文章として表現されていることが、自分にとっては非常に良いインプットになりました。
- 変更しづらく他のコンポーネントから依存される1 コンポーネントは別にする
- ステートフルなリソースは別にする
- 障害影響が異なるものは別にする
- 組織のライフサイクルに関わるリソースは別にする
- 関心事が異なるものは分離する
個別環境の管理方針
プロジェクトルートに environments ディレクトリを作成し、そこに各環境で必要なリソースを定義します。(略)
├── environments/ │ └── prod/ │ └── stage/ │ └── qa/
ちょうど、どうしようかという議論の最中だったので、その補強になりました。
この方式の欠点は、一部パラメータの値が違うだけのコードが、環境の数だけコピーされることです。これは、 書籍「Infrastructure as Code」でアンチパターンとして言及されています。しかし、実際には多くの組織で 採用されている方式です。
まさにここ。
全体を通して
ぼくのような初心者が terraform に入門するのには本当に良い本でした。 冒頭に述べた全体感の把握、「実践」の冠に恥じない充実したサンプル。この書籍に出会えてよかったです。
とはいえまだ書籍を一冊読んだだけなので、これから Terraform のドキュメント にきっちり目を通して、 この本でカバーされていない部分も理解していく予定です。
-
本文中では「安定度が高い」と表現されています↩
