Terraform and Environment Variables

As part of your application deployment process, Code Pipes lets you set values for both Terraform variables and environment variables:

Terraform variables define characteristics of the application you are deploying. Terraform variables are input variables for your Terraform script. They are covered more in depth here (https://www.terraform.io/docs/language/values/variables.html).
Environment variables define aspects of the environment into which you are deploying the application.

Terraform variables

A Code Pipes project includes a repo that contains the both application files and a Terraform (.tf) file that specifies how to deploy the application. Within the .tf file, you can expose some things as variables, so that they can be altered at the time of a Terraform APPLY. (If you weren’t using Code Pipes, you would pass the values of these variables to the terraform apply command via a config file or via command line switches.)

Within Code Pipes, when do you set the values of the Terraform variables?

You set these values when you create a project or create an environment.

In the API, the operations are:

POST Create a Project

POST Create an Environment

Hierarchy rules:

The general rule is that, as you go lower down a hierarchy, the value set at the lowest level is the one that applies to the deployment. This means that it overrides values that might have been set at higher levels.

For example, assume we start with a project that represents a repo. A project is relatively high on the hierarchy chain. Within your project, you can set a Terraform variable called VAR-A to 1.

Now suppose the project is a parent of an environment called ENV-A. If, within ENV-A, you set VAR-A to 2, then VAR-A will be set to 2 when the deployment is complete.

When does Code Pipes run the Terraform code, and replace its variables with your values?

Code Pipes does a Terraform APPLY on the .tf file when it does a POST of the type:

/…/envs/:envID/jobs

Examples include:

POST Start a Plan Validation

POST Start an Apply

Terraform example use case

Say you are developing Terraform code (a .tf file) that you plan to use in dev, test and prod environments. Let’s say the TF code spins up some VMs. You would like the VMs to be sized differently for each environment.

To do this you define a variable called, say, vm_size in your TF code. When you spin up the VMs, instead of hard coding the size of the VM, you use the vm_size variable.

Now, when you define these 3 environments via the Code Pipes POST Create Environment API, you add vm_size as a Terraform variable and specify a different size value for each environment.

Environment variables

You can set environment variables in two places to control two different things:

You can set them when you create an environment via POST Create Environment. These variables control environmental infrastructure elements such as an environment’s region:
```
"type": "env_var",
"key": "AWS_DEFAULT_REGION",
"value": "us-east-1",
"sensitive": false
```
You can set them within your application code to control things such as how your application behaves within different environments.

For example, you could create a LOG_LEVEL environment variable to set more verbose logging in a development environment, and less verbose logging in a production environment.

Within Code Pipes, you set this type of application environment variable within the request body, when you create an application via POST Create Application:
```
"appConfig": {
  "language": "source_go",
  "version": "1.13",
  "vars": {
  "LOG_LEVEL": "INFO"
}
```

API notes

Variable syntax:

When setting variables (for example, in POST Create a Project or POST Create an Environment), you pass in the variables as an array in the request body.

For each variable, you need to specify whether the variable is a Terraform variable or an environment variable. You do this via the type keyword.

Terraform variable: set type to tf_var.
Environment variable: set type to env_var

For example:

"variables": [
    {
        "type": tf_var,
        "key": "orgname",
        "value": "Ollion",
        "sensitive": false
    },
    {
        "type": tf_var,
        "key": "what_to_say",
        "value": "Hi Tom",
        "sensitive": false
    },
    {
    "type": env_var,
    "key": "AWS_DEFAULT_REGION",
    "value": "us-east-1",
    "sensitive": false
    }
]

"Sensitive" or "masked" variables

When you create a variable within Code Pipes, you can set it to be "sensitive" (in the API and CLI) or "masked" (in the UI). For example, you might want to set a password to sensitve/masked.

Both "sensitive" and "masked" mean the same thing, which is:

Once you set a value for this variable, you can never see this value again. Code Pipes encrypts it, and the Code Pipes workflows (or "pipelines") decrypt it when they need to use it.
Although no one can see this value again, you can reset it to a different value whenever you want.