用我自己的方式输出学习Terraform两个月所掌握的内容(基础篇)
我将详细记录我在这大约两个月左右学到的内容(基础篇。由于篇幅较长,应用性的讨论将在下一次进行。)
然而,由于也包含了我个人的主观意见,所以如果有什么不对的地方,希望能给予指正,不胜感激。
另外,我只讲基本的内容(假设读者能稍微理解所写的内容。),所以不会涉及深入的讨论。如果你感兴趣的话,可以尝试阅读教科书(简单易懂,非常值得推荐)。
使用過的教科書
-
- pragmatic terraform on aws
実践Terraform
如果要购买的话,我推荐购买实践Terraform,它是Pragmatic terraform on AWS的增强版本(彩色打印)。
基础的谈话
关于词汇的命名
为了多次使用以下的词语, 在之前写下它们的意思。
-
- provider
使用するサービスのこと。 AWSやGCPなどを指す。
resource
EC2やECSなどユーザがコンソール上で操作できる要素を指す。
关于tfState文件
-
- terraformの構成を記述したファイル。 .terraform/にあります
- このファイルをもとにresourceの追加や削除が行われるため、基本的には触らないのがおすすめ。
关于要使用的命令
-
- terraform init
まずはじめに実行するであろうコマンド。
terraformで設定している内容(providerやbackendなどの設定)の初期化を行ってくれる。
ちなみにproviderやbackendを変更したときは必ず実行しないといけない
terraform plan
書いたterraformコードをもとに実行計画(providerでどう反映されるかをまとめたもの)が作られる。
実行計画の見方
+はresourceが追加される
-はresourceが削除される
-/+はresourceが再構築される(※この変更が一番危険なため、出てたら要注意)
反映自体はまだされないので、安心して実行しよう。
terraform apply
実際にproviderに反映する。
Terraform applyして初めて気づくエラーも多々ある(例: サブネットの競合など)
やるときは実行計画を入念に確認して実行しよう
terraform destory
terraformで構築した内容をすべて削除する
terraformで構築した箇所をprovider側で変更した場合、削除できなくなるので注意
关于在代码中写入的内容
-
- 基本的な構文
- 以下の通り。
定義する要素 "要素の名前(何でもOK)" {
オプション = "値"
}
-
- providerについて
terraformで使用するproviderを設定する。
provider "aws" {
region = "ap-northeast-1"
}
-
- backendについて
tfstateファイルをproviderのステート管理サービスに格納することができる
このメリットについてはリモートステートを参照。
terraform {
backend "s3" {
region = "ap-northeast-1"
bucket = "hoge-terraform"
key = "hoge-network.tfstate"
}
}
-
- resourceについて
EC2やECSなどユーザがコンソール上で操作できる要素を構成する。
主にresourceを記述して、設定を入力していく。
// サブネットを構成するresource
resource "aws_subnet" "hoge_subnet" {
count = 1
vpc_id = 'hogehoge'
availability_zone = 'hogehoge'
cidr_block = '10.12.111.111'
map_public_ip_on_launch = false
tags = {
Name = hoge_subnet
}
}
-
- dataについて
providerにある既存のリソースを取得できるブロック。
既存のリソースのidを参照して構築したい場合に使用する
data "terraform_remote_state" "データ名" {
backend = "s3"
config = {
region = "ap-northeast-1"
bucket = "hoge-hoge-terraform"
key = "hoge-vpc.tfstate"
}
}
-
- variableについて
terraformで設定できる変数。
実行時に変数の上書きが可能。(コマンド実行時に変数を設定して実行することができるため)
変数の実体はtfvarsで管理する(詳しくは応用的な話を参照)
たとえ自明であってもdescriptionはつけておくことをおすすめする。
変数がどの型で来るのかを明示的に表示させることも可能(バリデーションの役割にもなる)
型は以下の通り(あくまで一例。 詳しくはこちらを参照)
string
number
bool
List(Type)
variable "変数名" {
description = "設定する環境の接頭語"
type = string
}
-
- localについて
terraformで設定できる変数
variableとは違い、コマンド実行時に上書きできない変数。
locals {
hogehoge = "hoge"
}
-
- outputについて
resourceの実行結果を表示するブロック。
後述するmoduleの値から値を取得したいときに使用される
descriptionはつけておいたほうがいい(なんの値なのかを明示させるため)
output "hogehoge_subnet_id" {
description = "hogehoge用プライベートサブネットのid"
value = aws_subnet.hoge_private_subnet.id
}
-
- moduleについて
resource, dataなどの塊を再利用可能にさせるために使用する。
読み込むリソースのパス、 module内で使用されているvariableを設定し、構築できる
module "manage_public_subnet" {
source = "./hoge"
name = hoge
vpc_id = "hogehoge"
availability_zones = "hogehoge"
cidr_blocks = ["10.10.111.111", "10.10.111.112"]
gateway_id = "hogehoge"
destination_cidr_block = "10.11.111.111"
}
以上。下次会再写关于应用方面的话题。