Up and Down
terraspace up and
terraspace down commands are how you create infrastructure with Terraspace. The
terraspace up ultimately calls
terraform apply and
terraspace down calls
terraform destroy. Before calling the terraform commands, terraspace does additional processing. For example, terraspace will build common source code files from config/terraform along with the deployed module.
Modules vs Stacks
Both modules and stacks are terraform modules. The difference is organizational and how they are can be used.
- Modules are reusable pieces of code. Generally, it contains non-business specific logic.
- Stacks can be used to group together modules. Generally, this is where more business-specific logic can go.
For example, the
app1 stack could be designed to use an
instance module. Another,
app2 stack could use an
There are no hard rules. Stacks can be reusable and you provide the tfvars config. It’s up to you. Here are some more Tfvars Location Thoughts.
Conventions Over Configuration
Terraspace uses Conventions Over Configuration to remove boilerplate setup and mental overhead. The
config/terraform are where you organized your code by convention and it should just work. You also put Tfvars files in conventional folders and Terraspace will automatically use them. The “batteries are included but replaceable” You can override things as necessary.
Terraspace introduces Tfvars Layering. You can use the same infrastructure code with different tfvar files to create multiple environments like dev, prod, uat, stage, etc. Layering DRYs up the usage of multiple tfvar files. Additionally, Layering allows you to use same infrastructure code to deploy to multiple regions and or accounts.
Terraspace ships with a testing framework. It allows you to test with real resources. The testing works by creating a “test harness”, which is a generated terraspace project. Then
terraspace up is ran. It’s what you would normally do manually, but automated.