IaC(Infrastructure as Code)とは?サーバー設定をコードで管理する仕組み

結論: IaC(アイエーシー)は、サーバーやネットワークなどのインフラの設定を、コード(ファイル)で書いて管理する考え方です。手作業で画面をクリックする代わりに、設定をファイルに書いて、ツールで自動的に反映します。同じ環境を何度でも作れ、変更の履歴が残り、レビューもできるのが利点です。一方で、手作業で変えると、コードと実際の環境がずれる点と、秘密情報をコードに書かない点に注意が必要です。

IaCとは

IaCは、Infrastructure as Code(インフラストラクチャ・アズ・コード)の略です。インフラとは、アプリを動かす土台となる、サーバー、ネットワーク、データベース、ストレージなどのことです。

これまで、インフラは、管理画面で画面をクリックしたり、サーバーにログインしてコマンドを打ったりして、手作業で用意することが多くありました。IaCでは、その設定をコードで書きます。

手作業との違い

「担当者によって、手順が違う」「いつ、誰が、何を変えたか分からない」といった、属人化を減らせます。履歴の管理は、Gitのブランチの考え方と同じです。

書き方のイメージ

次は、クラウド上に、ストレージ(バケット)を1つ作る、設定の例です(Terraformの書き方の一例)。

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket-name"
}

「どんなものが欲しいか」を、宣言します。ツールが、今の状態と比べて、足りないものを作り、違うものを変えます。

• コードに書いた状態を**「あるべき姿」**として扱う
• 実行すると、実際の環境を、その姿に近づける

IaCの流れ

1. コードを書く(あるべき状態を、ファイルに定義する)
2. レビューする(Gitなどで、変更点を、複数人で確認する)
3. 事前に確認する(多くのツールに、変更内容を実行前に表示する機能がある。Terraformのplanなど)
4. 適用する(実際の環境に反映する)

CI/CDと組み合わせて、レビューが済んだら自動で適用する運用もあります。

代表的なツール

使うクラウドや、チームの得意分野によって、選びます。特定の製品を、おすすめするものではありません。

DockerやKubernetesの環境も、IaCで構築・管理することが多くあります。

注意点

① 手作業で変えない(ドリフト)

コードで管理しているのに、画面から手作業で設定を変えると、コードと実際の環境が、ずれてしまいます。これをドリフトといいます。

• 次にコードを適用した時に、手作業の変更が消されることがある
• 「実際の環境が、どうなっているか」が、コードから分からなくなる

変更は、コードを直して、反映します。

② 秘密情報を、コードに書かない

パスワード、APIキー、認証情報を、コードに直接書いてはいけません。Gitに保存すると、履歴に残り、漏れる危険があります。専用の秘密情報の管理の仕組みを使います(APIキーとは)。

③ 実行の前に、変更内容を確認する

コードの間違いは、一度に多くの環境へ反映されることがあります。

• 実行前に、何が作られ・変わり・消えるかを必ず確認する
• 特に、「消える」ものがないかを見る(本番のデータベースなど)

④ 権限を絞る

IaCの適用に使うアカウントは、強い権限を持ちがちです。必要な範囲に絞って与えます(最小権限の原則)。

向いている場面

• 開発・検証・本番など、同じ構成の環境が複数ある
• 複数人でインフラを運用する
• 環境を作り直すことが多い(障害からの復旧、新しい拠点)
• 変更の履歴と、承認を残したい

サーバーが少なく、ほとんど変わらないなら、手作業でも十分です。まず、1つの環境から試し、慣れてから広げるのが現実的です。開発者向けの基盤づくりは、プラットフォームエンジニアリングとはも参考にしてください。

まとめ

• IaCは、インフラの設定を、コード(ファイル)で書いて管理する考え方
• 同じ環境を何度でも作れ、履歴が残り、レビューできる
• 手作業で変えると、ドリフトが起きる。秘密情報はコードに書かない
• 実行の前に、変更内容を確認する。権限は絞る

関連記事:Dockerとは、Kubernetesとは、CI/CDとは、Gitのブランチとは、APIキーとは