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