Help us understand the problem. What is going on with this article?

terraformのコードの管理と運用

More than 3 years have passed since last update.

はじめに

遅ればせながら、最近terraformを使い始めました。
簡潔明瞭な操作感およびコードシンタックスで学習コストも低く、容易に導入できます。
反面、感覚的に書き始めたコードがなんとなく動いてしまうので、事前の設計を疎かにして導入すると、後々負債1となってしまいそうな気がしました。
そのため、ここでは主にコードや運用の設計的な観点で考えたちょっとしたことをまとめておきます。
ややタイトル負けな内容ですが、何かの参考になれば幸いです。

※念のため、あくまで私個人の考えであり、所属組織等の見解ではありません。

前提となる知識(さらっと)

terraformとは

使い方

> terraform plan
コードロジックレベルのdry run。

> terraform apply
コードに書いたインフラをデプロイ。

> terraform show
今のインフラの状態を表示。

> terraform destroy
掃除。これ重要。

主なファイル

  • .tf

    • メインのテンプレートファイル。ここに書いたコードの通りにインフラをデプロイしてくれる。
  • terraform.tfstate

    • tfファイルに定義している各リソースの「状態」がjsonで書かれているファイル。terraform apply実行時に動的に生成/更新される。
  • terraform.tfvars

    • tfファイル内で使う変数を書いておくファイル。

コードの設計方針について

terraformのコードの書き方は自由度が高く、各リソースは順不同、ファイルも好きに分けて書くことができる。1ファイルに全部書こうが、サービス単位、リソース種別単位等で分けて書こうが動作する。
ここでは、AWSで以下のようなシンプルな構成を作る場合を例にして考えてみる。

サンプルコード

j-un/tfsample

モデルケース

  • VPCの中でいくつかWeb-DB等のシンプルなサービスが稼働していて、サービスごとに1つsubnetを作る。
  • 共通運用基盤的なsubnetを1つ作る。
  • 運用基盤はVPC内のホストから接続許可、サービス基盤はいい感じで通信制限する。
  • 諸々雑ですみませんがこんな感じ。 tfsample.png

コードの分け方

  • ネットワークの単位でブレイクダウンしてみる。上図の四角で囲った単位で分けるのが良さそう(AWS > VPC > subnet)。
  • 3つに分類できたので、以下のようなファイル構成にしてみる。
tfsample
├── aws.tf            # リージョンやゾーン、credentialの指定
├── base.tf           # VPCの定義、複数のsubnetで共有するセキュリティグループ、ルートテーブル等
└── testservice1.tf   # subnetの定義、subnet内のリソース固有のセキュリティグループ、ルートテーブル等

コードの書き方

  • 基本的に変数は使わず、書いてあることを見ればどういう構成になっているか分かるようにする。構成管理目的、具体的には昔ながらのサーバ一覧スプレッドシートのかわりとしてterraformを使いたいため。もっとInfrastructure as Codeしたい場合は、適切なレベルで抽象化して重複をなくしたほうがよいと思う。
  • 上記と反するが、credential情報はリポジトリに登録したくないので、terraform.tfvarsファイルに切り出しておき、.gitignoreに追記する等リポジトリに登録されないようにしておく。credential以外も変数を使う場合はterraform.tfvarsもリポジトリに登録したくなるので、credentialは別のところに書く。詳細は公式ドキュメント及びgoogle検索参照。

各ファイルの管理について

  • tfファイルは、何はなくともなのでリポジトリで管理する。
  • terraform.tfvarsは、先述の通りcredentialを書くならリポジトリで管理しない。credentialを書かないならリポジトリで管理する。
  • terraform.tfstateは、名前の通り「状態」が書いてあるファイルなのでリポジトリで管理しない、というかしてはいけない(AさんとBさんのローカルリポジトリで別の状態となってはいけない)。方法はいくつか用意されているが、s3に置いておく方法が一番お手軽だと思う。手順は公式ドキュメント及びgoogle検索参照。

運用について

  • 単純に手順を並べると以下のようになると思う。
  1. リポジトリからtfファイルをpull(or clone)する
  2. s3等に置いたterraform.tfstateをpullする
  3. tfファイルを更新する
  4. terraform plan を実行し、変更内容をテストする
  5. masterブランチにpull requestする
  6. 然るべき人がコードレビューする
  7. コードレビューOKであれば、masterブランチにmergeする
  8. s3等に置いたterraform.tfstateをpullしてから、masterブランチのコードを terraform apply する
  9. s3等にterraform.tfstateをpushする
  • 特に8、9のあたりは手順を間違いなく実行する必要がある。要はterraform.tfstateは常に最新のものを使わなければいけない。
  • そのため実際にapplyする作業は、7をトリガーにして、jenkins氏等間違いなく作業してくれる人に任せるべき。事情で任せられない場合は、作業者を一人に決めたほうが無難。

  1. といってもいわゆるアプリケーションのコードではないので、最悪全部捨てる!という判断も可能だし過度に恐れることはない。 

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away