ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Provider block ကို `provider "aws" { region = "us-east-1" }` ဆိုတဲ့ ပုံစံနဲ့ configure လုပ်ပါတယ် — provider တစ်ခုစီက ကိုယ်ပိုင် authentication method ရှိပါတယ် (AWS ဆိုရင် access key/secret key, environment variable, ဒါမှမဟုတ် IAM role)။ Resource type name (`aws_instance`, `aws_s3_bucket`, `azurerm_virtual_machine`) က provider name ကို prefix အနေနဲ့ ပါဝင်ပါတယ် — provider documentation (Terraform Registry) ကနေ resource type တစ်ခုချင်းစီရဲ့ argument အားလုံးကို ရှာဖွေဖတ်ရှုနိုင်ပါတယ်။ Provider version ကို `required_providers` block ထဲမှာ ကန့်သတ်ထားသင့်ပါတယ် — version update ကြောင့် config ရုတ်တရက် break သွားတာမျိုး ကာကွယ်ဖို့ပါ.
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Terraform Registry (registry.terraform.io) ကို ဖွင့်ပြီး `aws_instance` resource ရဲ့ documentation ကို ရှာကြည့်ရင် argument အားလုံး (ami, instance_type, tags) ကို ဖတ်နိုင်ပါတယ် — resource အသစ်တစ်ခု သုံးချင်တိုင်း Registry ကို ကိုးကားပြီး argument list ကို ကြည့်ရသင့်ပါတယ်။ Provider version ကို `~> 5.0` လို့ ရေးရင် '5.x version ဖြစ်ရင် ဘယ် minor version မဆို ok' ဆိုတဲ့ ဆိုလိုတာပါ.
အတူတူ ကြည့်မယ်
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
tags = {
Name = "tutorial-web-server"
}
}$ terraform plan
+ resource "aws_instance" "web" {
+ ami = "ami-0abcdef1234567890"
+ instance_type = "t3.micro"
...
}
Plan: 1 to add, 0 to change, 0 to destroy.၅ မိနစ် စမ်းကြည့်
Terraform Registry website ကို ဖွင့်ပြီး `aws_s3_bucket` (ဒါမှမဟုတ် သင်ကြိုက်တဲ့ provider) ရဲ့ documentation ကို ရှာဖွေဖတ်ရှုကြည့်ပါ — required argument ဘယ်ဟာတွေလဲ မှတ်ချက်ရေးကြည့်ပါ။
သတိလေးတစ်ချက်
Resource type တစ်ခုစီရဲ့ argument (required vs optional) က provider version အလိုက် ပြောင်းလဲနိုင်ပါတယ် — Registry documentation ကို သင်သုံးနေတဲ့ provider version အတိအကျအတွက် ကိုးကားပါ။