Terraform Cloud Settings

 Terraform CLI can integrate with Terraform Cloud, acting as a client for Terraform Cloud's CLI-driven run workflow.

You must configure the following settings to use Terraform Cloud for a particular working directory:

  • Provide credentials to access Terraform Cloud, preferably by using the terraform login command.
  • Add a cloud block to the directory's Terraform configuration, to specify which organization and workspace(s) to use.
  • Optionally, use a .terraformignore file to specify files that shouldn't be uploaded with the Terraform configuration when running plans and applies.

After adding or changing a cloud block, you must run terraform init.

The cloud Block

The cloud block is a nested block within the top-level terraform settings block. It specifies which Terraform Cloud workspaces to use for the current working directory.

terraform {
  cloud {
    organization = "my-org"
    hostname = "app.terraform.io" # Optional; defaults to app.terraform.io

    workspaces {
      project = "networking-development"
      tags = ["networking", "source:cli"]
    }
  }
}

The cloud block also has some special restrictions:

  • A configuration can only provide one cloud block.
  • A cloud block cannot be used with state backends. A configuration can use one or the other, but not both.
  • A cloud block cannot refer to named values (like input variables, locals, or data source attributes).

The cloud block only affects Terraform CLI's behavior. When Terraform Cloud uses a configuration that contains a cloud block - for example, when a workspace is configured to use a VCS provider directly - it ignores the block and behaves according to its own workspace settings.

Arguments

The cloud block supports the following configuration arguments:

  • organization - (Required) The name of the organization containing the workspace(s) the current configuration should use.

  • workspaces - (Required) A nested block that specifies which remote Terraform Cloud workspaces to use for the current configuration. The workspaces block must contain exactly one of the following arguments, each denoting a strategy for how workspaces should be mapped:

    • tags - (Optional) A set of Terraform Cloud workspace tags. You will be able to use this working directory with any workspaces that have all of the specified tags, and can use the terraform workspace commands to switch between them or create new workspaces. New workspaces will automatically have the specified tags. This option conflicts with name.

    • name - (Optional) The name of a single Terraform Cloud workspace. You will only be able to use the workspace specified in the configuration with this working directory, and cannot manage workspaces from the CLI (e.g. terraform workspace select or terraform workspace new). This option conflicts with tags.

    • project - (Optional) The name of a Terraform Cloud project. Workspaces that need creating will be created within this project. terraform workspace list will be filtered by workspaces in the supplied project.

  • hostname - (Optional) The hostname of a Terraform Enterprise installation, if using Terraform Enterprise. Defaults to Terraform Cloud (app.terraform.io).

  • token - (Optional) The token used to authenticate with Terraform Cloud. We recommend omitting the token from the configuration, and instead using terraform login or manually configuring credentials in the CLI config file.

Environment Variables

Note: CLI integration environment variables are supported in Terraform v1.2.0 and later.

You can use environment variables to configure one or more cloud block attributes. This is helpful when you want to configure Terraform as part of a Continuous Integration (CI) pipeline. Terraform only reads these variables if the corresponding attribute is omitted from your configuration file. If you choose to configure the cloud block entirely through environment variables, you must still add an empty cloud block in your configuration file.

Warning: Remote execution with non-interactive workflows requires auto-approved deployments. Minimize risk of unpredictable infrastructure changes and configuration drift by making sure that no one can change your infrastructure outside of your automated build pipeline. Refer to Non-Interactive Workflows for details.

Use the following environment variables to configure the cloud block:

  • TF_CLOUD_ORGANIZATION - The name of the organization. Terraform reads this variable when organization omitted from the cloud block`. If both are specified, the configuration takes precedence.

  • TF_CLOUD_HOSTNAME - The hostname of a Terraform Enterprise installation. Terraform reads this when hostname is omitted from the cloud block. If both are specified, the configuration takes precedence.

  • TF_CLOUD_PROJECT - The name of a Terraform Cloud project. Terraform reads this when workspaces.project is omitted from the cloud block. If both are specified, the cloud block configuration takes precedence.

  • TF_WORKSPACE - The name of a single Terraform Cloud workspace. Terraform reads this when workspaces is omitted from the cloud block. Terraform Cloud will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set TF_WORKSPACE if the cloud block uses tags. However, the value of TF_WORKSPACE must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to TF_WORKSPACE for details.

Excluding Files from Upload with .terraformignore

When executing a remote plan or apply in a CLI-driven run, a copy of your configuration directory is uploaded to Terraform Cloud. You can define paths to exclude from upload by adding a .terraformignore file at the root of your configuration directory. If this file is not present, the upload will exclude the following by default:

The rules in .terraformignore file resemble the rules allowed in a .gitignore file:

  • Comments (starting with #) or blank lines are ignored.
  • End a pattern with a forward slash / to specify a directory.
  • Negate a pattern by starting it with an exclamation point !. When ignoring large directories, negation patterns can impact performance. Place negation rules as early as possible within .terraformignore or avoid using them if possible.

Comments

Post a Comment

Popular posts from this blog

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more