「本番と検証で、なぜか設定が微妙に違う」という話は、インフラに触れたことがある人ならどこかで耳にしているはずです。
画面をクリックして作った環境は、作った本人の記憶と手順書の中にしか正解が残りません。
そこから抜け出すための考え方が、Infrastructure as Code（IaC）です。
DevOps を学び直している立場で一次資料をたどると、IaC はツールの名前ではなく「インフラをソフトウェアと同じ作法で扱う」という約束だと分かってきます。
手順書どおりに作ったはずの環境が合わなかった経験は、ありませんか？
IaCは「インフラの定義をコードに置く」こと
Martin Fowler 氏は IaC を、コンピューティングやネットワークのインフラをソースコードで定義し、ほかのソフトウェアと同じように扱うアプローチだと説明しています。
Infrastructure As Code（Martin Fowler）
AWS のホワイトペーパーも、アプリケーションのコード開発と同じ厳密さをインフラのプロビジョニングに持ち込むことだと述べています。
Infrastructure as code（Introduction to DevOps on AWS）
手順を人が覚えるのではなく、あるべき姿をファイルに書いて機械に再現させるのが要点です。
なぜ手作業では続かないのか
手作業のつらさは、作業そのものより「あとから再現できない」ところにある。
AWS のホワイトペーパーは、スクリプトと手作業を組み合わせる従来のやり方では手順書を書く人と実行する人が別になりがちで、更新されない手順書がデプロイの妨げになりうると指摘しています。
その結果、新しい環境を作るたびに同じものが再現できるとは限らない状態が生まれる。
サーバーごとに少しずつ設定がずれていく現象は、構成ドリフトと呼ばれるもの。
Fowler 氏も、サーバー間の一貫性が上がって構成ドリフトの問題が減ることを IaC の利点に数えています。
宣言的に書き、差分を確かめてから反映する
AWS のホワイトペーパーは、すべての構成を宣言的（declarative）に定義し、アプリのコードと同じようにソース管理へ置くべきだという立場。
宣言的とは、「サーバーを作る、ポートを開ける」と手順を並べるのではなく、「最終的にこうなっていてほしい」という状態を書く方式のこと。
HashiCorp の Terraform のドキュメントでは、宣言的な設定を書けば、リソース同士の依存関係をツール側が計算し、正しい順序で作成や削除をしてくれると説明されています。
What is Infrastructure as Code with Terraform?（HashiCorp Developer）
たとえば、ネットワークを 1 つ定義するコードは次のようなイメージです。
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "example"
}
}
// 以下、サブネットやセキュリティグループの定義が続く（省略）Terraform の基本的な流れは、書いた設定を初期化し、plan で変更点を事前に確認してから apply で反映するというもの。
ツールは現在の状態を記録した state を持ち、それを基準にコードと実際の差を計算します。
反映する前に差分をレビューできることが、画面操作との大きな違い。
バージョン管理とパイプラインに乗せて初めて効く
IaC の効果は、コードをファイルに書いた時点ではまだ半分です。
Fowler 氏は実践として、すべてをバージョン管理に置くこと、パイプラインで継続的にテストすること、大きな変更をまとめず小さく変えることを挙げています。
DORA の Version control のページで、バージョン管理に置くべきものとしてアプリのコードと並べて挙げられているのが、クラウドの設定ファイルやインフラを支えるスクリプト。
Capabilities: Version control（DORA）
変更がコードとして残れば、誰がいつ何を変えたかを履歴で追え、問題が出たら前の状態に戻しやすい。
アプリのコードに CI をかけるのと同じで、インフラのコードも「こまめに統合して、壊れたらすぐ気づく」流れに乗せてこそ意味が出てきます。
導入でつまずきやすいところ
つまずきやすいのは、ツールそのものより運用の約束のほうです。
- 急ぎの対応で画面から直接変更してしまい、コードと実際の構成がずれる
- パスワードやアクセスキーといった秘密情報を、コードに直接書いてしまう
- 1 回の変更に大量のリソースを詰め込み、差分が読めなくなる
特に「急ぎだから画面で直す」を例外として許し始めると、コードが正解ではなくなり、再現性の土台が崩れます。
最後に
IaC は、インフラの「あるべき姿」をコードに書き、アプリと同じ作法で管理するという考え方です。
宣言的に書いて差分を確かめ、バージョン管理とパイプラインに乗せる。
そうすることで、環境を作り直すことが怖い作業ではなくなるのだと、資料を読み比べて腑に落ちました。
CI や CD と同じく、DevOps という働き方を支える道具の一つとして位置づけると、全体像がつかみやすくなります。
書いたコードを Git に置いて本番の正解として扱う運用は、GitOps として別の記事にまとめました。
以上です。
コメントを残す