Zenn
🐷

【Terraform】使用上の注意

2023/05/09に公開
AWS
Azure
Terraform
tech

設計運用で注意すること

箇条書き

  • デプロイしたリソースをトラッキングし、必要な場合は設定を変更できるよう、管理しておくこと。
  • リソースの利用状況を常に見て、不要なリソースをクリーンアップすること。
  • 新しいコードをデプロイする際には、バージョン管理システムを使い、管理者がいつでも前の状態に戻せるようにすること。
  • 定期的なバックアップを取得し、災害時のリカバリーを確保しておくこと（リカバリ手順を準備しておくことも重要）。
  • リソースのスケーリングを行う際は、設定を保存しておいて必要なときに再利用できるようにすること。
  • ロールベースのアクセス制御を行うことで、不正な操作を防止し、管理のしやすい環境を維持すること。
  • ロギングや監視ソリューションを導入し、リソースの使用に関する情報を保存し、不正な操作を検知すること。
  • リソース毎に適切なサービスレベルアグリーメント（SLA）を定義することで、リソースのクオリティを維持するための取り組みが可能になる（結構手間かかるけど重要）。
  • リソースの変更をテストするための環境を作成しておくことで、本番環境への影響を最小限に抑えることが可能になる
  • リソースの変更時には必ずテストを行うこと。
  • リソースのアラートを設定し、リソースの状態をモニタリングすること。

メリット

  • 自動化が可能：Terraform を使用することで、手動で行っていた環境構築やリソースの作成などの作業を自動化することができます。これにより、時間とコストを節約することができます。
  • インフラストラクチャの可視化：Terraform を使用することで、インフラストラクチャの構成をコードで管理することができます。これにより、簡単にインフラストラクチャを可視化することができ、問題の特定やデバッグが容易になります。
  • 再利用性の向上：Terraform を使用することで、コードでインフラストラクチャを管理することができます。このため、同じコードを再利用して、複数の環境を作成することができます。これにより、コードの再利用性が向上し、開発者の生産性が向上します。

デメリット

  • 学習コスト：Terraform を使用するためには、Terraform の概念や構文を理解する必要があります。また、Terraform はクラウドプロバイダーに依存しているため、クラウドプロバイダーのサービスについても理解する必要があります。
  • バージョン管理の難しさ：Terraform は、コードで管理するためバージョン管理が非常に重要です。バージョン管理を誤ると、重大な問題が発生する可能性があります。
  • コスト：Terraform を使用するためには、コストが発生する可能性があります。コードの作成や管理に時間がかかるため、開発者の時間とコストがかかることがあります。

手順を整備すること

  • IaC のメリットは手動構築と比べ、資材を作ってしまえば、コマンド打鍵の手順だけで済むという点。しっかりとした手順を作ることで事故を抑止できます。
  • 複雑な手順になりにくく、大きな変更が発生することも少ない。作成するリソースはすべて Terraform の定義ファイルに記載しているため、レビューをコードで行えるのもメリットの一つ（差分確認などがしやすい）。

tfstate ファイルの取り扱いについて

  • tfstate ファイルはデフォルトではローカルに保存されます。ただし、大人数で作業を行うチーム開発でローカルに保存していて困ります。

更に詳しい内容はXX_tfstate ファイルの取り扱い にて記載します。

バージョンを統一する

Terraform のバージョンやプロバイダーのバージョンは揃えるべきです。

Terraform 自体のバージョンはインストール時に選択すればよいです。

プロバイダーのバージョンは少し特徴的な概念ですが、プロバイダーのバージョンによって扱うことのできるリソースの種類などが変わります。※基本的にクラウド側で新しく GA されたサービス・機能は現在の Terraform では正式にサポートされないのでプロバイダーのバージョンアップが必要です。

クラウドは更新頻度が高く、環境差異が出やすいのでプロバイダーのバージョンは統一しておくことが重要です。

例えば、Azure の場合、tf ファイルが配置されているディレクトリ（terraform apply を行うディレクトリ）に「provider.tf」という命名でプロバイダーのバージョンを記載しておくことが慣例になっています。

provider "azurerm" {

  version = "2.20.0"

}

ブランチについて

$terraform apply を実行するブランチはチーム開発時に非常に重要です。
コマンドについてはこちらで解説しています。

ここに認識の違いがあると最新の tf ファイルでなかったりして、意図しないリソースの削除や再作成が走ってしまう可能性があります。

「どのブランチで apply するのか」や「apply したらすぐに master ブランチに push する」ような感じでルールを決めておくと安全ですね。

構築方式について

  1. 手動構築

    1. IaC の特性上、コマンド打鍵のみで済むので、非常にお手軽です。ただし、ヒューマンエラーの可能性があります。しっかりとレビューをして、構築手順を確立させておくことが重要です。

      個人ユーザに作成権限を割り当てる必要があるので、権限昇格のロジックが組んでおいたほうが良いです。

      例えば、Azure であれば Azure AD Privileged Identity Management を使用すれば、一時的な権限昇格申請を作業者が申請し、管理者権限を持ったユーザが承認フローを行うことができます。

      もしくは、Terraformを実行するサーバに特定の権限を付与したマネージドID を設定して、それを使用する方法など様々あります。

  2. 自動構築

    1. jenkins, CircleCI. Travis, GitLab CI や Azure Pipeline, AWS Code Build などの SaaS を使用するやり方

      一度環境を作ってしまえば、ヒューマンエラーが発生することはないので運用管理コストが削減できます。

      ただし、認証情報などを外部のサービスに持たせることになるので、認証情報をどのように取り扱うかについてはしっかりとした設計が必要ですね。

Discussion