-
Notifications
You must be signed in to change notification settings - Fork 131
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #7 from hashicorp/mg_no_code_prov
No-Code Provisioning Docs
- Loading branch information
Showing
8 changed files
with
179 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
50 changes: 50 additions & 0 deletions
50
website/docs/cloud-docs/no-code-provisioning/module-design.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| --- | ||
| page_title: Designing No-Code Ready Modules - No-Code Provisioning - Terraform Cloud | ||
| description: No-code ready modules let users deploy a module's resources without writing configuration. Prepare modules for no-code ready provisioning. | ||
| --- | ||
|
|
||
| # Designing No-Code Ready Modules | ||
|
|
||
| -> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). | ||
|
|
||
| Terraform [modules](/language/modules) let you define standardized collections of infrastructure resources that downstream users can more easily deploy. No-code ready modules build on these advantages by letting users deploy a module's resources without writing any Terraform configuration. This practice is called no-code provisioning. | ||
|
|
||
| No-code provisioning enables a self-service workflow that lets users provision approved collections of resources without learning Terraform or infrastructure best practices. You can enable no-code provisioning for any public or private module in your [private registry](/cloud-docs/registry). Users can then [provision no-code infrastructure](/cloud-docs/no-code-provisioning/provisioning), set the module's input variables, and deploy its resources. | ||
|
|
||
| > **Hands On:** Try the [Create and Use No-Code Ready Modules tutorial](https://learn.hashicorp.com/tutorials/terraform/no-code-provisioning). | ||
| The same best practices apply to both standard and no-code ready module design. However, no-code modules have additional requirements and considerations. | ||
|
|
||
| ## Requirements | ||
|
|
||
| A no-code ready module must meet the following requirements: | ||
| - **Root Module Structure:** The module must follow [standard module structure](/language/modules/develop/structure) and define its resources in the root directory of the repository. This structure allows the public and private registries to generate documentation, track resource usage, and parse submodules and examples. | ||
| - **Provider Configuration:** A no-code ready module must declare the required provider(s) directly in the module. This configuration differs from the recommendations for [modules used in written configuration](/language/modules/develop/providers#legacy-shared-modules-with-provider-configurations). | ||
|
|
||
| ### Provider credentials | ||
|
|
||
| Organization administrators must determine how no-code workspaces access credentials for provider authentication and design modules accordingly. | ||
|
|
||
| When module consumers follow the no-code workflow, Terraform Cloud automatically creates a new workspace for the resources and attempts to provision them. New workspaces must be able to access credentials for all providers defined within the module. | ||
|
|
||
| You can grant new no-code workspace provider credentials using one of the following methods: | ||
|
|
||
| - Create a [global variable set](/cloud-docs/workspaces/variables/managing-variables#variable-sets) that Terraform Cloud applies to all existing and future workspaces in the organization. This action automatically grants newly-created workspaces access to the required provider credentials. | ||
| - Expose provider credentials as sensitive outputs in another workspace. You must add additional configuration to the module to access these values through [remote state data sources](/language/state/remote-state-data) and then reference them in provider configuration. This approach provides more control over access to these credentials than placing them in a global variable set. | ||
| - Elect to let the first run in new no-code workspaces fail and have module users add credentials directly to the workspace after creation. This approach provides the most control over access to provider credentials, but requires manual intervention. Module users must manually start a new run to provision infrastructure after they configure the credentials. | ||
|
|
||
| ## Module Design Recommendations | ||
|
|
||
| Similarly to a [standard module](/language/modules/develop#when-to-write-a-module), a well-designed no-code ready module composes resources so that they are easy for others to deploy. However, no-code module users are less familiar with Terraform, so we recommend the following best practices for no-code module design. | ||
|
|
||
| ### Build For a Specific Use Case | ||
|
|
||
| No-code ready module users are typically less familiar with Terraform and infrastructure management. Reduce the amount of technical decision-making required to deploy the module by scoping it to a single, specific use case. This approach lets users focus on business concerns instead of infrastructure concerns. | ||
|
|
||
| For example, you could build modules that satisfy the following well-scoped use cases: | ||
| - Deploying all resources needed for a three-tier web application | ||
| - Deploying a database with constraints on resource allocation and deployment region | ||
|
|
||
| ### Provide Variable Defaults When Possible | ||
|
|
||
| The no-code provisioning workflow prompts users to set values for the module's input variables before creating the new workspace and deploying resources. We recommend setting reasonable defaults when possible to reduce the effort and expertise needed to deploy the module. Remember that the workspace can also access variable values set through global variable sets in your organization. |
54 changes: 54 additions & 0 deletions
54
website/docs/cloud-docs/no-code-provisioning/provisioning.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| --- | ||
| page_title: No-Code Provisioning - Provisioning No-Code Infrastructure | ||
| description: How to provision infrastructure from a no-code ready module. | ||
| --- | ||
|
|
||
| # Provisioning No-Code Infrastructure | ||
|
|
||
| -> **Note:** No-code provisioning is in beta and available in the [Terraform Cloud Business tier](https://www.hashicorp.com/products/terraform/pricing). | ||
|
|
||
| No-code provisioning lets you deploy infrastructure resources in a new Terraform Cloud workspace without writing any Terraform configuration. You can create a no-code workspace from any module labeled **No-code Ready** in your organization's [private registry](/cloud-docs/registry). | ||
|
|
||
| The no-code provisioning workflow is best for quickly deploying relatively static infrastructure. Beyond changing variable values, you cannot apply configuration changes to existing no-code workspaces. If you need to deploy updates to the no-code ready module's configuration, you must create new no-code workspaces with new resources. We recommend standard modules for use cases that require dynamic configuration and development. | ||
|
|
||
| > **Hands On:** Try the [Create and Use No-Code Ready Modules tutorial](https://learn.hashicorp.com/tutorials/terraform/no-code-provisioning). | ||
| ## Permissions | ||
|
|
||
| To use no-code provisioning, you need permissions to [manage workspaces](/cloud-docs/users-teams-organizations/permissions#manage-workspaces). | ||
|
|
||
| ## Provider Credentials | ||
|
|
||
| Terraform automatically starts a new run to provision no-code infrastructure upon workspace creation. No-code modules contain provider blocks in their configuration, but still require provider credentials for successful deployment. Organization administrators determine how new workspaces should [access provider credentials](/cloud-docs/no-code-provisioning/module-design#provider-credentials), which may require specific module design. | ||
|
|
||
| ## Creating a Workspace and Deploying Resources | ||
|
|
||
| The no-code provisioning workflow creates a new Terraform Cloud workspace to deploy and manage the no-code ready module's resources. Terraform Cloud automatically starts a run to provision the module's resources in the new workspace. Depending on the workspace's settings, Terraform either automatically applies the plan or prompts you for approval to provision the infrastructure. | ||
|
|
||
| To launch the no-code workflow: | ||
|
|
||
| 1. Click **Registry** in the main Terraform Cloud navigation to access your organization's private registry. | ||
|
|
||
| 1. Click **Modules** to view the list of available modules in the private registry. You can filter for no-code ready modules in your registry. No-code enabled modules have a **No-code Ready** badge next to their names. | ||
|
|
||
| 1. Select the no-code ready module to view its details, then click **Provision workspace**. The **Configure module inputs** page appears. | ||
|
|
||
| Terraform Cloud scans the module configuration for input variables and prompts for values for any variables without defaults or undefined in an existing global variable set. Terraform requires values for these variables to successfully complete runs in the workspace. Terraform Cloud performs type validation for the variable values if the module configuration specifies a type. | ||
|
|
||
| 1. (Optional) Set values for the input variables. You can choose to skip this step and configure the variables later. However, Terraform Cloud does not prompt you for these values again and your Terraform runs may fail. | ||
|
|
||
| 1. Cick **Next: Workspace settings**. | ||
|
|
||
| 1. Enter a **Workspace Name**. The name must be unique within the organization and can include letters, numbers, dashes (-), and underscores (_). Refer to the [workspace naming recommendations](/cloud-docs/workspaces/naming) for more guidance. | ||
|
|
||
| 1. Add an optional **Description** for the workspace. | ||
|
|
||
| 1. Select an apply method for the workspace. **Auto apply** automatically applies any successful runs in the workspace, including the initial run on workspace creation. **Manual apply** prompts operators to review and confirm the changes in a run. **Auto apply** is the default option for a no-code workspace. | ||
|
|
||
| 1. Click **Create workspace**. Terraform Cloud creates a new workspace and starts a run. Depending on the apply method, it automatically applies your infrastructure or prompts you for approval to create the no-code module's resources. | ||
|
|
||
| ## Operations in No-Code Workspaces | ||
|
|
||
| No-code workspaces have a limited feature set because you cannot access the resource configuration. However, you can edit workspace variables and settings, including notifications, permissions, and run triggers. You can use run triggers to connect the workspace to one or more source workspaces, start new runs when you change workspace variables, or queue destroy runs. | ||
|
|
||
| If the module’s configuration changes, you must destroy the workspace and create a new one to provision resources with the updated configuration. |
Oops, something went wrong.