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日

*
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

Category: orchestration Tags: public

Upvote


Downvote