You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/terraform/v1.13.x/docs/language/stacks/design.mdx
+1-8Lines changed: 1 addition & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,19 +5,14 @@ description: Learn how to design a Stack that aligns with your existing infrastr
5
5
6
6
# Design a Stack
7
7
8
-
Stacks allow you to break down your existing infrastructure into logical components, making it easier to deploy and manage as a cohesive system. Designing a Stack begins with planning how to structure your infrastructure and thinking about how you intend to deploy the resources your Stack defines.
9
8
Stacks let you break down your existing infrastructure into logical components, making it easier to deploy and manage as a cohesive system. Designing a Stack begins with planning how to structure your infrastructure and thinking about how you intend to deploy the resources your Stack defines.
10
9
11
10
## Background
12
11
13
-
Every Stack requires two files: a Stack configuration file and a deployment configuration file. The Stack configuration file defines the infrastructure your Stack will provisi
8000
on when you deploy it. The deployment configuration files are where you define how many times to deploy the infrastructure your Stack defines.
14
12
Every Stack requires two files: a component configuration file and a deployment configuration file. The component configuration file defines the infrastructure your Stack provisions when you deploy it. The deployment configuration file is where you define how many times to deploy the infrastructure your Stack defines.
15
13
16
14
Before writing your component configuration, we recommend planning and designing how you want to use your new Stack:
17
15
18
-
* Understand your existing infrastructure and break it down into manageable components.
19
-
* Understand how you want to deploy the infrastructure your Stack defines.
20
-
* Align your Stack’s component organization with your deployment strategy.
21
16
- Understand your existing infrastructure and break it down into manageable components.
22
17
- Understand how you want to deploy the infrastructure your Stack defines.
23
18
- Align your Stack’s component organization with your deployment strategy.
@@ -30,14 +25,12 @@ Before writing your component configuration, we recommend assessing your current
30
25
31
26
### Break down your infrastructure
32
27
33
-
Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together.
34
28
Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together.
35
29
36
30
We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation lets you to manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
37
31
38
32
### Sketch out your configuration
39
33
40
-
We recommend sticking to technical boundaries when structuring a Stack configuration. A single Stack should represent a single system with a shared lifecycle.
41
34
We recommend sticking to technical boundaries when structuring a component configuration. A single Stack should represent a single system with a shared lifecycle.
42
35
43
36
While keeping a Stack as self-contained as possible is ideal, there are valid cases where a Stack must consume outputs from another Stack. For example, a shared networking Stack can publish outputs, such as `vpc_id` or subnet IDs, that downstream application Stacks can consume as inputs. This approach ensures modularity and lets you to manage dependencies between Stacks using well-defined interfaces. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
@@ -67,7 +60,7 @@ locals {
67
60
68
61
</CodeBlockConfig>
69
62
70
-
Additionally, using meta-arguments like `for_each` in your configuration can help streamline the creation of multiple components, making your configuration more flexible and scalable. Refer to the [`component` block documentation](/terraform/language/block/stack/tfcomponent_configuration/component#for_each) for more details.
63
+
Additionally, using meta-arguments like `for_each` in your configuration can help streamline the creation of multiple components, making your configuration more flexible and scalable. Refer to the [`component` block documentation](/terraform/language/block/stack/tfcomponent/component#for_each) for more details.
Copy file name to clipboardExpand all lines: content/terraform/v1.13.x/docs/language/stacks/use-cases.mdx
-5Lines changed: 0 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,13 +5,9 @@ description: Learn about example use cases to better understand how to use Stack
5
5
6
6
# Use Cases
7
7
8
-
Stacks provide a way to define, organize, and reuse components and then deploy the infrastructure those components describe consistently across different deployments.
9
8
Stacks provide a way to define, organize, and reuse components and then deploy the infrastructure those components describe consistently across different deployments.
10
9
11
10
Stacks are ideal for the following situations:
12
-
* Managing infrastructure with a common lifecycle, such as a microservices architecture where HCP Terraform needs to deploy multiple services together.
13
-
* Repeating infrastructure across different environments, regions, or accounts that require consistent and synchronized deployments.
14
-
* Tightly orchestrating infrastructure changes across different environments. Stacks help you manage your dependencies and ensure Terraform creates resources in the correct order.
15
11
- Managing infrastructure with a common lifecycle, such as a microservices architecture where HCP Terraform needs to deploy multiple services together.
16
12
- Repeating infrastructure across different environments, regions, or accounts that require consistent and synchronized deployments.
17
13
- Tightly orchestrating infrastructure that changes across different environments. Stacks help you manage your dependencies and ensure Terraform creates resources in the correct order.
@@ -100,7 +96,6 @@ By default, HCP Terraform notices that you changed your configuration and will c
100
96
## Deploy across regions
101
97
102
98
For global applications, deploying infrastructure across multiple cloud regions is often necessary to ensure low latency and high availability. Stacks enable you to manage cross-region deployments with a unified configuration, ensuring that HCP Terraform sets up each region consistently while allowing for region-specific customization.
103
-
For global applications, deploying infrastructure across multiple cloud regions is often necessary to ensure low latency and high availability. Stacks enable you to manage cross-region deployments with a unified configuration, ensuring that HCP Terraform sets up each region consistently while enabling region-specific customization.
104
99
105
100
For example, if you want to deploy the same environment to two different regions, you could set up your deployments to be region-specific.
0 commit comments