19-2 訳す係と部品（provider・resource）

この節を一言で

設計図の先頭で訳す係を指名し、その下に部品を一つずつ書き、最初の一回だけ係を呼び寄せます。

図版を準備中設計図を受け取り Cloudflare の言葉に訳す係

訳す係が入ることで、設計図の文章が Cloudflare への注文になります。

図面は、読む相手が決まって初めて役に立ちます。日本語で書いた図面を海外の職人に渡すなら、間に訳す人が要ります。

いま読んでいるこのサイト（Cloudflare Lab）の設定を文章にするときも同じです。書いた文章を Cloudflare への注文に訳す係を、設計図の先頭で指名します。

ここでは、公式の手引きに沿って、書き出しから最初の部品までを順に見ます。

Learning goals

この節でできるようになること

• provider が何をする係かを説明できる
• required_providers に何を書くかを言える
• resource の三つの部分（種類・呼び名・中身）を説明できる
• terraform init が何をするかを言える

1. 訳す係を指名する

工事の前に、まず「誰に訳してもらうか」を決めます。これは図面の一番上に書きます。

Cloudflare では、この訳す係を provider と呼びます。公式の手引きでは、main.tf という名前のファイルを作り、その先頭の required_providers に、どの係をどの版で使うかを書きます。

次の文章は「Cloudflare の係を、版 5 系で使う」という指名です。読めなくても大丈夫です。

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5"
    }
  }
}

図版を準備中設計図と Cloudflare の間に立つ訳す係

どの訳す係をどの版で使うかを、設計図の先頭で指定します。

設計図と Cloudflare の間に係が一人立ちます。名前と版を先に決めておけば、後で読み返しても同じ結果です。

つまり、provider は設計図を Cloudflare の注文に訳す係の指名です。

2. 部品を一つ書く

設計図の本体は、部品の並びです。「ここに棚を一つ」「電話帳にこの行を一つ」と、部品ごとに区切って書きます。

Cloudflare では、この部品を resource と書きます。書き方は三つの部分でできています。部品の種類、設計図の中で呼ぶ名前、そして中身の項目です。

次の文章は、公式の例そのままで、「www という名前で、203.0.113.10 を指す電話帳の行を 1 つ作る」という部品です。種類が cloudflare_dns_record、呼び名が www です。

resource "cloudflare_dns_record" "www" {
  zone_id = "<YOUR_ZONE_ID>"
  name    = "www"
  content = "203.0.113.10"
  type    = "A"
  ttl     = 1
  proxied = true
  comment = "Domain verification record"
}

中身の項目は、第 3 章で画面から入力した欄と同じものです。

図版を準備中設計図に描かれた電話帳の一行という部品

部品は種類と呼び名を決め、中身の項目を並べて書きます。

部品 1 つが、電話帳の 1 行に対応します。画面の入力欄が、そのまま文章の行になった形です。

つまり、resource は「種類・呼び名・中身」で書く部品 1 つです。

3. 合鍵の渡し方

図面と職人がそろっても、店の鍵がなければ工事は始まりません。

Cloudflare では、第 10 章で作った合鍵（API token）を係に渡します。公式の手引きでは、provider のかたまりの中に api_token の欄を置き、そこに自分の合鍵を書きます。手引きは、この作業に必要な権限を持つ API Token を先に作っておくことを前提にしています。

provider "cloudflare" {
  api_token = "<YOUR_API_TOKEN>"
}

公式はここに強い注意書きを添えています。合鍵をうっかり外へ出さないため、このファイルを版の管理に保存しないこと。合鍵の安全な渡し方は次の手引きで扱う、とも書かれています。

なお公式の例では、電話帳や口座の番号は variable という差し替え可能な欄にまとめます。

4. 係を呼び寄せる

指名しただけでは、係はまだ作業場にいません。最初の一回だけ、呼び寄せる必要があります。

Cloudflare では、次の命令で Cloudflare の係を取り寄せます。読めなくても大丈夫です。

terraform init

実行すると、指名した版の係が手元に降りてきます。設計図を新しく作ったときと、係の指名を変えたときに行います。

図版を準備中訳す係が呼ばれて作業場に到着する場面

最初の一回だけ、指定した訳す係を取り寄せます。

呼ばれた係が作業場に到着します。ここまでで、図面・訳す係・鍵の三つがそろいます。

つまり、terraform init は指名した係を実際に手元へ取り寄せる命令です。

Cloudflare Lab での使われ方

ここで紹介した書き方が、いま読んでいる Cloudflare Lab でどう使われるかを見ます。

Cloudflare Lab では、設計図の 1 枚目に Cloudflare の係を指名し、第 3 章で画面から作った電話帳の行を最初の部品として書き起こす予定です。合鍵は設計図の中に直接書かない形にします。実測は実装後に追記します。

つまずきやすいところ

つまずきポイント

合鍵を書いたファイルを共有の置き場に上げないでください

公式は、合鍵をうっかり外へ出さないよう、このファイルを版の管理に保存しないことと注意しています。

つまずきポイント

部品の呼び名と実際の名前は別物です

resource "cloudflare_dns_record" "www" の後ろの www は設計図の中の呼び名で、電話帳に載る名前は中身の name の欄です。

この節のまとめ

• provider は設計図を Cloudflare への注文に訳す係で、先頭で名前と版を指名します。
• resource は部品 1 つで、種類・呼び名・中身の三つで書きます。
• 合鍵は provider に渡し、そのファイルは版の管理に保存しません。

この節で出てきた言葉を、つながりの順に並べると次のようになります。

flowchart TD
  A["設計図のファイル<br/>main.tf"] --> B["係を指名する<br/>required_providers"]
  B --> C["訳す係<br/>provider"]
  C --> D["合鍵を渡す<br/>api_token"]
  D --> E["部品を書く<br/>resource"]
  E --> F["係を呼び寄せる<br/>terraform init"]

図のラベル: 設計図のファイル main.tf / 係を指名する required_providers / 訳す係 provider / 合鍵を渡す api_token / 部品を書く resource / 係を呼び寄せる terraform init

次の節では、書いた設計図と実物の差を確かめてから建てます。

この節のチェック

問 1公式の例で、required_providers の source に書く値はどれですか？

hashicorp/cloudflarecloudflare/cloudflarecloudflare/dnsterraform/cloudflare

問 2provider は何をする役割ですか？

設計図を Cloudflare への注文に訳す係設定を保存する置き場料金を計算する係画面の操作を記録する係

問 3公式の例 resource "cloudflare_dns_record" "www" のうち、後ろの www は何ですか？

電話帳に載る名前そのもの向き先の置き場設計図の中でこの部品を呼ぶ名前係の版

問 4合鍵を書いた設計図のファイルについて、公式はどう注意していますか？

毎回作り直すこと必ず暗号化して共有すること1 日で消すこと版の管理に保存しないこと

問 5terraform init は何をする命令ですか？

設定を Cloudflare へ反映する指名した Cloudflare の係を取り寄せる設定を消す料金を見積もる

採点する