IaCの原則として、”コードで作成したリソースはコードでのみ管理する”という鉄則がありますが、
それを無視するとどうなるかです。
検証してみる
Terraformで適当なリソースを立てます。下記のサンプル通りにEC2を立ててます。
https://www.terraform.io/docs/providers/aws/r/instance.html
次に作成したEC2のTagを適当に編集してみます。
次に先ほどterraformを実行した作業用端末からterraform applyしてみます。
$ terraform apply
data.aws_ami.ubuntu: Refreshing state...
aws_instance.web: Refreshing state... [id=i-0f4160053f3cf94fe]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# aws_instance.web will be updated in-place
~ resource "aws_instance" "web" {
ami = "ami-0cf54a87bffe628d2"
arn = "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxxxxxxxxxxx"
associate_public_ip_address = true
【中略】
~ tags = {
"Name" = "HelloWorld"
- "Name2" = "Testadded" -> null
}
tenancy = "default"
volume_tags = {}
【中略】
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
上記の通りコードに記載されていないtagを外そうとして”1 to change”と表示されます。
これを実際に実行してみてからマネジメントコンソール上から確認してみます。
マネジメントコンソール上からも手作業で足したtagが消えてしまっていることがわかります。
今回の場合はtagが変更されてしまっただけですが、
もしこれが新規に作成したSGを手動でアタッチされていた場合などは、SGが外れてしまい意図しない通信断の原因となりますので
コードで作成したコードは原則すべてコードで管理する必要があります。
※terraformはtfstateの内容を読み取って、
作成・削除したリソースに対して、実環境とのマッピングやメタデータを管理しているのでtfstateに基づく動作をする。
https://www.terraform.io/docs/state/purpose.html
例外を運用上で認めるとオライリーのIaC本で口が酸っぱくなるくらい言われているくらい
構成ドリフトやスノーフレークサーバの巣窟になり脆いインフラになるので絶対にやめましょう！