理系学生日記

おまえはいつまで学生気分なのか

「実践Terraform AWSにおけるシステム設計とベストプラクティス」を読んだ

ぼくは新しい技術を学ぶときは、たいてい以下の戦略を取ります。

  • 公式ドキュメントを読む
  • 当該技術に対する書籍を読む
  • 仕様があれば、その仕様 (RFC 等)に目を通す。ただし心が折れない程度に。

目的は以下 2 つの要素の獲得です。

  • 体系だった技術知識の獲得
  • 曖昧にでも、その技術の全体像を手に入れたという自信

Blog エントリや Stack Overflow、Qiita にはもちろんいつもお世話になっているのですが、 どうしても「これで全体像は理解できたのだろうか」という不安感が自分にはつきまといます。 公式ドキュメント、書籍でそこを手に入れたい。 Terraform を学び始ぶと決めたときの 1 つの心配は「書籍ってあるのかな」でした。あった。

初心者〜中級者向けの内容ということでしたが、そのとおり、初心者のぼくにとってもわかりやすい内容でした。 IAM から ECS まで多数の .tf のサンプルが織り交ぜられた内容で、「実践」の冠に相応しい書籍だと感じます。

実際に AWS リソースをどう作るのかだけでなく、個々の環境に対する .tf の管理方針やコンポーネントの分割指針等の設計思想、 .tf へのコードフォーマットやバリデーションと言ったプラクティス、tfstate の管理方針など、読んでおいてよかった系の内容がふんだんでした。

コンポーネントの分割指針

まず心に残ったのはコンポーネントの分割指針についてです。 ちょうど悩んでいたところだったので、渡りに船でした。 開発者の「感覚」ではなく文章として表現されていることが、自分にとっては非常に良いインプットになりました。

  1. 変更しづらく他のコンポーネントから依存される1 コンポーネントは別にする
  2. ステートフルなリソースは別にする
  3. 障害影響が異なるものは別にする
  4. 組織のライフサイクルに関わるリソースは別にする
  5. 関心事が異なるものは分離する

個別環境の管理方針

プロジェクトルートに environments ディレクトリを作成し、そこに各環境で必要なリソースを定義します。(略)

├── environments/
│   └── prod/
│   └── stage/
│   └── qa/

ちょうど、どうしようかという議論の最中だったので、その補強になりました。

この方式の欠点は、一部パラメータの値が違うだけのコードが、環境の数だけコピーされることです。これは、 書籍「Infrastructure as Code」でアンチパターンとして言及されています。しかし、実際には多くの組織で 採用されている方式です。

まさにここ。

全体を通して

ぼくのような初心者が terraform に入門するのには本当に良い本でした。 冒頭に述べた全体感の把握、「実践」の冠に恥じない充実したサンプル。この書籍に出会えてよかったです。

とはいえまだ書籍を一冊読んだだけなので、これから Terraform のドキュメント にきっちり目を通して、 この本でカバーされていない部分も理解していく予定です。


  1. 本文中では「安定度が高い」と表現されています