クラウドを使い始めると、サーバーやネットワークを画面から作る機会が増えます。最初は手作業で十分でも、環境が増え、作り直しや変更が重なると、手作業では追いつかなくなります。そこで使われるのが「IaC（Infrastructure as Code）」という考え方です。
この連載では、IaC の道具を使ってクラウドの環境を作っていきます。最初の今回は、道具の話に入る前に、IaC とは何かを整理します。
IaC とは
IaC は、インフラの構成を「コード」で定義し、作る・変える作業を自動化する手法です。ここでのコードは、プログラムというより、「どんなサーバーを、どんな設定で置くか」を書いた設定ファイルのことです。
手作業では、人が画面を操作したり、コマンドを1つずつ打ったりして環境を作ります。IaC では、作りたい環境を設定ファイルに書き、道具がその内容のとおりに環境を作ります。
なぜ IaC が必要なのか
手作業での構築には、次のような悩みがあります。
- 時間がかかる。同じ環境をもう1つ作るにも、同じ操作を最初から繰り返す
- 誤りが起きやすい。設定値の入れ間違いや、手順の抜けが起きる
- 記録が残りにくい。誰が、いつ、何を変えたかが分からなくなる
- 環境どうしがずれる。検証環境と本番環境で、いつの間にか設定が違っている
クラウドでは、環境を必要なときに作り、要らなくなったら消す使い方が増えています。作る・消すの回数が増えるほど、手作業の負担と誤りも増えます。
IaC で何が変わるのか
設定ファイルで環境を作ると、次のことができるようになります。
| できること | 中身 |
|---|---|
| 同じ環境を何度でも作れる | 同じ設定ファイルを使えば、同じ環境ができる |
| 設定ファイルが設計書になる | 何が、どんな設定で置かれているかを、ファイルを読めば分かる |
| 変更の履歴を残せる | 設定ファイルを Git などで管理すれば、いつ、何を変えたかが残る |
| 手作業の誤りが減る | 決まった内容を道具が実行するので、入れ間違いや抜けが起きにくい |
一方で、気を付ける点もあります。
- 道具ごとに書き方が違い、覚えるのに時間がかかる
- 設定ファイルの内容が自動で反映されるため、書き間違えると、意図しない変更や削除が起こりうる
2つ目は、IaC の道具を使ううえで特に大事な点です。この連載で使う道具には、実行する前に「何が変わるか」を確かめる仕組みがあり、その使い方も回を追って紹介します。
宣言型と命令型
IaC の書き方には、大きく2つの型があります。
| 型 | 書くもの | たとえ |
|---|---|---|
| 宣言型 | 「何を」：最後にどうなっていてほしいか | コース料理を注文し、作り方は料理人に任せる |
| 命令型 | 「どうやって」：そこに至る手順 | 手順書を見ながら、自分で1から料理を作る |
図1 宣言型と命令型
宣言型では、「VCN が1つあり、その中にサブネットが2つある」のように、最後の状態を書きます。今の状態と比べて何をすればよいかは、道具が判断します。命令型では、「VCN を作る」「次にサブネットを作る」のように、手順を順番に書きます。
どちらが優れているというより、向いている作業が違います。
- クラウドのリソース（ネットワークやサーバーそのもの）を作るには、宣言型の道具がよく使われます。代表例は Terraform や、AWS の CloudFormation です。
- サーバーの中の設定（ソフトウェアのインストールや設定ファイルの書き換え）には、Ansible などの道具がよく使われます。Ansible は手順を上から順に書く形で、命令型の例として紹介されることが多い道具です。ただし、1つ1つの手順は「この状態にする」という書き方で、宣言型の考え方も取り入れています。
この連載で使う道具
この連載では、役割の違う2つの道具を使います。
- Terraform：クラウドのリソースを作る（宣言型）
- Ansible：作ったサーバーの中を設定する
まずは土台となるクラウドのリソースを作るところから始めるので、最初に使うのは Terraform です。
次回
次回は、Terraform を使うと手作業と何が違うのかを、コードの形と基本の流れ（plan・apply・destroy）から見ていきます。