Adding links and copy to Terraform roadmap (#5914)
* Adding links and copy to Terraform roadmap * added hcl content * add resource topic content * add tf meta-argument content and copy * add content for variables and outputs * added more links to areas that are lacking * Apply suggestions from code review Corrected stylingpull/6026/head
parent
b7b8a935c1
commit
1ebf850882
27 changed files with 215 additions and 27 deletions
@ -1 +1,7 @@ |
||||
# Basic Syntax |
||||
|
||||
The Basic Syntax of HashiCorp Configuration Language (HCL) includes defining blocks, attributes, and expressions. Blocks are fundamental units like `resource`, `module`, and `provider`, identified by keywords and enclosed in curly braces. Attributes are key-value pairs within blocks, where keys are strings and values can be strings, numbers, or other data types. Expressions allow embedding variables, functions, and references to other resources, enabling dynamic configurations. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@opensource@HCL Native Syntax Specification](https://github.com/hashicorp/hcl/blob/main/hclsyntax/spec.md) |
@ -1,3 +1,8 @@ |
||||
# CaC vs IaC |
||||
|
||||
CaC (Configuration as Code) and IaC (Infrastructure as Code) are both ways to manage infrastructure resources, but they focus on different things. CaC deals with setting up and managing the software and settings within your servers, like user settings and app configs. Examples of CaC tools include Ansible and Puppet. IaC, on the other hand, is about managing the underlying infrastructure, like virtual machines, networks, and storage. Examples of IaC tools include Terraform and AWS CloudFormation. So, while IaC sets up the environment, CaC ensures the software within that environment runs correctly. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@video@ Ansible vs. Terraform: What's the difference?](https://www.youtube.com/watch?v=rx4Uh3jv1cA) |
||||
- [@article@IaC vs CaC](https://medium.com/@cloudhacks_/infrastructure-as-code-iac-vs-configuration-as-code-cac-unraveling-the-differences-24fbce05ae25) |
@ -1 +1,8 @@ |
||||
# Configuring Providers |
||||
|
||||
Configuring providers in Terraform involves specifying the required provider in the `provider` block within your Terraform configuration files. This block includes settings such as authentication credentials, region, and other provider-specific parameters. Providers must be initialized using `terraform init` to download and install the necessary plugins. Multiple configurations can be managed by aliasing providers, enabling resource management across different environments or accounts within the same provider. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Providers Overview](https://developer.hashicorp.com/terraform/language/providers#providers) |
||||
- [@article@How To Use Terraform Providers](https://www.env0.com/blog/how-to-use-terraform-providers) |
||||
|
@ -1 +1,11 @@ |
||||
# count |
||||
|
||||
The count meta-argument in Terraform allows you to specify the number of instances of a particular resource to create. By setting count to a numeric value, Terraform dynamically generates multiple instances of the resource, indexed from 0 to count-1. This is useful for managing infrastructure that requires multiple identical or similar resources, such as creating multiple virtual machines or storage buckets. Using count, you can conditionally create resources by setting the value based on variables or expressions, making your configurations more flexible and reducing redundancy. Each instance of the resource can be uniquely referenced using the count.index value, enabling more granular control and customization of each resource instance. |
||||
|
||||
Note: You cannot delare count and for_each on the same resource. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Docs - count](https://developer.hashicorp.com/terraform/language/meta-arguments/count) |
||||
- [@article@Terraform by Example - count](https://www.terraformbyexample.com/count) |
||||
- [@video@Conditional blocks in Terraform using count](https://www.youtube.com/watch?v=RVoIqWkN_gI) |
||||
|
@ -1 +1,9 @@ |
||||
# depends_on |
||||
|
||||
The depends_on meta-argument in Terraform is used to explicitly declare dependencies between resources, ensuring that one or more resources are created or destroyed only after the specified dependent resources have been successfully applied. This is crucial for managing resource dependencies that are not automatically detected by Terraform’s implicit dependency analysis. By using depends_on, you can enforce the correct order of resource creation, modification, or destruction, which is particularly useful in complex infrastructure setups where certain resources must exist or be configured before others can be effectively managed. This meta-argument enhances the reliability and predictability of your Terraform configurations |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Docs - depends_on](https://developer.hashicorp.com/terraform/language/meta-arguments/depends_on) |
||||
- [@article@How to Use Terraform depends_on](https://spacelift.io/blog/terraform-depends-on) |
||||
- [@video@How to use Terraform depends_on meta tag?](https://www.youtube.com/watch?v=v0Qt-ltvmXU) |
||||
|
@ -1 +1,11 @@ |
||||
# for_each |
||||
|
||||
The for_each meta-argument in Terraform enables you to create multiple instances of a resource based on a set or map. Unlike count, which uses a simple integer, for_each allows for more granular and dynamic resource creation, as each instance is associated with a specific key-value pair from the given set or map. This meta-argument is particularly useful for creating resources with unique configurations derived from the keys and values of the set or map. By leveraging for_each, you can manage collections of resources more efficiently, ensuring each instance can be individually referenced and customized based on its specific key. |
||||
|
||||
Note: You cannot declare for_each and count in the same resource. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Docs - for_each](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each) |
||||
- [@article@Terraform by Example - for_each](https://www.terraformbyexample.com/for_each) |
||||
- [@video@Terraform for loops](https://www.youtube.com/watch?v=4qO7WK6D3cA) |
||||
|
@ -1,3 +1,8 @@ |
||||
# HashiCorp Configuration Language (HCL) |
||||
|
||||
HashiCorp Configuration Language (HCL) is a configuration language built by HashiCorp that is used for configuring products in the HashiCorp ecosystem. With its human-readable style, HCL is designed to strike a balance between a generic configuration language like JSON or YAML and a high-level scripting language. In relation to the Terraform Roadmap, HCL is the primary language used for writing Terraform configuration files, thus making it a fundamental part of defining and providing data center infrastructure in a descriptive manner. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Language Documentation(https://developer.hashicorp.com/terraform/language) |
||||
- [@opensource@HCL Repository](https://github.com/hashicorp/hcl) |
@ -1 +1,9 @@ |
||||
# Input Variables |
||||
|
||||
Terraform input variables are parameters for modules, declared using variable blocks. They support multiple data types, default values, and descriptions. Users provide values when invoking modules or running Terraform. Accessed via `var.<name>` syntax, input variables enable flexible, reusable infrastructure templates adaptable to various deployment scenarios. They can be marked sensitive for security and are typically defined in a `variables.tf` file. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Define Input Variables](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-variables) |
||||
- [@article@Terraform Input and Output Variables Explained](https://kodekloud.com/blog/terraform-variables-explained/) |
||||
- [@video@Terraform Basics: Input Variables](https://www.youtube.com/watch%3Fv%3D2f65JhfYmIo) |
@ -1 +1,9 @@ |
||||
# lifecycle |
||||
|
||||
The lifecycle meta-argument in Terraform customizes the behavior of resources during creation, update, and deletion. It includes settings such as create_before_destroy, which ensures a new resource is created before the old one is destroyed, preventing downtime. prevent_destroy protects resources from accidental deletion, and ignore_changes specifies attributes to ignore during updates, allowing external modifications without triggering Terraform changes. These options provide fine-grained control over resource management, ensuring that the desired state of infrastructure is maintained with minimal disruption and precise handling of resource lifecycles. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Docs - for_each](https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle) |
||||
- [@article@Terraform Resource Lifecycle](https://spacelift.io/blog/terraform-resource-lifecycle) |
||||
- [@article@Understanding the Lifecycle Block](https://dev.to/pwd9000/terraform-understanding-the-lifecycle-block-4f6e) |
@ -1 +1,9 @@ |
||||
# Meta Arguments |
||||
|
||||
Meta-arguments in Terraform resources provide additional control over how resources are managed and interact within the configuration. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@article@Meta Arguments in Terraform](https://muditmathur121.medium.com/meta-arguments-in-terraform-aaaa6e3734e6) |
||||
- [@article@Terraform Meta-Arguments](https://www.devopsschool.com/blog/terraform-tutorials-meta-arguments/) |
||||
- [@video@Resource Meta Arguments](https://www.youtube.com/watch?v=7JraLCfroyE) |
@ -1 +1,9 @@ |
||||
# Outputs |
||||
|
||||
Terraform outputs expose selected values from a configuration or module, making them accessible to users or other modules. Defined in output blocks, typically in an `outputs.tf` file, they can reference resource attributes or other computed values. Outputs are displayed after apply operations, can be queried using terraform output commands, and are crucial for passing information between modules or to external systems. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Output Values](https://developer.hashicorp.com/terraform/language/values/outputs) |
||||
- [@article@Terraform Output Values](https://spacelift.io/blog/terraform-output) |
||||
- [@video@Learn Terraform Outputs in 4 Minutes](https://www.youtube.com/watch?v=i-Ky1Tut_2I) |
@ -1 +1,8 @@ |
||||
# Preconditions |
||||
|
||||
Terraform preconditions are declarative checks within resource or data blocks that validate configuration or state before Terraform attempts to create or modify resources. They use condition arguments to specify logical tests and `error_message` arguments for custom failure notifications. Preconditions help catch misconfigurations early, enforce business rules, and ensure dependencies are met before resource operations. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Custom Condition Checks](https://developer.hashicorp.com/terraform/language/values/outputs#custom-condition-checks) |
||||
- [@video@ Using Precondition and Postcondition Blocks in Terraform](https://www.youtube.com/watch?v=55ZLu8tSnvk) |
@ -1 +1,10 @@ |
||||
# Project Initialization |
||||
|
||||
Project initialization in Terraform involves setting up the necessary configuration files and directory structure for managing infrastructure as code. The `terraform init` command is crucial in this process, as it initializes the working directory, downloads the required provider plugins, and sets up the backend configuration for storing state files. This command ensures that the project is correctly configured and ready for subsequent Terraform commands, laying the foundation for efficient and organized infrastructure management. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
-[@official@Init Command](https://developer.hashicorp.com/terraform/cli/commands/init) |
||||
- [@official@Initialize Terraform Configuration](https://developer.hashicorp.com/terraform/tutorials/cli/init) |
||||
- [@article@Terraform Init](https://spacelift.io/blog/terraform-init) |
||||
- [@video@Learn Terraform: The Init Command](https://www.youtube.com/watch?v=82lsMLqWjS4) |
@ -1 +1,8 @@ |
||||
# provider |
||||
|
||||
The `provider` meta-argument in Terraform specifies which provider configuration to use for a resource, overriding the default provider selection based on the resource type name. This is useful in scenarios where multiple configurations of the same provider are required, such as managing resources across different regions or environments. By setting the `provider` argument, you can ensure that the resource uses the specified provider setup, identified by its alias, enhancing control and flexibility in multi-provider or multi-region deployments. This meta-argument is essential for precisely directing Terraform on how to interact with the underlying infrastructure provider. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Docs - for_each](https://developer.hashicorp.com/terraform/language/meta-arguments/resource-provider) |
||||
- [@article@Terraform by Example - for_each](https://www.terraformbyexample.com/providers/) |
@ -1 +1,9 @@ |
||||
# Providers |
||||
|
||||
Terraform Providers are plugins that enable interaction with various external APIs. They manage the lifecycle of resources by defining resource types and data sources. Each provider requires configuration, typically including authentication details and endpoint URLs. Providers are specified in the `provider` block, and multiple providers can be used in a single Terraform project to manage resources across different platforms. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Providers Documentation](https://developer.hashicorp.com/terraform/language/providers#providers) |
||||
- [@article@Understanding Terraform Providers](https://docs.aws.amazon.com/prescriptive-guidance/latest/getting-started-terraform/providers.html) |
||||
- [@video@ What are terraform providers and how to use them?](https://www.youtube.com/watch?v=Kd7ddHBR2ec) |
@ -1 +1,8 @@ |
||||
# Resource Behavior |
||||
|
||||
Resource behavior encompasses how resources are managed, created, updated, and destroyed according to the configuration specified in Terraform files. Each resource block specifies desired attributes, and Terraform ensures that the real-world infrastructure matches these specifications. If writing a configuration for the first time, the resources defined will only exist in the configuration and will not be reflected on the target platform until applied. When a configuration is applied, Terraform generates an execution plan, determining the actions required to reach the desired state, such as creating new resources, updating existing ones, or deleting resources no longer needed. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Behaviour](https://developer.hashicorp.com/terraform/language/resources/behavior) |
||||
- [@article@Terraform Resource Syntax, Behavior and State](https://terraformguru.com/terraform-certification-using-azure-cloud/09-Resource-Syntax-and-Behavior/) |
@ -1 +1,8 @@ |
||||
# Resources |
||||
|
||||
Resources represent components of your infrastructure such as Virtual Machines, Storage Buckets, Databases or Virtual Private Clouds. Access to provider resources comes after successful project initalization after declaring your desired providers. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Resource Blocks](https://developer.hashicorp.com/terraform/language/resources/syntax) |
||||
- [@video@Define Infrastructure With Terraform Resources](https://developer.hashicorp.com/terraform/tutorials/configuration-language/resource) |
||||
|
@ -1 +1,9 @@ |
||||
# Terraform Registry |
||||
|
||||
The Terraform Registry is a centralized repository for discovering, sharing, and using Terraform modules and providers. It allows users to browse and download pre-built configurations, enabling quick integration of best practices. The registry supports versioning, ensuring consistent deployments, and includes detailed documentation for each module and provider. Users can also publish their own modules to the registry, facilitating community collaboration and reuse. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Terraform Registry](https://registry.terraform.io/) |
||||
- [@article@Terraform Registry Guide](https://spacelift.io/blog/terraform-registry) |
||||
- [@video@Terraform Registry Providers and Modules](https://www.youtube.com/watch?v=q4VdvS8aXnc) |
@ -1 +1,8 @@ |
||||
# Type Constraints |
||||
|
||||
Terraform variable type constraints specify allowed data types for input variables. They include primitive types (string, number, bool), complex types (list, set, map, object), and any for unspecified types. Constraints can enforce specific structures, nested types, or value ranges. They're defined in the variable block's type argument, helping catch errors early and ensuring correct variable usage throughout configurations. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Variable Type Contraints](https://developer.hashicorp.com/terraform/language/expressions/type-constraints) |
||||
- [@video@Terraform Type Constraints](https://www.youtube.com/watch?v=hNZiZEQfV4Q) |
@ -1,3 +1,9 @@ |
||||
# Benefits of Terraform |
||||
|
||||
Using Terraform offers numerous benefits. It allows you to define your infrastructure as code (IaC), making it human-readable, versioned, and shareable. Its multi-cloud support means you can manage resources consistently across various cloud providers and on-premises environments. By automating infrastructure provisioning and management, Terraform reduces manual errors and speeds up deployments. Version control integration ensures you can track changes, roll back when needed, and collaborate effectively with team members. Terraform's use of templates and modules ensures configuration consistency and reusability across projects and environments, while its state management capabilities keep track of existing resources for efficient updates. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Use Cases](https://developer.hashicorp.com/terraform/intro/use-cases#use-cases) |
||||
- [@article@9 Terraform Use Cases for Your Infrastructure as Code](https://spacelift.io/blog/terraform-use-cases) |
||||
- [@video@What are the Benefits of Using Terraform?](https://www.youtube.com/watch?v=0M4IvedbLJ4) |
@ -1 +1,8 @@ |
||||
# Variable Definition File |
||||
|
||||
A Terraform `variables.tf` file centralizes input variable declarations for a module or configuration. It typically contains multiple variable blocks, each defining a single input variable with its name, type constraint, optional default value, and description. This file serves as a single reference point for all variables used in the configuration, enhancing readability and maintainability. While not mandatory, using `variables.tf` is a common practice to organize and document a module's expected inputs. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Parameterize Your Configuration](https://developer.hashicorp.com/terraform/tutorials/configuration-language/variables#parameterize-your-configuration) |
||||
- [@video@You should be using tfvars vs variables in Terraform](https://www.youtube.com/watch?v=BHWM4D2GJvI) |
@ -1 +1,9 @@ |
||||
# Variables |
||||
|
||||
Terraform uses variables to make configurations more flexible and reusable. Variables can be declared in `.tf` files and assigned values through various methods, including default values, command-line flags, environment variables, or separate `.tfvars` files. They support multiple data types such as string, number, bool, list, and map. Variables can be referenced throughout the configuration using the `var` prefix. This system enables infrastructure as code to be more dynamic and adaptable to different environments or use cases. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Input Variables](https://developer.hashicorp.com/terraform/language/values/variables) |
||||
- [@article@How To Use Terraform Variables](https://spacelift.io/blog/how-to-use-terraform-variables) |
||||
- [@video@Learn How to Use Terraform Variable](https://www.youtube.com/watch?v=oArutYYvQ_Y) |
||||
|
@ -1 +1,7 @@ |
||||
# Versions |
||||
|
||||
Specifying provider versions in Terraform ensures consistent and predictable behavior across different environments. Instead of using the `version` meta-argument within the provider block, which was deprecated and removed in Terraform 0.13, provider version constraints should now be defined in the `required_providers` block. This approach prevents unexpected changes or compatibility issues due to provider updates, enhancing stability and reliability in infrastructure management. It allows you to control when and how provider updates are applied, ensuring that your infrastructure code runs with the expected provider functionality. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@Requiring Providers](https://developer.hashicorp.com/terraform/language/providers/requirements#requiring-providers) |
@ -1,3 +1,4 @@ |
||||
# What is HCL? |
||||
|
||||
HCL, or HashiCorp Configuration Language, is a human-readable language for DevOps tools. It is used to code infrastructure management and service orchestration in a clear and manageable way. Several HashiCorp products, including Terraform, use HCL as their primary configuration language. Terraform uses HCL to provision and manage cloud resources efficiently. Its clear syntax and structure are instrumental in creating resource modules and configurations that align with the Terraform Roadmap's goals for providing a seamless, user-friendly platform for infrastructure as code. |
||||
|
||||
|
@ -1 +1,9 @@ |
||||
# What is Infrastructure as Code? |
||||
|
||||
Infrastructure as Code (IaC) is a practice in DevOps and cloud computing that involves managing and provisioning computing infrastructure through machine-readable configuration files, rather than through physical hardware configuration or interactive configuration tools. This approach allows for version control, automation, and consistency in infrastructure deployment, making it easier to manage, scale, and replicate environments while reducing the risk of human error. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@article@What Is It? Why Is It Important?](https://www.hashicorp.com/resources/what-is-infrastructure-as-code) |
||||
- [@article@What is Infrastructure as Code?](https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac) |
||||
- [@video@What is Infrastructure as Code?](https://www.youtube.com/watch?v=zWw2wuiKd5o) |
@ -1,3 +1,9 @@ |
||||
# What is Terraform? |
||||
|
||||
Terraform is a powerful tool designed by HashiCorp that helps you set up, manage, and update infrastructure safely and efficiently across various cloud providers. Think of it as a way to define your cloud resources—like servers, storage, and networks—using a simple code format. This makes it easier to automate, share, and manage your infrastructure, ensuring that everything is consistent and can be quickly reproduced or modified as needed. |
||||
|
||||
Learn more from the following resources: |
||||
|
||||
- [@official@What is Terraform?](https://developer.hashicorp.com/terraform/intro#what-is-terraform) |
||||
- [@article@What is Terraform?](https://www.varonis.com/blog/what-is-terraform) |
||||
- [@video@What is Terraform? Terraform Explained in 2 Minutes](https://www.youtube.com/watch?v=lIaUz2GAqEQ) |
Loading…
Reference in new issue