IaC導入実践 ~Terraform~：前編（導入の苦労とその解決策）

本記事はIaC導入を進めるにあたって、苦労した点やその回避策をまとめた内容となります。
前編は導入にあたっての知識を中心に、後編は導入時の技術的な話を中心に記述予定です。

はじめに

本稿は、Infrastructure as Code (以下、IaC) を導入するに当たっての失敗や苦労話とどのように解決したかをまとめたいと思います。同様に苦労されている方々の参考になれば幸いです。
また、本記事は複数に分けて投稿予定です。今回は導入時の注意点や、導入のメリット等を中心に書きたいと思います。（※次回以降は具体的な構成や技術的な話を書いていく予定です）

IaC(Infrastructure as Code)とは

IaCとはインフラ運用管理をコードで管理・運用する手法です。
コードで管理することによりアプリ開発等で用いられるバージョン管理手法や、
冪等性を保った環境デプロイを実現できます。

本記事ではIaC導入による運用への影響をお伝えしていきます。

IaC導入に当たっての注意点

ツール選定

IaCツールには下記のような種類があります。

Terraform, Ansible, AWS CloudFormation など

また、選定には下記のような項目について検討が必要と考えます。

デプロイ先環境への対応状況
導入後の運用への影響
コードの学習コスト

今回の環境では、IaCツールとしてTerraformを採用しました。
そして、Terraform の中でもTerraform Cloud(Plus)を採用しています。
なお、選定理由は次の通りです。

デプロイ先環境への対応状況
→有名なパブリッククラウドやオンプレ環境など、対応範囲が広い
導入後の運用への影響
→SaaS版を利用することでIaCツール自体の運用コストを低減。ポリシー運用も可能。
コードの学習コスト
→HCL(Hashicorp Configuration Language) の記述方法がシンプル。
　直感的な構文と明確な構造により、理解がしやすく他の言語に比べて
　学習コストが低いといえる。

Terraform 製品サイト
Terraform Cloud : HashiCorp社が提供するSaaS。Plus tierは有償版。無償版(Free tier)も存在。

導入時の苦労と対策

IaC化を進めるに当たって、既存環境に導入する際に気をつけるべき点がいくつかあります。

開発中のIaCコードのテストが既存環境へ影響しないようにすること
採用したIaCツールでは対応できない領域を見極めること

既存環境をコード化

まずインフラをコードで管理するに当たって、既存環境に導入する場合は2つの選択肢があります。

インフラ情報を元に0から作成
インポートを利用
・Terraform Import
・インポートツールの利用 (Terraformer, Azure Terrafy)

0から作成する場合は、新規に作成する場合と変わりません。
アーキテクチャを理解し利用するサービス等を既存環境に合わせて定義していきます。
Importを利用する場合は、Terraformの標準機能であるImportを使う、もしくは有志によって開発
されているインポートツールの利用が挙げられます。

標準機能のImportを使うことも可能ですが、パブリッククラウドの既存環境(特にAWS, Azrue, GCP)の環境がインポート元となる場合、インポートツールを使った方が早くソースコードの雛形を作成することが可能になる場合があります。
なお、インポートするだけでコード化が完了することは稀です。
コードで定義できる設定や対応範囲には限りがあるため、インポートしたコードをそのままapplyしたとしても設定や細部まで対応できているかの保証はありません。
Terraform Import(公式ドキュメント:英語)
Terraformer
Azure Terrafy

IaC(Terraform)導入によって変わる運用

IaC導入がインフラ運用に与える変化の一つとして、アプリ開発等で行われるバージョン管理のナレッジがそのまま適用できるという点があります。
レガシーなインフラ管理ではエクセルファイル等で更新/構成を管理する場合もあったと思います。
そのような運用を続けることは環境変更が多く発生するような昨今のクラウド/コンテナ環境には向いていないことは明らかです。
人の手による更新によってファイル名を変更したものが乱立したり、どれが最新版かわからないといった事象に陥ったことがある方もいらっしゃるのではないでしょうか。

IaCではそういった変更管理をGitのようなバージョン管理システムの機能を用いることができます。
誰が/いつ/何を編集したのかはGitの履歴を見ればよいことになります。
また、TerraformがGitと連携すれば、誰が/いつ/どのバージョンのコードを環境に適用したのかTerraformの履歴を見るだけですべて把握できるようになります。
そして、IaCがもたらすもう一つの変化があります。

それは”冪等性の担保”です。
人の手による作業はどうしてもミスの可能性が残ります。
ですが、IaCによるデプロイは構築対象が数百台を超える規模になっても変わることはありません。
同じコードであれば誰が実行しても同じ結果を得られるということです。

加えてTerraformはポリシーチェック(Sentinel)機能、環境構築による費用の変動チェックをデプロイ毎に実行することが可能です。ポリシーもコードで定義できることで、ポリシー自身もバージョン管理システムで管理可能になり、チェックが自動化することでポリシーチェックの頻度が増え、結果的に
ガバナンスの向上につながります。

これらの変化は大きなメリットになると思います。