diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json deleted file mode 100644 index f634bb2a1a..0000000000 --- a/website/data/docs-nav-data.json +++ /dev/null @@ -1,17 +0,0 @@ -[ - { "title": "Intro to Terraform", "href": "/intro" }, - { "title": "Configuration Language", "href": "/language" }, - { "title": "Terraform CLI", "href": "/cli" }, - { "title": "Terraform Cloud", "href": "/cloud-docs" }, - { "title": "Terraform Enterprise", "href": "/enterprise" }, - { "title": "Provider Use", "href": "/language/providers" }, - { "title": "Plugin Development", "href": "/plugin" }, - { "title": "Registry Publishing", "href": "/registry" }, - { - "title": "Integration Program", - "path": "partnerships" - }, - { "title": "Terraform Tools", "path": "terraform-tools" }, - { "title": "CDK for Terraform", "href": "/cdktf" }, - { "title": "Glossary", "path": "glossary" } -] diff --git a/website/docs/docs/glossary.mdx b/website/docs/docs/glossary.mdx deleted file mode 100644 index 444b42faab..0000000000 --- a/website/docs/docs/glossary.mdx +++ /dev/null @@ -1,1028 +0,0 @@ ---- -page_title: Terraform Glossary -description: >- - Definitions for technical terms related to Terraform core, Terraform CLI, - Terraform Cloud, and Terraform Enterprise. ---- - -# Glossary - -This page collects brief definitions of some of the technical terms used in the documentation for Terraform, as well as some terms that come up frequently in conversations throughout the Terraform community. - -
- -- [API](#api) -- [Apply (noun)](#apply-noun) -- [Apply (verb)](#apply-verb) -- [Argument](#argument) -- [Attribute](#attribute) -- [Backend](#backend) -- [Blob Storage](#blob-storage) -- [Block](#block) -- [Branch](#branch) -- [CI/CD](#ci-cd) -- [CLI](#cli) -- [Commit](#commit) -- [(Terraform) Configuration](#terraform-configuration) -- [Configuration Version](#configuration-version) -- [Cost Estimation](#cost-estimation) -- [Data Source](#data-source) -- [Deposed](#deposed) -- [Expression](#expression) -- [Fork](#fork) -- [Git](#git) -- [HCL](#hcl) -- [ID](#id) -- [Infrastructure as Code](#infrastructure-as-code) -- [Ingress](#ingress) -- [Input Variables](#input-variables) -- [Interpolation](#interpolation) -- [JSON](#json) -- [Locking](#locking) -- [Log](#log) -- [Module](#module) -- [OAuth](#oauth) -- [OAuth Client](#oauth-client) -- [OAuth Token](#oauth-token) -- [Organization](#organization) -- [Output Values](#output-values) -- [OSS](#oss) -- [Permissions](#permissions) -- [Plan (verb)](#plan-verb) -- [Plan (noun, 1)](#plan-noun-1) -- [Plan File](#plan-file) -- [Policy](#policy) -- [Policy Check](#policy-check) -- [Policy Set](#policy-set) -- [Private Terraform Registry](#private-terraform-registry) -- [Private Terraform Enterprise (PTFE)](#private-terraform-enterprise-ptfe) -- [(Terraform) Provider](#terraform-provider) -- [Pull Request (PR)](#pull-request-pr) -- [Queue](#queue) -- [(Terraform) Registry](#terraform-registry) -- [Remote Operations](#remote-operations) -- [Remote Backend](#remote-backend) -- [Repository](#repository) -- [Resource](#resource) -- [Root Module](#root-module) -- [Root Outputs](#root-outputs) -- [Run](#run) -- [Run Triggers](#run-triggers) -- [S3](#s3) -- [SAML](#saml) -- [Sentinel](#sentinel) -- [Site Admin](#site-admin) -- [Speculative Plan](#speculative-plan) -- [SSH Key](#ssh-key) -- [State](#state) -- [State Version](#state-version) -- [Team](#team) -- [Terraform](#terraform) -- [Terraform Cloud](#terraform-cloud) -- [Terraform Enterprise](#terraform-enterprise) -- [Terraform Version](#terraform-version) -- [TFE](#tfe) -- [TFE Provider / Terraform Cloud Provider](#tfe-provider-terraform-cloud-provider) -- [(API) Token](#api-token) -- [Trigger](#trigger) -- [Variables](#variables) -- [VCS](#vcs) -- [VCS Provider](#vcs-provider) -- [Webhook](#webhook) -- [Working Directory](#working-directory) -- [Workspace](#workspace) - -
- -## API - -[api]: /docs/glossary#api -[apis]: /docs/glossary#api - -Acronym for "Application Programming Interface". Any interface designed to allow programmatic manipulation of some kind of software system. For most software developers today, the most common kinds of APIs are based on HTTP requests. - -Terraform relies on cloud service provider APIs to manage resources; each service's Terraform provider is responsible for mapping Terraform's resource model to the series of actual API calls necessary to create, check, modify, or delete a real infrastructure resource in that cloud service. - -Terraform Cloud also offers its own API, for managing resources like team membership, policies, and workspaces. That API, in turn, is used by the `tfe` Terraform provider, so you can use Terraform to manage the system that runs Terraform for you. - -- [Terraform Cloud docs: API](/cloud-docs/api-docs) -- [Terraform providers: `tfe`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) - -## Apply (noun) - -[apply]: /docs/glossary#apply-noun- -[applies]: /docs/glossary#apply-noun- - -One of the stages of a [run][], in which changes are made to real infrastructure resources in order to make them match their desired state. The counterpart of a [plan][]. - -In Terraform's CLI, applies are performed with the `terraform apply` command. Terraform Cloud runs `terraform apply` using a [plan file][] as its input. - -- [Terraform docs: The `terraform apply` command](/cli/commands/apply) -- [Terraform Cloud docs: About Runs](/cloud-docs/run) - -## Apply (verb) - -[apply-v]: /docs/glossary#apply-verb- - -To make changes to real infrastructure in order to make it match the desired state (as specified by a Terraform [config][] and set of [variables][]). - -In conversation, it's common to refer to "applying a [plan][]" (usually in the context of Terraform Cloud's workflow) or "applying a [configuration][]" (usually in the context of the Terraform CLI workflow). - -- [Terraform docs: The `terraform apply` command](/cli/commands/apply) -- [Terraform Cloud docs: About Runs](/cloud-docs/run) - -## Argument - -[argument]: /docs/glossary#argument -[arguments]: /docs/glossary#argument - -In Terraform's [configuration][] language: a syntax construct that assigns a value to a name. Arguments have the form ` = `, and they appear within blocks. - -Most of a Terraform configuration consists of using arguments to configure Terraform [resources][]. Each resource type defines the arguments its resources can use, the allowed values for each argument, and which arguments are required or optional. Information about a given resource type can be found in the docs for that resource's [provider][]. - -- [Terraform Language docs: Syntax — Arguments and Blocks](/language/syntax/configuration#arguments-and-blocks) - -## Attribute - -[attribute]: /docs/glossary#attribute -[attributes]: /docs/glossary#attribute - -In Terraform's [configuration][] language: a named piece of data that belongs to some kind of object. The value of an attribute can be referenced in [expressions][] using a dot-separated notation, like `aws_instance.example.id`. - -Terraform [resources][] and [data sources][] make all of their [arguments][] available as readable attributes, and also typically export additional read-only attributes. - -- [Terraform docs: Expressions — Indices and Attributes](/configuration/expressions#indices-and-attributes) - -## Backend - -[backend]: /docs/glossary#backend -[backends]: /docs/glossary#backend - -The part of Terraform's core that determines how Terraform stores [state][] and performs [operations][remote operations] (like [plan][], [apply][], import, etc.). Terraform has multiple backends to choose from, which can be configured in a variety of ways. Backends are not plugins, so it is not possible to install additional backends. - -In a general computer science sense, a backend is any lower-level implementation that enables a higher-level feature. But in the context of Terraform, "backend" always means the built-in code that handles state and operations. - -- [Terraform docs: Backends](/language/settings/backends) - -## Blob Storage - -[blob storage]: /docs/glossary#blob-storage - --> Terraform Cloud - -An API service for storing and retrieving arbitrary chunks of data using opaque addresses, which are indexed by a directory of some kind. The most notable example is AWS's [S3][]. - -You do not need to be familiar with the properties and advantages of blob storage services in order to work with Terraform or Terraform Cloud. However, you might need to administer or configure a blob storage service if you are responsible for administering a [Terraform Enterprise][] instance. - -## Block - -[block]: /docs/glossary#block -[blocks]: /docs/glossary#block - -In Terraform's [configuration][] language: a container for other content which usually represents the configuration of some kind of object, like a [resource][]. Blocks have a _block type,_ can have zero or more _labels,_ and have a _body_ that contains any number of [arguments][] and nested blocks. Most of Terraform's features are controlled by top-level blocks in a configuration file. - -```hcl -resource "aws_vpc" "main" { - cidr_block = var.base_cidr_block -} - - "" "" { - # Block body - = # Argument -} -``` - -- [Terraform Language docs: Syntax — Arguments and Blocks](/language/syntax/configuration#arguments-and-blocks) - -## Branch - -[branch]: /docs/glossary#branch -[branches]: /docs/glossary#branch - -In some [version control systems][vcs]: a semi-independent history of changes to content in a repository. A branch generally shares some history with other branches in the same repository, but eventually diverges to include changes that aren't yet present elsewhere. - -A repository usually has a default branch (whose name, in [Git][], defaults to `master`), which successful changes are eventually merged into. Most modern development workflows also include topic branches (where a specific set of changes is explored, iterated on, and verified), and some workflows include long-lived branches other than the default branch. - -## CI/CD - -[ci-cd]: /docs/glossary#ci-cd - -CI/CD (Continuous Integration/Continuous Delivery) platforms perform pre-defined tasks (like tests or builds) in response to trigger events (like new commits in a project). This helps make new releases more automated, predictable, and understandable. Infrastructure management, typically handled by operations teams, can also fit into an automated release workflow using infrastructure as code with Terraform. - -## CLI - -[cli]: /docs/glossary#cli - -Command-line interface. The `terraform` command expects to be run in a CLI (a Unix shell or the Windows command prompt), which it uses to accept instructions and return text output. - -We often use "Terraform CLI" to refer to the core open source Terraform binary when we need to distinguish it from other parts of the Terraform ecosystem (like Terraform Cloud or the Terraform GitHub Actions). - -- [Wikipedia: Command-line Interface](https://en.wikipedia.org/wiki/Command-line_interface) -- [Terraform docs: Commands (CLI)](/cli/commands) - -## Commit - -[commit]: /docs/glossary#commit -[commits]: /docs/glossary#commit - -In a [version control system][vcs]: A coherent set of changes saved to a repository's version history. - -In Git, commits act like a complete snapshot of the contents of a repo, on a specific [branch][] (or group of branches with shared history) and at a specific moment in time. Each commit also records the identity of its parent(s), which enables viewing the entire history of the repo up to any specific moment. Additionally, comparing a commit to its parent(s) can reveal the exact changes introduced by that commit; if those changes are applied as a diff, they can be added to a different branch in the repo without merging in the entire history of the commit in question. - -## (Terraform) Configuration - -[configuration]: /docs/glossary#terraform-configuration -[configurations]: /docs/glossary#terraform-configuration -[config]: /docs/glossary#terraform-configuration -[configs]: /docs/glossary#terraform-configuration - -Also "config". - -Code written in [Terraform's configuration language][hcl] that declaratively describes the desired state of your infrastructure. A complete config consists of a [root module][], which can optionally call any number of child [modules][]. - -- [Terraform docs: Configuration Language](/language) -- [Introduction to Terraform](/intro) - -## Configuration Version - -[configuration version]: /docs/glossary#configuration-version -[configuration versions]: /docs/glossary#configuration-version -[config version]: /docs/glossary#configuration-version -[config versions]: /docs/glossary#configuration-version - --> Terraform Cloud - -Also "config version". - -The contents of a Terraform [config][] at a specific moment in time. This concept only applies to Terraform Cloud, since the Terraform CLI doesn't have visibility into repeated runs for a specific configuration over a period of time. - -Every stage of a given run uses one specific configuration version. - -Config versions can be automatically imported when new commits are merged to a workspace's repo, uploaded via the API, or uploaded by running `terraform plan` or `terraform apply` as a [remote operation][]. Adding a new config version is sometimes called "[ingressing][ingress]." - -## Cost Estimation - -[cost estimation]: /docs/glossary#cost-estimation -[cost estimations]: /docs/glossary#cost-estimation - --> Terraform Cloud - -Part of a [run][]. After gathering the [plan file][] for a run, Terraform Cloud uses plan data to estimate costs for each resource found in the [plan][]. Previous and proposed resources are given estimated costs, providing an estimated delta cost between the two. The results can be used in [Sentinel policies][]. - -- [Terraform Cloud docs: Run States and Stages](/cloud-docs/run/states) - -## Data Source - -[data source]: /docs/glossary#data-source -[data sources]: /docs/glossary#data-source - -A [resource][]-like object that can be configured in Terraform's [configuration][] language. - -Unlike resources, data sources do not create or manage infrastructure. Instead, they return information about some kind of external object in the form of readable [attributes][]. This allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration. - -Data sources are implemented by [providers][]. - -- [Terraform docs: Data Sources](/language/data-sources) - -## Deposed - -[deposed]: /docs/glossary#deposed -[deposed resource]: /docs/glossary#deposed -[deposed resources]: /docs/glossary#deposed - -This status tracks a [resource][] that was marked for deletion, but still remains in the Terraform [state][] and infrastructure due an error from a previous [apply][]. Terraform expected to replace the existing resource by creating a new resource, then destroying the existing resource, but an error occurred in the apply before the destruction. Existing references to the resource refer to the new resource. Terraform will destroy the `deposed` resource on the next apply. This only can occur in resource [configurations][] that have the `lifecycle` configuration block `create_before_destroy` [argument][] set to `true`. - -- [Terraform docs: Resources](/configuration/resources) - -## Expression - -[expression]: /docs/glossary#expression -[expressions]: /docs/glossary#expression - -In Terraform's [configuration][] language: a piece of syntax that represents a value, either literally or by referencing and combining other values. Expressions appear as values for [arguments][], or within other expressions. - -Prior to Terraform 0.12, \[interpolation]\[] was the only way to use non-literal expressions in Terraform configurations; in 0.12 and later, expressions can be used independently. - -- [Terraform docs: Expressions](/configuration/expressions) - -## Fork - -[fork]: /docs/glossary#fork -[forks]: /docs/glossary#fork -[forked]: /docs/glossary#fork - -Also "forked repository" or "forked repo". - -A [VCS][] [repository][] that was created by copying content and history from another repository. - -Different VCS providers handle forks differently, but a fork is usually owned by a different person or organization than the original repo, and a fork usually does not inherit all of the original repo's access permissions. - -Terraform Cloud makes extensive use of VCS repos, and assumes that forks of a trusted repo are not necessarily trusted. As such, Terraform Cloud avoids evaluating any code from external forks, which prevents Terraform Cloud from running [speculative plans][] for [pull requests][] from forks. - -On [Terraform Enterprise][], [speculative plans][] on [pull requests][] from forks can be enabled by an administrator. - -## Git - -[git]: /docs/glossary#git - -A distributed [version control system][vcs] for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. - -- [Wikipedia: Git](https://en.wikipedia.org/wiki/Git) - -## HCL - -[hcl]: /docs/glossary#hcl - -HashiCorp Configuration Language. The structured configuration syntax that serves as the basis for Terraform's [configuration][] language, as well as the configuration layer for several other HashiCorp products. - -HCL establishes the syntax Terraform uses for things like [arguments][], [blocks][], literal values, and [expressions][]. But what most people think of as the Terraform language extends beyond just the syntax; the built-in functions, Terraform-specific block types (like `resource` and `variable`), and Terraform-specific named values available in expressions are all implementation details of Terraform itself. - -- [GitHub: HCL](https://github.com/hashicorp/hcl) -- [Terraform docs: Configuration Language](/language) - -## ID - -[id]: /docs/glossary#id -[ids]: /docs/glossary#id - -An identifier; an opaque string permanently associated with a specific object, which doesn't contain any information about the object but which can be used to retrieve information about it or perform actions on it via an [API][]. - -In Terraform, many [resource][] types have an ID [attribute][] that helps link Terraform's [state][] to the real infrastructure resource being managed. - -In Terraform Cloud, most internal application objects (like [workspaces][], users, [policies][], etc.) can be identified by both a name and by an opaque, permanent ID. Most API endpoints use IDs instead of names, since names sometimes change. IDs for Terraform Cloud's application objects are sometimes called "external IDs." - -You can usually copy an external ID from the URL bar when viewing an object in Terraform Cloud's UI. Workspaces don't display an ID in the URL bar, but their general settings page includes a UI control for viewing and copying the ID. - -## Infrastructure as Code - -[infrastructure-as-code]: /docs/glossary#infrastructure-as-code - -Infrastructure-as-Code (IaC) is the practice of managing infrastructure in a file or files rather than manually configuring it via a user interface. Infrastructure resource types managed with IaC can include virtual machines, security groups, network interfaces, and many others. - -## Ingress - -[ingress]: /docs/glossary#ingress -[ingressing]: /docs/glossary#ingress - --> Terraform Cloud - -The process of bringing content into Terraform Cloud. Usually that content is a [configuration version][], but it can also be a [private module][] version or some other kind of content. - -This term comes from Terraform Cloud's internal subsystems. Most documentation and UI avoids using "ingress," but it can sometimes appear in API contexts or support conversations. - -## Input Variables - -See [Variables][]. - -## Interpolation - -Using a special placeholder to insert a computed value into a string. - -[Terraform's configuration language][hcl] supports interpolation in strings using `${}` placeholders. For example: - -```hcl -"Hello, ${var.name}!" -``` - -Prior to Terraform 0.12, interpolation was the only way to use non-literal [expressions][] in Terraform configurations; in 0.12 and later, expressions can be used independently. - -Interpolation is a very common feature in programming languages; for example, Ruby uses `#{}` placeholders in double-quoted strings, and JavaScript (ES6 and up) uses `${}` placeholders in backtick-quoted strings. - -- [Terraform docs: Expressions - String Templates](/configuration/expressions#string-templates) - -## JSON - -[json]: /docs/glossary#json - -Acronym for "JavaScript Object Notation". A popular text-based data interchange format, which can represent strings, numbers, booleans, null, arrays, and objects/maps. - -Terraform and Terraform Cloud often interact with JSON data in order to consume or provide APIs. Terraform also supports JSON as an alternate format for [configurations][]. - -- [Wikipedia: JSON](https://en.wikipedia.org/wiki/Json) -- [Terraform docs: JSON Configuration Syntax](/language/syntax/json) - -## Locking - -[locking]: /docs/glossary#locking -[lock]: /docs/glossary#locking - --> Terraform Cloud - -The ability to prevent new [runs][] from starting in a given [workspace][]. Workspaces are automatically locked while a run is in progress, and can also be manually locked. - -The [`remote` backend][remote backend] respects the lock status in Terraform Cloud workspaces. Some other Terraform [backends][] can also lock state during runs. - -## Log - -[log]: /docs/glossary#log -[logs]: /docs/glossary#log - -The text-based output of actions taken within a [run][]. For example, the output of running `terraform plan`. - -## Module - -[module]: /docs/glossary#module -[modules]: /docs/glossary#module - -Also "Terraform module". - -A self-contained collection of Terraform [configurations][] that manages a collection of related infrastructure resources. - -Other Terraform configurations can _call_ a module, which tells Terraform to manage any resources described by that module. - -Modules define [input variables][] (which the calling module can set values for) and [output values][] (which the calling module can reference in [expressions][]). - -- [Terraform docs: Modules](/language/modules/develop) - -## OAuth - -[oauth]: /docs/glossary#oauth - -An open standard for token-based authorization between applications on the internet. - -Terraform Cloud uses OAuth to connect your organization to your [VCS provider][]. Generally takes an `id` and `secret` from your VCS provider to give access to Terraform Cloud and allow it to pull in configuration from the provider. - -- [Terraform Cloud docs: VCS Integration](/cloud-docs/vcs) - -## OAuth Client - -[oauth client]: /docs/glossary#oauth-client -[oauth clients]: /docs/glossary#oauth-client - --> Terraform Cloud - -An entity collecting the configuration information that a Terraform Cloud organization needs in order to connect to a specific [VCS provider][]. - -An OAuth client needs an [OAuth token][] in order to actually access data belonging to a user or organization in that VCS provider. The client can be created with an existing token for that VCS provider (API-only, and not supported for some VCS providers), or it can be created with the details Terraform Cloud needs in order to request a token. Requesting a token requires a user to click through and approve access with their VCS provider account. - -- [Terraform Cloud docs: VCS Integration](/cloud-docs/vcs) -- [Terraform Cloud API docs: OAuth Clients](/cloud-docs/api-docs/oauth-clients) - -## OAuth Token - -[oauth token]: /docs/glossary#oauth-token -[oauth tokens]: /docs/glossary#oauth-token - --> Terraform Cloud - -**In general:** A secret string that allows an application to authenticate itself to another application. The token is generated ahead of time by the application being accessed (either during the OAuth authorization exchange or in response to a direct request by a user), and allows access with whatever permissions that application assigns to the token. The [VCS providers][] supported by Terraform Cloud allow access via OAuth tokens; that access is generally restricted to data belonging to a given user or organization within that provider. - -**Within Terraform Cloud:** An entity in the Terraform Cloud application that associates an OAuth token (in the "secret string" sense) with a permanent ID and with metadata about which VCS provider it applies to and which VCS user approved the token. When documentation refers specifically to this kind of entity, the name is often styled as `oauth-token` to indicate that it's an entity you can interact with via the [API][]. - -An `oauth-token` has a one-to-one relationship with an [OAuth client][], but the client can outlive a specific token, to allow revoking and re-requesting VCS access. - -[Workspaces][] that are linked to a VCS [repo][] have a relationship with one `oauth-token`. - -- [Terraform Cloud docs: VCS Integration](/cloud-docs/vcs) -- [Terraform Cloud API docs: OAuth Tokens](/cloud-docs/api-docs/oauth-tokens) - -## Organization - -[organization]: /docs/glossary#organization -[organizations]: /docs/glossary#organization - --> Terraform Cloud - -Terraform Cloud's fundamental unit for controlling access and grouping things together; meant to represent a company or a business unit within a company. An organization contains a group of [workspaces][], a group of [teams][], a group of [Sentinel policies][], and a variety of settings. Adding users to an organization is done via teams. - -- [Terraform Cloud docs: Organizations](/cloud-docs/users-teams-organizations/organizations) - -## Output Values - -[output value]: /docs/glossary#output-values -[output values]: /docs/glossary#output-values -[output]: /docs/glossary#output-values -[outputs]: /docs/glossary#output-values - -Also "outputs". - -Data exported by a Terraform [module][], which can be displayed to a user and/or programmatically used by other Terraform code. - -## OSS - -[oss]: /docs/glossary#oss - -Acronym for "Open-Source Software". Terraform and the publicly available Terraform providers are open-source. Terraform Cloud and Terraform Enterprise are closed-source commercial software, but they make use of Terraform and the available Terraform providers. - -- [Wikipedia: Open-Source Software](https://en.wikipedia.org/wiki/Open-source_software) - -## Permissions - -[permission]: /docs/glossary#permissions -[permissions]: /docs/glossary#permissions - --> Terraform Cloud - -Specific levels of access allowed within Terraform Cloud. Can be managed at the [workspace][] and/or [organization][] level. For example, a user with "read" permissions for a workspace can see a list of runs but cannot approve a run like a user with "write" permissions can. - -- [Terraform Cloud docs: Permissions](/cloud-docs/users-teams-organizations/permissions) - -## Plan (verb) - -[plan-v]: /docs/glossary#plan-verb- - -Also "queue plan". - -To start a new [run][], which begins by running a Terraform [plan (noun)][plan]. - -- [Terraform Cloud docs: About Runs](/cloud-docs/run) - -## Plan (noun, 1) - -[plan]: /docs/glossary#plan-noun-1- -[plans]: /docs/glossary#plan-noun-1- - -One of the stages of a [run][], in which Terraform compares the managed infrastructure's real state to the [configuration][] and [variables][], determines which changes are necessary to make the real state match the desired state, and presents a human-readable summary to the user. The counterpart of an [apply][]. - -In Terraform's CLI, plans are performed by all of the following commands: - -- `terraform plan`, which only performs a plan. It can optionally output a [plan file][], which `terraform apply` can use to perform that exact set of planned changes. -- `terraform apply`, which performs a plan and then, if a user approves, immediately applies it. -- `terraform destroy`, which is similar to `terraform apply` but uses a desired state in which none of the managed resources exist; if the plan is approved, those resources are destroyed. - -In Terraform Cloud, plans are performed by committing changes to a workspace's configuration, running `terraform plan` or `terraform apply` with the remote backend enabled, manually queueing a plan, or uploading a configuration via the API. - -Terraform Cloud's workflow always creates a [plan file][], which can be auto-applied or can wait for a user's approval. Terraform Cloud also supports [speculative plans][], which are for informational purposes only and cannot be applied. - -- [Terraform docs: The `terraform plan` command](/cli/commands/plan) -- [Terraform Cloud docs: About Runs](/cloud-docs/run) - -## Plan File - -[plan file]: /docs/glossary#plan-file -[plan files]: /docs/glossary#plan-file - -Also "`.tfplan`", "saved plan", or simply "plan" in contexts where it's clearly referring to an artifact. - -A binary artifact optionally produced by the `terraform plan` command, which `terraform apply` can use to carry out the exact changes that were decided at the time of the [plan][]. - -Terraform Cloud always uses a saved plan as the input to an [apply][], so that applies never make changes that weren't shown to the user after the plan (in cases where the config or the variables changed in the meantime). - -## Policy - -[policy]: /docs/glossary#policy -[policies]: /docs/glossary#policy -[sentinel policy]: /docs/glossary#policy -[sentinel policies]: /docs/glossary#policy - --> Terraform Cloud - -[Sentinel][] code that can be enforced on runs. Combined into [policy sets][]. - -- [Terraform Cloud docs: Managing Sentinel Policies](/cloud-docs/sentinel/manage-policies) - -## Policy Check - -[policy check]: /docs/glossary#policy-check -[policy checks]: /docs/glossary#policy-check - --> Terraform Cloud - -Part of a [run][]. After gathering the [configuration][], [state][], and [plan file][] for a run, Terraform Cloud runs [Sentinel][] to check that data against the active [policies][]. Policy checks end in success or failure. If a failure occurs in a required policy, this can prevent the run from proceeding to the [apply][] stage. - -- [Terraform Cloud docs: Run States and Stages](/cloud-docs/run/states) - -## Policy Set - -[policy set]: /docs/glossary#policy-set -[policy sets]: /docs/glossary#policy-set - --> Terraform Cloud - -A list of [Sentinel][] [policies][] to enforce globally or on specific workspaces. - -- [Terraform Cloud docs: Managing Sentinel Policies](/cloud-docs/sentinel/manage-policies) - -## Private Terraform Registry - -[private terraform registry]: /docs/glossary#private-terraform-registry -[private module registry]: /docs/glossary#private-terraform-registry -[private registry]: /docs/glossary#private-terraform-registry -[private module]: /docs/glossary#private-terraform-registry -[private modules]: /docs/glossary#private-terraform-registry - --> Terraform Cloud - -Also "private module registry". - -A version of the [Terraform Registry][] that is built-in to Terraform Cloud, to enable code sharing within an organization. It includes a configuration designer, which lets you combine and configure modules to generate a Terraform [configuration][] that uses them. - -- [Terraform Cloud docs: Private Registry](/cloud-docs/registry) - -## Private Terraform Enterprise (PTFE) - -[private terraform enterprise]: /docs/glossary#private-terraform-enterprise-ptfe- -[private installs]: /docs/glossary#private-terraform-enterprise-ptfe- - -[Terraform Enterprise][]. - -Prior to mid-2019, "Terraform Enterprise" (TFE) was the name of the Terraform Cloud application, and "Private Terraform Enterprise" (PTFE) was the name of the on-premises distribution. - -- [Terraform Enterprise docs](/enterprise) - -## (Terraform) Provider - -[provider]: /docs/glossary#terraform-provider -[providers]: /docs/glossary#terraform-provider - -A plugin for Terraform that makes a collection of related resources available. A provider plugin is responsible for understanding [API][] interactions with some kind of service and exposing [resources][] based on that API. - -Terraform providers are generally tied to a specific _infrastructure provider,_ which might be an infrastructure as a service (IaaS) provider (like AWS, GCP, Microsoft Azure, OpenStack), a platform as a service (PaaS) provider (like Heroku), or a software as a service (SaaS) provider (like Terraform Cloud, DNSimple, Cloudflare). - -There are many existing providers available, but providers can also be custom-built to work with any API. - -- [Terraform docs: Provider Use](/language/providers) -- [Terraform docs: Plugin Development](/plugin) - -## Pull Request (PR) - -[pull request]: /docs/glossary#pull-request-pr- -[pull requests]: /docs/glossary#pull-request-pr- -[pr]: /docs/glossary#pull-request-pr- -[prs]: /docs/glossary#pull-request-pr- - -A mechanism created by GitHub to review and discuss changes made to a [Git][] [repository][] [branch][] that a user wants to merge into another branch. Other collaborators can request changes, approve, or reject these changes. - -Conversationally, people often say "pull request" to refer to this review-before-merging workflow even when working with a VCS provider that calls it something else. (For example, GitLab calls this a Merge Request.) - -## Queue - -[queue]: /docs/glossary#queue -[queues]: /docs/glossary#queue - --> Terraform Cloud - -The list of [runs][] waiting to be processed. Terraform Cloud uses several queues of runs, including a per-workspace queue (since only one run at a time is allowed in a given [workspace][], to avoid conflicts and state corruption) and a global per-instance queue (since compute resources are finite and Terraform Cloud only has access to so many VMs). - -## (Terraform) Registry - -[terraform registry]: /docs/glossary#terraform-registry -[registry]: /docs/glossary#terraform-registry - -A repository of [modules][] written by the Terraform community, which can be used as-is within a Terraform [configuration][] or [forked][] and modified. The registry can help you get started with Terraform more quickly, see examples of how Terraform is written, and find pre-made modules for infrastructure components you require. - -- [Terraform docs: The Terraform Registry](/registry) - -## Remote Operations - -[remote operation]: /docs/glossary#remote-operations -[remote operations]: /docs/glossary#remote-operations - --> Terraform Cloud - -The ability to start a [run][] (or perform a few other tasks) from your local [CLI][] and view output inline, while still allowing Terraform Cloud to perform the actual operation. - -Terraform Cloud performs Terraform runs in its own disposable VMs, where it can capture information, control access to secrets, etc., but many users are accustomed to running Terraform on their local machines. Remote operations exist to help split the difference. - -- [Terraform Cloud Docs: Terraform Runs and Remote Operations](/cloud-docs/run#remote-operations) - -## Remote Backend - -[remote backend]: /docs/glossary#remote-backend - -A Terraform CLI feature that lets Terraform connect to Terraform Cloud, by specifying in the Terraform [configuration][] which organization and workspace(s) to use. Used for [remote operations][] in Terraform Cloud workspaces, and used for [state][] storage in Terraform Cloud's free tier. - -See also [backend][]. Older documentation sometimes refers to backends like `s3` or `consul` as "remote backends," since they store Terraform's state in a remote service instead of the local filesystem, but today this term usually means the specific backend whose name is `remote`. - -- [Terraform docs: The `remote` Backend](/language/settings/backends/remote) - -## Repository - -[repository]: /docs/glossary#repository -[repositories]: /docs/glossary#repository -[repo]: /docs/glossary#repository -[repos]: /docs/glossary#repository - -Also "repo". - -A collection of files and a history of the changes to them, managed by a [version control system][vcs]. In Terraform Cloud, a "repo" is generally a Git repository that contains a Terraform configuration, although [private modules][] are also based on Git repos. - -- [Wikipedia: Repository (version control)]() - -## Resource - -[resource]: /docs/glossary#resource -[resources]: /docs/glossary#resource - -Also "infrastructure resource". - -In Terraform's [configuration][] language: A [block][] that describes one or more infrastructure objects. Resources can be things like virtual networks, compute instances, or higher-level components such as DNS records. - -In other Terraform-related contexts: An infrastructure object of a type that _could_ be managed by Terraform. - -A resource block in a configuration instructs Terraform to _manage_ the described resource — during a run, Terraform will create a matching real infrastructure object if one doesn't already exist, and will modify the existing object if it doesn't match the desired configuration. Terraform uses [state][] to keep track of which real infrastructure objects correspond to resources in a configuration. - -Terraform uses cloud provider [APIs][] to create, edit, and destroy resources. Terraform [providers][] are responsible for defining resource types and mapping transitions in a resource's state to a specific series of API calls that will carry out the necessary changes. - -- [Terraform docs: Resources](/configuration/resources) - -## Root Module - -[root module]: /docs/glossary#root-module -[root modules]: /docs/glossary#root-module - -The place where Terraform begins evaluating a [configuration][]. The root module consists of all of the configuration files in Terraform's [working directory][]. - -The root module's [variables][] and [outputs][] are handled directly by Terraform (unlike child [modules][], whose variables and outputs are handled by the calling module). Root variable values can be provided with Terraform Cloud, `.tfvars` files, CLI options, or environment variables. Root outputs are printed after a run and stored in the state. - -## Root Outputs - -[root output]: /docs/glossary#root-outputs -[root outputs]: /docs/glossary#root-outputs - -Also "root-level outputs". - -The [output values][] of a configuration's [root module][]. A [configuration][] can access the root outputs of another configuration with a `terraform_remote_state` data source. - -## Run - -[run]: /docs/glossary#run -[runs]: /docs/glossary#run - -Also "Terraform Run". - -The process of using Terraform to make real infrastructure match the desired state (as specified by the contents of the config and variables at a specific moment in time). - -In Terraform Cloud, runs are performed in a series of stages ([plan][], [policy check][], and [apply][]), though not every stage occurs in every run. Terraform Cloud saves information about historical runs. - -- [Learn Terraform: Get Started](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) -- [Terraform Cloud docs: About Runs](/cloud-docs/run) - -## Run Triggers - -[run triggers]: /docs/glossary#run-triggers - --> Terraform Cloud - -Terraform Cloud provides a way to connect a given workspace to one or more workspaces within an organization, known as "source workspaces". These connections, called run triggers, allow runs to queue automatically in your workspace on successful apply of runs in any of the source workspaces. - -- [Terraform Cloud docs: Runs Triggers](/cloud-docs/workspaces/settings/run-triggers) - -## S3 - -[s3]: /docs/glossary#s3 - -Amazon Web Services' "Simple Storage Service", a service for storing and retrieving arbitrary blobs of data. - -Many other cloud or self-hosted services provide [APIs][] that are compatible with S3's API, which allows them to be used with software that was designed to work with S3. - -Terraform's `aws` [provider][] can manage S3 resources. - -Terraform Enterprise can use an S3-compatible [blob storage][] service when configured to use _External Services_ for storage. - -- [AWS: S3](https://aws.amazon.com/s3/) - -## SAML - -[saml]: /docs/glossary#saml - --> Terraform Enterprise - -SAML is an XML-based standard for authentication and authorization. Terraform Enterprise can act as a service provider (SP) (or Relying Party, RP) with your internal SAML identity provider (IdP). The SAML Single Sign On feature is only available on [Terraform Enterprise][]; the Terraform Cloud SaaS does not support it. - -- [Terraform Enterprise docs: SAML Single Sign-On](/enterprise/user-management/saml) - -## Sentinel - -[sentinel]: /docs/glossary#sentinel - --> Terraform Cloud - -A language and runtime for managing policy as code. Allows you to define rules around operations in Terraform Cloud. - -- [Terraform Cloud docs: Sentinel](/cloud-docs/sentinel) - -## Site Admin - -[site admin]: /docs/glossary#site-admin -[site admins]: /docs/glossary#site-admin - --> Terraform Enterprise - -An administrator of a [Terraform Enterprise][] instance, who has access to application settings that affect all [organizations][] using the instance. - -- [Terraform Enterprise docs: Administration](/enterprise/admin) - -## Speculative Plan - -[speculative plan]: /docs/glossary#speculative-plan -[speculative plans]: /docs/glossary#speculative-plan - --> Terraform Cloud - -A [run][] that is only intended to show possible changes to infrastructure, when using a given [config version][] and set of [variables][]. Speculative plans can never be [applied][apply-v], and are usually started as a result of [pull requests][] to a [workspace][]'s repo, or by running `terraform plan` on the command line with [remote operations][] configured. - -## SSH Key - -[ssh key]: /docs/glossary#ssh-key -[ssh keys]: /docs/glossary#ssh-key - -A type of access credential based on public key cryptography, used to log into servers. - -Terraform Cloud uses SSH private keys for two kinds of operations: - -- Downloading private Terraform [modules][] with [Git][]-based sources during a Terraform run. Keys for downloading modules are assigned per-workspace. - -- Bringing content from a connected [VCS provider][] into Terraform Cloud, usually when pulling in a Terraform [configuration][] for a [workspace][] or importing a module into the [private module registry][]. Only some VCS providers require an SSH key, but other providers only need an SSH key if your repositories include submodules that are only accessible via SSH (instead of your VCS provider's API). - -- [Wikipedia: SSH](https://en.wikipedia.org/wiki/Secure_Shell) - -- [Terraform Cloud docs: SSH Keys for Cloning Modules](/cloud-docs/workspaces/settings/ssh-keys) - -## State - -[state]: /docs/glossary#state - -Terraform's cached information about your managed infrastructure and [configuration][]. This state is used to persistently map the same real world [resources][] to your configuration from run-to-run, keep track of metadata, and improve performance for large infrastructures. - -Without state, Terraform has no way to identify the real resources it created during previous runs. Thus, when multiple people are collaborating on shared infrastructure, it's important to store state in a shared location, like a free Terraform Cloud organization. - -- [Terraform docs: State](/language/state) - -## State Version - -[state version]: /docs/glossary#state-version -[state versions]: /docs/glossary#state-version - --> Terraform Cloud - -A snapshot of your infrastructure's [state][] at a point in time. Can be manually uploaded to Terraform Cloud or created as the result of an [apply][]. - -Terraform CLI doesn't have any concept of historical state data; it only interacts with the most recent state, and writes a snapshot of the new state to the configured [backend][] after making changes. Whatever system that backend writes to can choose to retain previous state; Terraform Cloud does this, and some other backends (like S3) can also be configured to keep historical snapshots. The `local` backend does not. - -## Team - -[team]: /docs/glossary#team -[teams]: /docs/glossary#team - --> Terraform Cloud - -A group of Terraform Cloud users, which can be given permission to access and/or edit various objects ([workspaces][], [policies][], etc.) within an [organization][]. A team belongs to a single organization. Users can belong to any number of teams in any number of organizations. - -- [Terraform Cloud docs: Teams](/cloud-docs/users-teams-organizations/teams) - -## Terraform - -[terraform]: /docs/glossary#terraform - -A tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions. - -- [Intro to Terraform](/intro) - -## Terraform Cloud - -[terraform cloud]: /docs/glossary#terraform-cloud - -An application that helps teams use Terraform together. Terraform Cloud provides a consistent environment for Terraform runs, as well as hosting Terraform [state][] and other shared information. - -Terraform Cloud is available as a hosted service at . It is also available in an on-premises distribution called [Terraform Enterprise][]. - -Prior to mid-2019, "Terraform Enterprise" (TFE) was the name of the Terraform Cloud application, and "Private Terraform Enterprise" (PTFE) was the name of the on-premises distribution. - -- [Terraform Cloud docs](/cloud) - -## Terraform Enterprise - -[terraform enterprise]: /docs/glossary#terraform-enterprise - -An on-premises distribution of Terraform Cloud, which enables large enterprises to host their own private instance of the application. - -Prior to mid-2019, "Terraform Enterprise" (TFE) was the name of the Terraform Cloud application, and "Private Terraform Enterprise" (PTFE) was the name of the on-premises distribution. - -- [Terraform Enterprise docs](/enterprise) - -## Terraform Version - -[terraform version]: /docs/glossary#tool-version -[terraform versions]: /docs/glossary#tool-version - --> Terraform Cloud - -A particular version of the `terraform` binary available for use in Terraform Cloud workspaces. Specifies a URL, a SHA256 checksum and enabled/beta flags. - -[Site admins][] can configure the available Terraform versions for a [Terraform Enterprise][] instance. - -- [Terraform Enterprise docs: Managing Terraform Versions](/enterprise/admin/application/resources#managing-terraform-versions) - -## TFE - -[tfe]: /docs/glossary#tfe - -[Terraform Enterprise][]. - -- [Terraform Enterprise docs](/enterprise) - -## TFE Provider / Terraform Cloud Provider - -[tfe provider]: /docs/glossary#tfe-provider-terraform-cloud-provider - -A Terraform provider that manages Terraform Cloud. Allows you to manage Terraform Cloud using a Terraform [configuration][]. - -- [Provider docs: tfe](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) - -## (API) Token - -[token]: /docs/glossary#api-token -[tokens]: /docs/glossary#api-token - --> Terraform Cloud - -A revocable secret string that authenticates a user, to allow use of Terraform Cloud's [API][] or the [remote backend][]. - -Different kinds of tokens grant different permissions. Tokens can be granted by user, [team][], or [organization][]. - -Many applications other than Terraform Cloud use token-based authentication, but within Terraform Cloud's documentation and UI, "token" without any other qualification generally means a Terraform Cloud API token. - -- [Terraform Cloud docs: User Tokens](/cloud-docs/users-teams-organizations/users#api-tokens) -- [Terraform Cloud docs: Team Tokens](/cloud-docs/users-teams-organizations/teams#api-tokens) -- [Terraform Cloud docs: Organization Tokens](/cloud-docs/users-teams-organizations/organizations#api-tokens) - -## Trigger - -[trigger]: /docs/glossary#trigger -[triggers]: /docs/glossary#trigger - --> Terraform Cloud - -Something that causes a new [run][] to queue. Runs can be UI/VCS-driven (in which case the trigger is a new VCS commit or a UI action), API-driven (in which case the trigger is an API call) or CLI-driven (in which case the trigger is a CLI command). - -- [Terraform Cloud docs: UI/VCS-based Run Workflow](/cloud-docs/run/ui) - -## Variables - -[variables]: /docs/glossary#variables -[input variables]: /docs/glossary#variables - -Also "input variables". - -In general-purpose programming, a variable is a symbolic name associated with a value. - -In Terraform, "variables" almost always refers to _input variables,_ which are key/value pairs used in a [run][]. Terraform [modules][] can declare variables to allow customization. For child modules, the parent module provides a value when calling the module; for the [root module][], values are provided at run time. - -Terraform Cloud lets you set values for root input variables in a [workspace][], so all collaborators can use the same values. Variable values marked as "sensitive" become unreadable in the UI and API, and all variable values are protected by Vault. - -- [Terraform docs: Input Variables](/language/values/variables) -- [Terraform Cloud docs: Variables](/cloud-docs/workspaces/variables) - -## VCS - -[vcs]: /docs/glossary#vcs - -Version Control System, like [Git][]. Software that tracks changes over time to a collection of files, making it possible to keep track of changes, undo changes, and combine changes made in parallel by different users. Usually used for any non-trivial code effort, including infrastructure as code. - -Different VCSes use different models for history; Git models changes as a directed acyclic graph of [commits][], and parallel changes that begin from the same parent commit become diverging [branches][] (which might later be merged together). - -- [Wikipedia: Version Control](https://en.wikipedia.org/wiki/Version_control) - -## VCS Provider - -[vcs provider]: /docs/glossary#vcs-provider -[vcs providers]: /docs/glossary#vcs-provider - --> Terraform Cloud - -A specific service that provides [VCS][] features, with the goal of enabling teams to collaborate on code. Terraform Cloud can integrate with VCS providers to access your Terraform [configurations][] and [modules][], and currently supports GitHub, GitHub Enterprise, GitLab.com, GitLab EE and CE, Bitbucket Cloud, Bitbucket Server, Azure DevOps Server, and Azure DevOps Services. - -- [Terraform Cloud docs: Connecting VCS Providers](/cloud-docs/vcs) - -## Webhook - -[webhook]: /docs/glossary#webhook -[webhooks]: /docs/glossary#webhook - -A server-to-server HTTP request, in which one system responds to a change in its internal state by sending information to another system. - -The recipient of a webhook might return information to the requesting system, call other webhooks in response, perform its action silently, or ignore the request entirely. - -Terraform Cloud uses webhooks in multiple ways. Most notably: - -- Terraform Cloud creates webhook configurations on [VCS providers][], so that they send webhook requests to Terraform Cloud whenever linked [repositories][] receive [pull requests][] or new [commits][]. ([Terraform Cloud docs: UI/VCS-driven Runs](/cloud-docs/run/ui)) -- Users can create webhook configurations on Terraform Cloud [workspaces][], so that Terraform Cloud will send run notification webhooks to Slack or other external services. ([Terraform Cloud docs: Run Notifications](/cloud-docs/workspaces/settings/notifications)) - -## Working Directory - -[working directory]: /docs/glossary#working-directory -[working directories]: /docs/glossary#working-directory - -The directory where `terraform init` runs, creating a `.terraform` subdirectory. All subsequent commands for the same [configuration][] should then be run from the same working directory. - -The [root module][] consists of all of the configuration files in the top level of Terraform's working directory. Subdirectories of the working directory can contain child [modules][]. - -## Workspace - -[workspace]: /docs/glossary#workspace -[workspaces]: /docs/glossary#workspace - -In Terraform CLI, a workspace is an isolated instance of [state][] data. Using multiple workspaces lets you manage multiple non-overlapping sets of infrastructure from a single [configuration][] in a single [working directory][]. - -In Terraform Cloud, a workspace is a complex object that represents everything needed to manage a specific collection of infrastructure resources over time. In particular, this includes: - -- A Terraform [configuration][] (which has multiple versions over time, and which can come from a repo or from manual uploads) -- A set of [variables][] -- [State][] data that represents the current and historical condition of the infrastructure -- Historical information about [runs][]. - -All Terraform Cloud runs occur in the context of a workspace — they use that workspace's config data, use that workspace's state to identify the real infrastructure being managed, and edit that workspace's state to match any infrastructure changes during the run. A workspace belongs to an [organization][]. - -- [Terraform Cloud docs: Workspaces](/cloud-docs/workspaces) -- [Terraform docs: Workspaces](/language/state/workspaces) diff --git a/website/docs/docs/index.mdx b/website/docs/docs/index.mdx deleted file mode 100644 index e6bafacf17..0000000000 --- a/website/docs/docs/index.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -page_title: Documentation -description: >- - Documentation for Terraform, including Terraform CLI, Terraform Cloud, and - Terraform Enterprise. -show_notification: false ---- - -# Terraform Documentation - -Terraform is an infrastructure as code (IaC) tool that allows you to build, change, and version infrastructure safely and efficiently. This includes both low-level components like compute instances, storage, and networking, as well as high-level components like DNS entries and SaaS features. - -
-
- -### Get Started - -- Learn how Terraform [solves infrastructure challenges](/intro) and how it [compares to other tools and services](/intro/vs). -- Install Terraform and explore use cases with the [hands-on tutorials on HashiCorp Learn](https://learn.hashicorp.com/collections/terraform/aws-get-started). - -### Manage Infrastructure - -- Describe infrastructure on various [providers](/language/providers) with [Terraform's configuration language](/language). -- Use the [Terraform CLI](/cli) to manage configuration, plugins, infrastructure, and state. -- Use [CDK for Terraform](/cdktf) to write and deploy Terraform configurations in your preferred programming language. - -
- -
- -### Collaborate - -- [Terraform Cloud](/cloud) helps teams use Terraform together, with version control, state sharing, [governance](/cloud-docs/sentinel), and more. -- [Terraform Enterprise](/enterprise) is a self-hosted instance of Terraform Cloud. - -### Develop and Share - -- [Create a provider](/plugin) to allow Terraform to interact with a service. -- Create reusable configurations with [modules](/language/modules). -- [Publish a provider or module](/registry) to the Terraform Registry to make it publicly available. - -
- -
diff --git a/website/docs/docs/partnerships.mdx b/website/docs/docs/partnerships.mdx deleted file mode 100644 index aae535dd53..0000000000 --- a/website/docs/docs/partnerships.mdx +++ /dev/null @@ -1,217 +0,0 @@ ---- -page_title: Terraform Integration Program -description: >- - The Terraform Integration Program allows prospect partners to create and - publish Terraform integrations that have been verified by HashiCorp. ---- - -# Terraform Integration Program - -The Terraform Integration Program facilitates prospect partners in creating and publishing Terraform integrations that have been verified by HashiCorp. - -## Terraform Editions - -Terraform is an infrastructure as code (IaC) tool that allows you to build, change, and version infrastructure safely and efficiently. This includes low-level components such as compute instances, storage, and networking, as well as high-level components such as DNS entries, SaaS features, etc. Terraform can manage both existing service providers and custom in-house solutions. - -HashiCorp offers three editions of Terraform: Open Source, Terraform Cloud, and Terraform Enterprise. - -- [Terraform Open Source](/) provides a consistent CLI workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files. -- [Terraform Cloud (TFC)](/cloud) is a free to use, self-service SaaS platform that extends the capabilities of the open source Terraform CLI. It adds automation and collaboration features, and performs Terraform functionality remotely, making it ideal for collaborative and production environments. Terraform Cloud is available as a hosted service at https://app.terraform.io. Small teams can sign up for free to connect Terraform to version control, share variables, run Terraform in a stable remote environment, and securely store remote state. Paid tiers allow you to add more than five users, create teams with different levels of permissions, enforce policies before creating infrastructure, and collaborate more effectively. -- [Terraform Enterprise (TFE)](/enterprise) is our self-hosted distribution of Terraform Cloud with advanced security and compliance features. It offers enterprises a private instance that includes the advanced features available in Terraform Cloud. - -## Types of Terraform Integrations - -The Terraform ecosystem is designed to enable users to apply Terraform across different use cases and environments. The Terraform Integration Program currently supports both workflow and integration partners (details below). Some partners can be both, depending on their use cases. - -- **Workflow Partners** build integrations for Terraform Cloud and/or Terraform Enterprise. Typically, these partners are seeking to enable customers to use their existing platform within a Terraform Run. - -- **Infrastructure Partners** empower customers to leverage Terraform to manage resources exposed by their platform APIs. These are accessible to users of all Terraform editions. - -Our Workflow Partners typically have the following use cases: - -- **Code Scanning:** These partners provide tooling to review infrastructure as code configurations to prevent errors or security issues. -- **Cost Estimation:** These partners drive cost estimation of new deployment based on historical deployments. -- **Monitoring:** These partners provide performance visibility. -- **Zero Trust Security:** These partners help users create configurations to verify connections prior to providing access to an organization’s systems. -- **Audit:** These partners focus on maintaining code formatting, preventing security threats, and performing additional code analysis. -- **ITSM (Information Technology Service Management):** These partners focus on implementation, deployment, and delivery of IT workflows. -- **SSO (Single Sign On):** These partners focus on authentication for end users to securely sign on. -- **CI/CD:** These partners focus on continuous integration and continuous delivery/deployment. -- **VCS:** These partners focus on tracking and managing software code changes. - -Most workflow partners integrate with the Terraform workflow itself. Run tasks allow Terraform Cloud to execute tasks in external systems at specific points in the Terraform Cloud run lifecycle. This offers much more extensibility to Terraform Cloud customers, enabling them to integrate your services into the Terraform Cloud workflow. The beta release of this feature allows users to add and execute these tasks during the new pre-apply stage which exists in between the plan and apply stages. Eventually, we will open the entire workflow to Terraform Cloud users, including the pre-plan and post apply stages. Reference the [Terraform Cloud Integrations](/docs/partnerships#terraform-cloud-integrations) or [Terraform Enterprise Integrations](/docs/partnerships#terraform-enterprise-integrations) documentation for more details. - -![Integration program diagram](/img/docs/terraform-integration-program-diagram.png) - -Our Infrastructure Partners typically have the following use cases: - -- **Public Cloud:** These are large-scale, global cloud providers that offer a range of services including IaaS, SaaS, and PaaS. -- **Container Orchestration:** These partners help with container provisioning and deployment. -- **IaaS (Infrastructure-as-a-Service):** These are infrastructure and IaaS providers that offer solutions such as storage, networking, and virtualization. -- **Security & Authentication:** These are partners with authentication and security monitoring platforms. -- **Asset Management:** These partners offer asset management of key organization and IT resources, including software licenses, hardware assets, and cloud resources. -- **CI/CD:** These partners focus on continuous integration and continuous delivery/deployment. -- **Logging & Monitoring:** These partners offer the capability to configure and manage services such as loggers, metric tools, and monitoring services. -- **Utility:** These partners offer helper functionality, such as random value generation, file creation, http interactions, and time-based resources. -- **Cloud Automation:** These partners offer specialized cloud infrastructure automation management capabilities such as configuration management. -- **Data Management:** These partners focus on data center storage, backup, and recovery solutions. -- **Networking:** These partners integrate with network-specific hardware and virtualized products such as routing, switching, firewalls, and SD-WAN solutions. -- **VCS (Version Control Systems):** These partners focus on VCS (Version Control System) projects, teams, and repositories from within Terraform. -- **Comms & Messaging:** These partners integrate with communication, email, and messaging platforms. -- **Database:** These partners offer capabilities to provision and configure your database resources. -- **PaaS (Platform-as-a-Service):** These are platform and PaaS providers that offer a range of hardware, software, and application development tools. This category includes smaller-scale providers and those with more specialized offerings. -- **Web Services:** These partners focus on web hosting, web performance, CDN and DNS services. - -Infrastructure partners integrate by building and publishing a plugin called a Terraform [provider](/language/providers). Providers are executable binaries written in Go that communicate with Terraform Core over an RPC interface. The provider acts as a translation layer for transactions with external APIs, such as a public cloud service (AWS, GCP, Azure), a PaaS service (Heroku), a SaaS service (DNSimple, CloudFlare), or on-prem resources (vSphere). Providers work across Terraform OSS, Terraform Cloud and Terraform Enterprise. Refer to the [Terraform Provider Integrations documentation](/docs/partnerships#terraform-provider-integrations) for more detail. - -## Terraform Provider Integrations - -You can follow the five steps. below to develop your provider alongside HashiCorp. This ensures that you can publish new versions with Terraform quickly and efficiently. - -![Provider Development Process](/img/docs/provider-program-steps.png) - -1. **Prepare**: Develop integration using included resources -1. **Publish**: Publish provider to the Registry or plugin documentation -1. **Apply**: Apply to Technology Partnership Program -1. **Verify**: Verify integration with HashiCorp Alliances team -1. **Support**: Vendor provides ongoing maintenance and support - -We encourage you to follow the tasks associated with each step fully to streamline the development process and minimize rework. - -All providers integrate into and operate with Terraform exactly the same way. The table below is intended to help users understand who develops, and maintains a particular provider. - - -

- -### 1. Prepare - -To get started with the Terraform provider development, we recommend reviewing and following the articles listed below. - -#### Provider Development Kit - -a) Writing custom providers [guide](https://learn.hashicorp.com/tutorials/terraform/provider-setup) - -b) Creating a Terraform Provider for Just About Anything: [video](https://www.youtube.com/watch?v=noxwUVet5RE) - -c) Sample provider developed by [partner](http://container-solutions.com/write-terraform-provider-part-1/) - -d) Example provider for reference: [AWS](https://github.com/terraform-providers/terraform-provider-aws), [OPC](https://github.com/terraform-providers/terraform-provider-opc) - -e) Contributing to Terraform [guidelines](https://github.com/hashicorp/terraform/blob/master/.github/CONTRIBUTING.md) - -f) HashiCorp developer [forum](https://discuss.hashicorp.com/c/terraform-providers/tf-plugin-sdk/43) - -Please submit questions or suggestions about the Terraform SDK and provider development to the HashiCorp Terraform plugin SDK forum. If you are new to provider development and would like assistance, you can leverage one of the following development agencies that have developed Terraform providers in the past: - -| Partner | Email | Website | -| ------------------ | :-------------------------- | :-------------------------------------------------- | -| Crest Data Systems | | [www.crestdatasys.com](http://www.crestdatasys.com) | -| DigitalOnUs | | [www.digitalonus.com](http://www.digitalonus.com) | -| Akava | | [www.akava.io](http://www.akava.io) | -| OpenCredo | | [www.opencredo.com](http://www.opencredo.com) | - -#### Provider License - -All Terraform providers listed as Verified must contain one of the following open source licenses: - -- CDDL 1.0, 2.0 -- CPL 1.0 -- Eclipse Public License (EPL) 1.0 -- MPL 1.0, 1.1, 2.0 -- PSL 2.0 -- Ruby's Licensing -- AFL 2.1, 3.0 -- Apache License 2.0 -- Artistic License 1.0, 2.0 -- Apache Software License (ASL) 1.1 -- Boost Software License -- BSD, BSD 3-clause, "BSD-new" -- CC-BY -- Microsoft Public License (MS-PL) -- MIT - -### 2. Publish - -After your provider is complete and ready to release, you can publish it the integration to the [Terraform Registry](https://registry.terraform.io/). This makes it publicly available for all Terraform users. - -Follow the [Terraform Registry publishing documentation](/registry/providers/publishing) and review the [provider publishing learn guide](https://learn.hashicorp.com/tutorials/terraform/provider-release-publish?in=terraform/providers). If your company has multiple products with separate providers, we recommend publishing them under the same Github organization to help with discoverability. - -Once completed, your provider will be visible in the Terraform Registry and available to use in Terraform. Please confirm that everything looks correct and that documentation is rendering properly. - -### 3. Apply - -After your provider is published, connect with HashiCorp Alliances to onboard your integration to the HashiCorp technology ecosystem or [apply to become a technology partner](https://www.hashicorp.com/ecosystem/become-a-partner/#technology). - -### 4. Verify - -Work with your HashiCorp Alliances representative to verify the plugin within the Registry and become listed as an HashiCorp technology partner integration on HashiCorp website. - -### 5. Support - -Getting a new provider built and published to the Terraform Registry is just the first step towards enabling your users with a quality Terraform integration. Once a verified provider has been published, on-going effort is required to maintain the provider. - -HashiCorp Terraform has an extremely wide community of users and contributors and we encourage everyone to report issues however small, as well as help resolve them when possible. We expect that all verified provider publishers will continue to maintain the provider and address any issues users report in a timely manner. This includes resolving all critical issues within 48 hours and all other issues within 5 business days. HashiCorp reserves the right to remove verified status from any integration that is no longer being maintained. - -Vendors who choose not to support their provider and prefer to make it a community-supported provider will no longer be listed as Verified. - --> **Network Infrastructure Automation (NIA):** These integrations leverage Consul’s service catalog to seamlessly integrate with Consul-Terraform-Sync (CTS) to automate changes in network infrastructure via a publisher-subscriber method. More details can be found in the [NIA Integration Program](https://www.consul.io/docs/integrate/nia-integration) documentation. - -## Terraform Cloud Integrations - -Run tasks allow Terraform Cloud to execute tasks in external systems at specific points in the Terraform Cloud run lifecycle. The beta release of this feature allows users to add and execute these tasks during the new pre-apply stage that exists in between the plan and apply stages. Tasks are executed by sending an API payload to the external system. This payload contains a collection of run-related information and a callback URL which the external system can use to send updates back to Terraform Cloud. - -The external system can then use this run information and respond back to Terraform Cloud with a passed or failed status. Terraform Cloud uses this status response to determine if a run should proceed, based on the task's enforcement settings within a workspace. - -Partners who successfully complete the Terraform Cloud integration checklist obtain a Terraform Cloud badge. This signifies HashiCorp has verified the integration and the partner is a member of the HashiCorp Technology Partner Program. - -- Note: Currently, pre-apply is the only integration phase available. As of September 2021, run tasks are available only as a beta feature, are subject to change, and not all customers will see this functionality in their Terraform Cloud organization since this is currently enabled by default for our business tier customers of Terraform Cloud. If you have a customer that is interested in run tasks and are not a current Terraform Cloud for Business customer please request them to [sign up using the form](https://docs.google.com/forms/d/e/1FAIpQLSf3JJIkU05bKWov2wXa9c-QV524WNaHuGIk7xjHnwl5ceGw2A/viewform). - -Terraform Cloud Partnership Badge - -The above badge will help drive visibility for the partner as well as provide better differentiation for joint customers. This badge will be available for partners to use at their digital properties (as per guidelines in the technology partner guide that partners receive when they join HashiCorp’s technology partner program). - -The Terraform Cloud Integration program has the following five steps. - -![RunTask Program Process](/img/docs/runtask-program-steps.png) - -1. **Engage**: Sign up for the Technology Partner - Program -1. **Develop & Test**: Understand and build using the API integration for Run Tasks -1. **Review**: Review integration with HashiCorp Alliances team -1. **Release**: Provide documentation for your Integration -1. **Support**: Vendor provides ongoing maintanance and support - -### 1. Engage - -For partners who are new to working with Hashicorp, we recommend [signing up for our Technology Partner Program](https://www.hashicorp.com/go/tech-partner). To understand more about the program, check out our “[Become a Partner](https://www.hashicorp.com/partners/become-a-partner)” page. - -### 2. Develop & Test - -Partners should build an integration using [Run Task APIs in Terraform Cloud](/cloud-docs/api-docs/run-tasks). To better understand how run Task enhances the workflow, see diagram listed below and check out our [announcement about Terraform run Task](https://www.hashicorp.com/blog/terraform-cloud-run-tasks-beta-now-available). [Snyk](https://docs.snyk.io/features/integrations/ci-cd-integrations/integrating-snyk-with-terraform-cloud), for example, created an integration to detect configuration anomalies in code while reducing risk to the infrastructure. For additional API resources, [click here](/cloud-docs/api-docs). -**Currently, pre-apply is the only integration phase available.** - -![RunTask Diagram](/img/docs/runtask-diagram.png) - -### 3. Review - -Schedule time with your Partner Alliance manager to review your integration. The review should include enabling the integration on the partner’s platform and Terraform Cloud, explaining the use case for the integration, and a live demonstration of the functionality. If you are unable to engage with your Partner Alliances manager, you can also reach out to . - -### 4. Release - -We add new partners to the [Terraform Run Task page](/cloud-docs/integrations/run-tasks#run-tasks-technology-partners) after the integration review and documentation is complete. On this page, you will provide a two-line summary about your integration(s). If you have multiple integrations, we highly recommend creating a summary that highlights all potential integration options. - -You must provide documentation that helps users get started with your integration. You also need to provide documentation for our support team, including points of contact, email address, FAQ and/or best practices. We want to ensure end users are able to reach the right contacts for internal HashiCorp support when working with customers. - -### 5. Support - -At HashiCorp, we view the release step to be the beginning of the journey. Getting the integration built is just the first step in enabling users to leverage it against their infrastructure. On-going effort is required to support and maintain it after you complete the initial development. - -We expect that partners will create a mechanism to track and resolve all critical issues as soon as possible (ideally within 48 hours) and all other issues within 5 business days. This is a requirement given the critical nature of Terraform Cloud to a customer’s operation. If you choose not to support your integration, we cannot consider it verified and will not list it on the Terraform documentation website. - -## Terraform Enterprise Integrations - -Terraform Enterprise integrations are workflow integrations that are validated against Terraform Enterprise. Partners with a verified Terraform Enterprise integration will be given a Terraform Enterprise verified badge. This signifies HashiCorp has verified the integration and the partner is a member of the HashiCorp Technology Partner Program. At this time we are working to release an official program around integrating with Terraform Enterprise. Until then, if you are interested in publishing a verified Terraform Enterprise integration, please reach out to us at [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com). - -Terraform Cloud Partnership Badge - --> Contact us at [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) with any questions or feedback. \ No newline at end of file diff --git a/website/docs/docs/terraform-tools.mdx b/website/docs/docs/terraform-tools.mdx deleted file mode 100644 index dfe8f6cc8a..0000000000 --- a/website/docs/docs/terraform-tools.mdx +++ /dev/null @@ -1,73 +0,0 @@ ---- -page_title: Terraform Tools -description: >- - Use these tools with Terraform to solve a broad range of infrastructure and DevOps challenges. ---- - -# Terraform Tools -Terraform is part of a rich infrastructure and DevOps ecosystem. The tools below extend Terraform’s functionality or pair with Terraform to solve a broad range of infrastructure challenges. - -## Develop and Validate Configuration - -|Name | Maintainer |Description| Tutorial | -|-----|------------|-----------|----------| -|[Cloud Development Kit for Terraform (CDKTF)](/cdktf)| HashiCorp | Use familiar programming languages to define and provision infrastructure. CDKTF currently supports TypeScript, Python, Java, C#, and Go (experimental).| [Write CDK for Terraform configurations](https://learn.hashicorp.com/collections/terraform/cdktf) | -|[Visual Studio Code Extension](https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform) | HashiCorp | Enable syntax highlighting and other editing features in VS Code using the Terraform Language Server.| | -|[Language Server](https://github.com/hashicorp/terraform-ls) | HashiCorp | Add support for the Terraform configuration language to editors that use the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/), like Sublime Text, vim, emacs, etc.| | -|[console](https://www.terraform.io/docs/cli/commands/console.html) | HashiCorp | Evaluate Terraform expressions and explore your Terraform project's state. The console helps you develop and debug your configuration, especially when working with complex state data and Terraform expressions.| [Develop Configuration with the Console](https://learn.hashicorp.com/tutorials/terraform/console) | - - -## Manage Infrastructure - -|Name | Maintainer |Description| Tutorial | -|-----|------------|-----------|----------| -|[Kubernetes Operator for Terraform](https://github.com/hashicorp/terraform-k8s)| HashiCorp | Manage cloud and on-prem infrastructure through a Kubernetes custom resource definition (CRD) and Terraform Cloud. | [Deploy Infrastructure with the Terraform Cloud Operator for Kubernetes](https://learn.hashicorp.com/tutorials/terraform/kubernetes-operator) | -| [ServiceNow Catalog](/docs/cloud/integrations/service-now/index.html) | HashiCorp | Create Terraform configuration to order Service Items, create workspaces, and perform Terraform runs from ServiceNow.| | -| [Consul Terraform Sync (CTS)](https://github.com/hashicorp/consul-terraform-sync) | HashiCorp | Automatically request network infrastructure updates to accommodate Consul service registrations. Works with A10 ADC, F5 BIG IP, Palo Alto Networks, and more. | [Network Infrastructure Automation (NIA)](https://learn.hashicorp.com/collections/consul/network-infrastructure-automation) | - - -## Automate Terraform - -|Name | Maintainer |Description| Tutorial | -|-----|------------|-----------|----------| -| [`terraform-exec`](https://github.com/hashicorp/terraform-exec) | HashiCorp | Use this Go module to construct and run CLI commands. Refer to the `terraform-json` repository (below) for documentation about the return values. | | -| [`terraform-json`](https://github.com/hashicorp/terraform-json) | HashiCorp | Use the data types and helper functions in this repository to work with JSON-formatted Terraform output.| | -|[TFE Provider](https://registry.terraform.io/providers/hashicorp/tfe/latest) | HashiCorp | Manage Terraform Cloud or Terraform Enterprise with Terraform itself. Create, modify, and delete organizations, workspaces, teams, variables, run triggers, policy sets, and more. | | -| [CircleCI Orb](https://circleci.com/developer/orbs/orb/circleci/terraform) | Third Party | Deploy your Terraform infrastructure with a CircleCI pipeline. CircleCI Orbs let you package, ship, and re-use configurations. | [Deploy Terraform infrastructure with CircleCI](https://learn.hashicorp.com/tutorials/terraform/circle-ci) | -|[GitHub Actions for Terraform](https://github.com/hashicorp/setup-terraform) | Third Party | Automate Terraform in your GitHub Actions workflow. After you have used the action, subsequent steps in the same job can run Terraform commands using the GitHub Actions run syntax. | [Automate Terraform with GitHub Actions](https://learn.hashicorp.com/tutorials/terraform/github-actions) | - -## Security and Compliance - -|Name | Maintainer |Description| Tutorial | -|-----|------------|-----------|----------| -| [Splunk and Terraform Cloud](/docs/cloud/integrations/splunk/index.html) | HashiCorp | Pull audit logs from Terraform Cloud into Splunk to identify the most active policies, understand significant changes in resource operations, and filter actions by specific users within your organization. | | -| [Sentinel](https://www.terraform.io/docs/cloud/sentinel/index.html) | HashiCorp | Write and enforce fine-grained, logic-based policies for your infrastructure. Sentinel is an embedded policy-as-code framework integrated with the HashiCorp Enterprise products. | [Enforce Policy with Sentinel](https://learn.hashicorp.com/collections/terraform/policy) | - - -## Develop Terraform Providers - -|Name | Maintainer |Description| Tutorial | -|-----|------------|-----------|----------| -| [Plugin SDK](/plugin/sdkv2) | HashiCorp | Develop your own Terraform providers. | [Setup and Implement Read](https://learn.hashicorp.com/tutorials/terraform/provider-setup?in=terraform/providers) | -|[Plugin Framework](/plugin/framework) | HashiCorp | A new SDK to develop your own Terraform providers. The framework provides improvements and additional features beyond what is available in the Plugin SDK. | [Implement Create and Read with the Terraform Plugin Framework](https://learn.hashicorp.com/tutorials/terraform/plugin-framework-create?in=terraform/providers) | -|[`terraform-plugin-mux`](https://github.com/hashicorp/terraform-plugin-mux)| HashiCorp | Combine providers built using different SDKs and frameworks. This lets you upgrade between SDKs or frameworks on a resource-by-resource basis instead of all at once. | | -| [`terraform-plugin-go`](https://github.com/hashicorp/terraform-plugin-go) | HashiCorp | Use low-level Go bindings for the Terraform plugin protocol as a foundation for integrations. | | -| [`terraform-plugin-go-contrib`](https://github.com/hashicorp/terraform-plugin-go-contrib) | HashiCorp | Use this set of common code packages with `terraform-plugin-go`. | | -| [`terraform-plugin-log`](https://github.com/hashicorp/terraform-plugin-log) | HashiCorp | Attach context and information to logs and use multiple loggers to filter log output. | | - - -## HashiCorp Products -You can use HashiCorp products together to enable self-service automation across teams and organizations. - -|Name | Maintainer | Description| Tutorial | -|-----|------------|-----------|----------| -| [HashiCorp Cloud Platform (HCP) Provider](https://registry.terraform.io/providers/hashicorp/hcp/latest) | HashiCorp | Launch and run HashiCorp products as managed services that will be deployed into HashiCorp Virtual Networks (HVNs) and connected to your infrastructure resources. | | -| [Vault provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) | HashiCorp | [Vault](https://www.vaultproject.io/) lets you secure, store, and tightly control access to tokens, passwords, certificates, encryption keys, and other sensitive data. Use this provider to read from, write to, and configure Vault. | [Inject Secrets into Terraform Using the Vault Provider](https://learn.hashicorp.com/tutorials/cloud/terraform-hcp-provider-vault)| -|[Consul Provider](https://registry.terraform.io/providers/hashicorp/consul/latest) | HashiCorp | [Consul](https://www.consul.io/) provides service-based networking for dynamic infrastructure. Use this provider to add external services to Consul, work with the key/value store, and more, using Terraform. | [Use Terraform to Register External Services](https://learn.hashicorp.com/tutorials/consul/terraform-consul-provider)| -|[HashiCorp Consul Service (HCS)](https://registry.terraform.io/providers/hashicorp/hcs/latest) | HashiCorp | Provision HashiCorp-managed Consul clusters directly through the Azure Marketplace. | | -| [HCP Packer registry](https://cloud.hashicorp.com/docs/packer) | HashiCorp | [Packer](https://www.packer.io/) lets you create identical machine images for multiple platforms from a single source template. Use the registry to track golden images, designate images for test and production environments, and query images to use in both Packer and Terraform configurations. | [Push Image Metadata to the HCP Packer Registry](https://learn.hashicorp.com/tutorials/packer/hcp-push-image-metadata) | -|[Boundary Provider](https://registry.terraform.io/providers/hashicorp/boundary/latest) | HashiCorp | [Boundary](https://www.boundaryproject.io/) is an intelligent proxy that creates granular, identity-based access controls for dynamic infrastructure. Use this provider to manage Boundary access controls for resources provisioned with Terraform. | | -| [Nomad AWS Module](https://registry.terraform.io/modules/hashicorp/nomad/aws/latest) | Third Party | [Nomad](https://www.nomadproject.io/) is a distributed, highly-available, data-center aware scheduler. Use Terraform to deploy a Nomad cluster on Amazon Web Services (AWS). | - - - diff --git a/website/img/docs/provider-program-steps.png b/website/img/docs/provider-program-steps.png deleted file mode 100644 index 440d7b00a4..0000000000 Binary files a/website/img/docs/provider-program-steps.png and /dev/null differ diff --git a/website/img/docs/runtask-diagram.png b/website/img/docs/runtask-diagram.png deleted file mode 100644 index 36cfaef2ac..0000000000 Binary files a/website/img/docs/runtask-diagram.png and /dev/null differ diff --git a/website/img/docs/runtask-program-steps.png b/website/img/docs/runtask-program-steps.png deleted file mode 100644 index f183f7e1bd..0000000000 Binary files a/website/img/docs/runtask-program-steps.png and /dev/null differ diff --git a/website/img/docs/terraform-integration-program-diagram.png b/website/img/docs/terraform-integration-program-diagram.png deleted file mode 100644 index 7135a97f7f..0000000000 Binary files a/website/img/docs/terraform-integration-program-diagram.png and /dev/null differ