Managing Applications and Infrastructure with Terraform-Deploying Infrastructure with Terraform-(1)Terraform Basics and a Docker Deployment-(14)Breaking Out Our Variable Definitions
2018年10月04日
Terraform automatically loads a number of variable definitions files if they are present in files named exactly terraform.tfvars or terraform.tfvars.json.
~/docker# vim terraform.tfvars
~/docker# vim variables.tf
~/docker# terraform plan
References
Variable Definition Precedence
*
Managing Applications and Infrastructure with Terraform-Deploying Infrastructure with Terraform
1. Terraform Basics and a Docker Deployment
14. Breaking Out Our Variable Definitions
~/docker# terraform workspace select default
Switched to workspace "default".
Terraform automatically loads a number of variable definitions files if they are present in files named exactly terraform.tfvars or terraform.tfvars.json.
~/docker# vim terraform.tfvars
image = { dev = "ghost:latest" prod = "ghost:alpine" } container_name = { dev = "dev_blog" prod = "prod_blog" } int_port = { dev = "2368" prod = "2368" } ext_port = { dev = "8080" prod = "80" }
~/docker# vim variables.tf
variable "env" { description = "env: dev or prod" } variable "image" { description = "image for container" type = map } variable "container_name" { description = "Name of Container" type = map } variable "int_port" { description = "Internal port for container" type = map } variable "ext_port" { description = "External port for container" type = map }
~/docker# terraform plan
var.env env: dev or prod Enter a value: dev Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # module.container.docker_container.container_id will be created + resource "docker_container" "container_id" { + attach = false + bridge = (known after apply) + command = (known after apply) + container_logs = (known after apply) + dns = (known after apply) + dns_opts = (known after apply) + entrypoint = (known after apply) + exit_code = (known after apply) + gateway = (known after apply) + hostname = (known after apply) + id = (known after apply) + image = (known after apply) + ip_address = (known after apply) + ip_prefix_length = (known after apply) + ipc_mode = (known after apply) + log_driver = (known after apply) + log_opts = (known after apply) + logs = false + must_run = true + name = "dev_blog" + network_data = (known after apply) + read_only = false + restart = "no" + rm = false + shm_size = (known after apply) + start = true + user = (known after apply) + working_dir = (known after apply) + ports { + external = 8080 + internal = 2368 + ip = "0.0.0.0" + protocol = "tcp" } } # module.image.docker_image.image_id will be created + resource "docker_image" "image_id" { + id = (known after apply) + latest = (known after apply) + name = "ghost:latest" } Plan: 2 to add, 0 to change, 0 to destroy. Changes to Outputs: + IP_Address = (known after apply) + container_name = "dev_blog" ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.
References
Variable Definition Precedence