diff --git a/roadmaps/terraform/content/-replace-option-in-apply@jvHtSRLuCXJrGIiesgbE-.md b/roadmaps/terraform/content/-replace-option-in-apply@jvHtSRLuCXJrGIiesgbE-.md index 221ad421b..c7efd2161 100644 --- a/roadmaps/terraform/content/-replace-option-in-apply@jvHtSRLuCXJrGIiesgbE-.md +++ b/roadmaps/terraform/content/-replace-option-in-apply@jvHtSRLuCXJrGIiesgbE-.md @@ -1,6 +1,6 @@ # -replace option in apply -The `-replace` flag in Terraform is used with the apply or plan command to force the replacement of a specific resource by tainting the resources. This flag instructs Terraform to delete and recreate the specified resource instead of updating it in place. It's useful when you need to regenerate a resource completely, such as when certain attributes can't be modified after creation. The flag is typically used when Terraform can't automatically detect that a resource needs replacement, or when you want to force a replacement for testing or troubleshooting purposes. While powerful, this flag should be used cautiously, especially with stateful resources, as it can lead to data loss. It's often employed in scenarios where in-place updates are not sufficient to achieve the desired configuration state of a resource. +The `-replace` flag on `terraform apply` forces Terraform to destroy and recreate a specific resource even if no configuration changes would normally trigger replacement. It is used to resolve issues with a corrupted or degraded resource that needs to be rebuilt. This replaces the older `taint` command. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/authentication@RPcsyhIG027uP7KF0hwaY.md b/roadmaps/terraform/content/authentication@RPcsyhIG027uP7KF0hwaY.md index 0e05de3c7..78b48c9d8 100644 --- a/roadmaps/terraform/content/authentication@RPcsyhIG027uP7KF0hwaY.md +++ b/roadmaps/terraform/content/authentication@RPcsyhIG027uP7KF0hwaY.md @@ -1,6 +1,6 @@ # Authentication -HCP (HashiCorp Cloud Platform) authentication provides secure access management for its services, including Terraform Cloud. It utilizes a comprehensive identity and access management system that supports multiple authentication methods. These include username/password combinations, single sign-on (SSO) integration with popular identity providers, and API tokens for programmatic access. HCP supports SAML 2.0 for enterprise-grade SSO, allowing seamless integration with existing identity management systems. For machine-to-machine communication, HCP offers service principal authentication, enabling secure, automated interactions with HCP services. The platform also provides fine-grained role-based access control (RBAC), allowing administrators to define and manage user permissions across different resources and operations. +HCP Terraform authenticates users and services through API tokens. User tokens are generated in the account settings and used for CLI access. Service account tokens are used in CI/CD pipelines. The `terraform login` command stores credentials locally for CLI use. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/best-practices-for-state@jas0XILqCUXjWRk3ZoSEO.md b/roadmaps/terraform/content/best-practices-for-state@jas0XILqCUXjWRk3ZoSEO.md index 7a280e9b9..24f969cbe 100644 --- a/roadmaps/terraform/content/best-practices-for-state@jas0XILqCUXjWRk3ZoSEO.md +++ b/roadmaps/terraform/content/best-practices-for-state@jas0XILqCUXjWRk3ZoSEO.md @@ -1,16 +1,6 @@ # Best Practices for State -Terraform state best practices focus on security, consistency, and collaboration. - -* Store state files remotely in encrypted, version-controlled backends like S3 or Terraform Cloud to enable team access and enhance security. -* Implement state locking to prevent concurrent modifications. Use workspaces or separate state files for different environments. -* Regularly back up state files and enable versioning for rollback capabilities. -* Avoid storing sensitive data directly in state; instead, use secret management tools. -* Keep state files separate from your Terraform configuration in version control. -* Utilize state subcommands for maintenance and troubleshooting. Implement access controls to restrict state file access. -* Regularly review and clean up unused resources in the state. - -These practices help maintain a secure, efficient, and manageable Terraform workflow, especially in team environments and complex infrastructures. +State should never be stored in version control, as it may contain sensitive values and is not designed for manual editing. Use a remote backend with locking and versioning enabled. Keep state files small by splitting large configurations into smaller modules with independent state, and run `terraform refresh` carefully as it overwrites state with live data. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/cac-vs-iac@UsINvx84pBF1hp8XoLF4c.md b/roadmaps/terraform/content/cac-vs-iac@UsINvx84pBF1hp8XoLF4c.md index a587f6e90..43509fa75 100644 --- a/roadmaps/terraform/content/cac-vs-iac@UsINvx84pBF1hp8XoLF4c.md +++ b/roadmaps/terraform/content/cac-vs-iac@UsINvx84pBF1hp8XoLF4c.md @@ -1,6 +1,6 @@ # 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. +Configuration as Code (CaC) refers to managing the configuration of existing systems, such as installing software or setting up services on a server. Infrastructure as Code (IaC) refers to provisioning the underlying infrastructure itself, like virtual machines, networks, and storage. Terraform is an IaC tool; tools like Ansible or Chef are typically used for CaC, though there is overlap in practice. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/checkov@ljj7ngl1N4ezCXQ0o6Y8x.md b/roadmaps/terraform/content/checkov@ljj7ngl1N4ezCXQ0o6Y8x.md index c543324a3..a639e6ad7 100644 --- a/roadmaps/terraform/content/checkov@ljj7ngl1N4ezCXQ0o6Y8x.md +++ b/roadmaps/terraform/content/checkov@ljj7ngl1N4ezCXQ0o6Y8x.md @@ -1,6 +1,6 @@ # Checkov -Checkov is an open-source static code analysis tool designed for scanning Infrastructure as Code (IaC) files, including Terraform configurations, for security and compliance issues. It provides a comprehensive set of out-of-the-box policies covering various cloud providers and security best practices. Checkov can identify misconfigurations, security risks, and compliance violations in Terraform code before deployment, helping to shift security left in the development process. The tool supports custom policies written in Python, allowing organizations to enforce specific requirements. Checkov integrates easily into CI/CD pipelines and offers multiple output formats for better reporting and integration with other tools. Its ability to scan for a wide range of issues, from insecure defaults to compliance with standards like CIS Benchmarks, makes it a powerful asset for maintaining secure and compliant infrastructure deployments. +Checkov is a static analysis tool for infrastructure as code that scans Terraform, CloudFormation, Kubernetes, and other formats for security and compliance issues. It includes hundreds of built-in checks covering major cloud providers and supports custom policies written in Python or YAML. Scan results can be output as JUnit XML for integration with CI systems. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/ci--cd-integration@O194eWh529jj4VDhKxNSj.md b/roadmaps/terraform/content/ci--cd-integration@O194eWh529jj4VDhKxNSj.md index 32c8880d4..ceadcbd77 100644 --- a/roadmaps/terraform/content/ci--cd-integration@O194eWh529jj4VDhKxNSj.md +++ b/roadmaps/terraform/content/ci--cd-integration@O194eWh529jj4VDhKxNSj.md @@ -1,5 +1,3 @@ # CI / CD Integration -CI/CD integration with Terraform involves incorporating infrastructure-as-code practices into continuous integration and continuous deployment pipelines. This integration automates the process of planning, validating, and applying Terraform configurations as part of software delivery workflows. - -In a typical setup, CI/CD pipelines run Terraform commands to check syntax, generate plans, and apply changes to infrastructure. This approach ensures that infrastructure changes are versioned, tested, and deployed consistently alongside application code. Key aspects include automated testing of Terraform configurations, secure handling of sensitive data like access keys, and implementing approval processes for infrastructure changes. \ No newline at end of file +Integrating Terraform into a CI/CD pipeline automates infrastructure changes through the same review and deployment process used for application code. A typical pipeline runs `terraform fmt`, `terraform validate`, and `terraform plan` on pull requests, and `terraform apply` on merges to the main branch. Automation reduces human error and enforces a consistent workflow. \ No newline at end of file diff --git a/roadmaps/terraform/content/circle-ci@6OoAdvikyp0byMH2oZhyQ.md b/roadmaps/terraform/content/circle-ci@6OoAdvikyp0byMH2oZhyQ.md index 3df569d15..a8e46baf9 100644 --- a/roadmaps/terraform/content/circle-ci@6OoAdvikyp0byMH2oZhyQ.md +++ b/roadmaps/terraform/content/circle-ci@6OoAdvikyp0byMH2oZhyQ.md @@ -1,6 +1,6 @@ # Circle CI -Integrating Terraform with CircleCI enables automated infrastructure management within CircleCI's continuous integration and deployment pipelines. This setup allows for consistent and repeatable infrastructure deployments alongside application code changes. In a typical CircleCI configuration, jobs are defined to run Terraform commands like init, plan, and apply. The workflow can include steps for checking out code, setting up Terraform, and managing state files. CircleCI's environment variables and contexts can be used to securely store and access sensitive data like cloud provider credentials. CircleCI's parallelism features can be leveraged for faster execution of Terraform in complex setups. +CircleCI can execute Terraform pipelines using orbs or custom job configurations. Jobs are defined in a `.circleci/config.yml` file and run in containers with the Terraform binary installed. It supports parallel jobs, caching, and approval steps that can be used to gate a `terraform apply` behind a manual review. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/clean-up@inbTto9Qukdj6egRJ0Zh9.md b/roadmaps/terraform/content/clean-up@inbTto9Qukdj6egRJ0Zh9.md index 6d96f438e..135282d80 100644 --- a/roadmaps/terraform/content/clean-up@inbTto9Qukdj6egRJ0Zh9.md +++ b/roadmaps/terraform/content/clean-up@inbTto9Qukdj6egRJ0Zh9.md @@ -1,6 +1,6 @@ # Clean Up -Cleaning up after using Terraform involves removing the infrastructure resources created and managing the associated state. The primary command for this is `terraform destroy`, which deletes all resources managed by the current Terraform configuration. It shows a destruction plan and requires confirmation before proceeding. After destruction, you should remove or archive the state files if they're no longer needed. For partial cleanup, you can remove specific resources from the state using `terraform state rm` and then run `terraform apply` to delete them. It's crucial to ensure all resources are properly removed to avoid unnecessary costs and security risks. Always review the destruction plan carefully, especially in shared or production environments, to prevent accidental deletion of critical resources. +Cleaning up Terraform-managed infrastructure means removing resources that are no longer needed. Terraform provides a command to destroy all resources in the current workspace, and understanding when and how to use it safely is an important part of the infrastructure lifecycle. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/compliance--sentinel@z0PcbgpHbR6Fm07-On4P8.md b/roadmaps/terraform/content/compliance--sentinel@z0PcbgpHbR6Fm07-On4P8.md index c5904c709..5fc5c2073 100644 --- a/roadmaps/terraform/content/compliance--sentinel@z0PcbgpHbR6Fm07-On4P8.md +++ b/roadmaps/terraform/content/compliance--sentinel@z0PcbgpHbR6Fm07-On4P8.md @@ -1,6 +1,6 @@ # Compliance / Sentinel -Hashicorp Sentinel is a policy-as-code framework integrated with HashiCorp's enterprise products, including Terraform Cloud and Terraform Enterprise. It allows organizations to define and enforce standardized, fine-grained policies across their infrastructure deployments. Sentinel policies can be written to check for security compliance, cost management, or operational best practices before Terraform applies any changes. These policies use a domain-specific language to define rules that evaluate Terraform plans and state, enabling teams to catch potential issues early in the development process. Sentinel can enforce mandatory policies that prevent non-compliant infrastructure changes from being applied, or advisory policies that warn but don't block deployments. +Sentinel is a policy as code framework built into Terraform Cloud and Enterprise. It allows teams to define rules that restrict what infrastructure can be provisioned, enforce tagging standards, or require cost approval before applying. Policies are evaluated between the plan and apply phases, blocking deployments that violate defined rules. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/contract-testing@bjozhkpOI9UjjNfmT5HhY.md b/roadmaps/terraform/content/contract-testing@bjozhkpOI9UjjNfmT5HhY.md index d02b1354f..af2b263fb 100644 --- a/roadmaps/terraform/content/contract-testing@bjozhkpOI9UjjNfmT5HhY.md +++ b/roadmaps/terraform/content/contract-testing@bjozhkpOI9UjjNfmT5HhY.md @@ -1,6 +1,6 @@ # Contract Testing -Terraform contract testing focuses on verifying the interfaces and interactions between different modules or components of your infrastructure code. This approach ensures that modules work correctly together and adhere to expected input/output contracts. Contract tests typically validate that a module accepts the correct input variables, produces the expected outputs, and creates resources with the right attributes. They often involve setting up test fixtures with mock data or minimal real infrastructure. The goal is to catch integration issues early, such as mismatched variable types or unexpected resource configurations. Contract testing helps maintain consistency across module versions and ensures that changes to one module don't break dependent modules. This type of testing is particularly valuable in large, modular Terraform projects where multiple teams may be working on different components of the infrastructure. +Contract testing verifies that the inputs and outputs of a module conform to a defined interface. It ensures that a module behaves predictably when called with specific values and that its outputs meet the expectations of callers. This is useful when modules are shared across multiple teams or projects. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/count@kyScfijEntX9H1mp7tmej.md b/roadmaps/terraform/content/count@kyScfijEntX9H1mp7tmej.md index e0ce764e8..e9e0e1b3e 100644 --- a/roadmaps/terraform/content/count@kyScfijEntX9H1mp7tmej.md +++ b/roadmaps/terraform/content/count@kyScfijEntX9H1mp7tmej.md @@ -1,8 +1,6 @@ # 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 declare count and for\_each on the same resource. +The `count` meta-argument creates multiple instances of a resource or module from a single block. It accepts a whole number, and each instance is identified by an index starting at zero. Individual instances can be referenced using the `resource.name[index]` syntax. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/creating-local-modules@wQN1QrK9VB_fHlXrBzDoU.md b/roadmaps/terraform/content/creating-local-modules@wQN1QrK9VB_fHlXrBzDoU.md index 3bb97a501..be12ee6f5 100644 --- a/roadmaps/terraform/content/creating-local-modules@wQN1QrK9VB_fHlXrBzDoU.md +++ b/roadmaps/terraform/content/creating-local-modules@wQN1QrK9VB_fHlXrBzDoU.md @@ -1,6 +1,6 @@ # Creating Local Modules -Creating local modules in Terraform involves organizing a set of related resources into a reusable package within your project. To create a local module, you typically create a new directory within your project structure and place Terraform configuration files (`.tf`) inside it. These files define the resources, variables, and outputs for the module. The module can then be called from your root configuration using a module block, specifying the local path to the module directory. Local modules are useful for encapsulating and reusing common infrastructure patterns within a project, improving code organization and maintainability. They can accept input variables for customization and provide outputs for use in the calling configuration. Local modules are particularly beneficial for breaking down complex infrastructures into manageable, logical components and for standardizing resource configurations across a project. +Local modules are directories containing Terraform configuration files that are referenced using a relative file path in a `module` block. They allow you to break a large configuration into smaller, self-contained units. Inputs are passed via variables and outputs are declared for the parent module to consume. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/creation--destroy-time@CJfCpRN_oVf6n_EfLNJSV.md b/roadmaps/terraform/content/creation--destroy-time@CJfCpRN_oVf6n_EfLNJSV.md index 519e932cb..a5ce330ad 100644 --- a/roadmaps/terraform/content/creation--destroy-time@CJfCpRN_oVf6n_EfLNJSV.md +++ b/roadmaps/terraform/content/creation--destroy-time@CJfCpRN_oVf6n_EfLNJSV.md @@ -1,8 +1,6 @@ # Creation / Destroy Time -Creation and destroy-time provisioners in Terraform are used to execute actions at specific points in a resource's lifecycle. Creation-time provisioners run after a resource is created, while destroy-time provisioners run before a resource is destroyed. Creation-time provisioners are useful for tasks like initializing a newly created server, installing software, or configuring applications. Destroy-time provisioners are typically used for cleanup tasks, such as deregistering a server from a load balancer before deletion. Both types can be specified within a resource block. - -Creation-time provisioners that fail will cause the resource creation to fail, potentially leaving resources in an incomplete state. Destroy-time provisioners that fail don't prevent resource destruction but may leave external resources in an inconsistent state. Due to their potential impact on Terraform's ability to manage state consistently, both types should be used cautiously and designed to be idempotent and fault-tolerant. +Provisioners run either at creation time, after the resource is created, or at destroy time, before the resource is deleted. Creation-time provisioners bootstrap resources, while destroy-time provisioners handle cleanup tasks. If a creation-time provisioner fails, the resource is marked as tainted and will be destroyed and recreated on the next apply. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/custom-provisioners@HEr-BBxE3jRKTqRnguds1.md b/roadmaps/terraform/content/custom-provisioners@HEr-BBxE3jRKTqRnguds1.md index 0172653cb..41d1b8f1d 100644 --- a/roadmaps/terraform/content/custom-provisioners@HEr-BBxE3jRKTqRnguds1.md +++ b/roadmaps/terraform/content/custom-provisioners@HEr-BBxE3jRKTqRnguds1.md @@ -1,8 +1,6 @@ # Custom Provisioners -Terraform custom provisioners allow developers to extend Terraform's provisioning capabilities beyond the built-in options. These are created using Go programming language and the Terraform plugin SDK. Custom provisioners can perform specialized tasks tailored to specific infrastructure needs or organizational requirements. They follow the same lifecycle as built-in provisioners, executing during resource creation or destruction. - -Developing custom provisioners requires a deep understanding of Terraform's architecture and Go programming. They're useful for integrating Terraform with proprietary systems or implementing complex, organization-specific provisioning logic. However, custom provisioners should be approached cautiously, as they increase maintenance overhead and can complicate Terraform upgrades. In many cases, it's preferable to use existing provisioners or separate configuration management tools unless there's a compelling need for custom functionality. +Custom provisioners can be implemented using external programs that follow the Terraform provisioner plugin protocol. They allow teams to integrate specialized tooling into the Terraform lifecycle without relying on the built-in provisioner types. Custom provisioners are rare and typically only needed for highly specific workflows. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/data-sources@huXZz55P7kVJwTn5BS_Wk.md b/roadmaps/terraform/content/data-sources@huXZz55P7kVJwTn5BS_Wk.md index 10a914380..f3eed4b4a 100644 --- a/roadmaps/terraform/content/data-sources@huXZz55P7kVJwTn5BS_Wk.md +++ b/roadmaps/terraform/content/data-sources@huXZz55P7kVJwTn5BS_Wk.md @@ -1,6 +1,6 @@ # Data Sources -Terraform data sources allow retrieval of information from external systems or existing resources for use within Terraform configurations. They provide a way to query and fetch data that can be used in resource definitions, making configurations more dynamic and adaptable. Data sources don't create or manage resources; instead, they read existing data. Common uses include fetching AMI IDs, looking up IP ranges, or retrieving information about existing infrastructure components. Data sources are defined using data blocks in Terraform configuration files and can accept arguments to filter or specify the data being requested. They enable Terraform to integrate with existing infrastructure or external systems, facilitating more flexible and context-aware resource management. +Data sources allow Terraform to read information from external systems or from resources not managed in the current configuration. A `data` block queries a provider for information at plan time and makes the result available as a reference. Common uses include looking up AMI IDs, VPC details, or DNS zone information. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/deployment-workflow@wL3WWhjPEgFmumOmCPRDf.md b/roadmaps/terraform/content/deployment-workflow@wL3WWhjPEgFmumOmCPRDf.md index 1954f217d..4bf880611 100644 --- a/roadmaps/terraform/content/deployment-workflow@wL3WWhjPEgFmumOmCPRDf.md +++ b/roadmaps/terraform/content/deployment-workflow@wL3WWhjPEgFmumOmCPRDf.md @@ -1,6 +1,6 @@ # Deployment Workflow -A Terraform deployment workflow for scaling typically involves several key stages optimized for managing large infrastructures. It starts with code development in feature branches, followed by automated testing including syntax checks, linting, and unit tests. Pull requests trigger plan generations for review. After approval, changes merge to a main branch, initiating a CI/CD pipeline. This pipeline runs more comprehensive tests, including integration and possibly end-to-end tests. For large infrastructures, the workflow often includes staged deployments, starting with lower environments and progressively moving to production. It may involve partial applies or use of workspaces to manage different environments. The process incorporates manual approval gates for critical changes. State management becomes crucial, often utilizing remote backends with locking. Monitoring and logging are integrated to track deployment progress and catch issues early. +A consistent deployment workflow defines how infrastructure changes move from development to production. Common patterns include environment promotion, where changes are applied to lower environments first, and GitOps, where the desired state is tracked in a Git repository and applied automatically. Enforcing a workflow reduces the risk of ad-hoc changes causing drift. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/deployment@pjmOK1MEMnIV_zAlaOF01.md b/roadmaps/terraform/content/deployment@pjmOK1MEMnIV_zAlaOF01.md index f338d4d5e..261863480 100644 --- a/roadmaps/terraform/content/deployment@pjmOK1MEMnIV_zAlaOF01.md +++ b/roadmaps/terraform/content/deployment@pjmOK1MEMnIV_zAlaOF01.md @@ -1,10 +1,6 @@ # Deployment -Deploying Terraform-defined infrastructure involves several key steps: - -* Initialize the working directory with `terraform init` -* Review changes with `terraform plan` -* Apply the configuration using `terraform apply`. +Deployment refers to the process of applying a configuration to create or update infrastructure. The typical workflow involves running `terraform plan` to preview changes and `terraform apply` to execute them. Understanding what happens during these steps is necessary for safe and predictable infrastructure management. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/end-to-end-testing@QqwlAtz7VfrMtNEGpT5Sa.md b/roadmaps/terraform/content/end-to-end-testing@QqwlAtz7VfrMtNEGpT5Sa.md index cdf91fe34..99d9691c8 100644 --- a/roadmaps/terraform/content/end-to-end-testing@QqwlAtz7VfrMtNEGpT5Sa.md +++ b/roadmaps/terraform/content/end-to-end-testing@QqwlAtz7VfrMtNEGpT5Sa.md @@ -1,6 +1,6 @@ # End to End Testing -Terraform end-to-end testing involves validating the entire infrastructure deployment process from start to finish, simulating real-world usage scenarios. These tests apply complete Terraform configurations to create full environments, verify the functionality and interactions of all components, and then destroy the infrastructure. End-to-end tests often include checking network connectivity, application deployments, and overall system performance. They may involve multiple Terraform modules and external systems, testing the infrastructure as a cohesive unit. While resource-intensive and time-consuming, these tests provide the highest level of confidence in the infrastructure's correctness and reliability. They're particularly valuable for detecting issues that arise from complex interactions between different parts of the infrastructure. End-to-end tests are typically run less frequently than other types of tests, often as part of release processes or major change validations. +End-to-end tests validate an entire infrastructure stack by provisioning it, running checks against live endpoints or resources, and then tearing it down. These tests are the most comprehensive but also the slowest and most costly. They are typically run in a dedicated test environment and triggered on a schedule or before major releases. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/enterprise-features@elW7IMBSF0ydmlb7rtI1o.md b/roadmaps/terraform/content/enterprise-features@elW7IMBSF0ydmlb7rtI1o.md index aef2848c1..22cc97b21 100644 --- a/roadmaps/terraform/content/enterprise-features@elW7IMBSF0ydmlb7rtI1o.md +++ b/roadmaps/terraform/content/enterprise-features@elW7IMBSF0ydmlb7rtI1o.md @@ -1,24 +1,6 @@ # Enterprise Features -HashiCorp Cloud Platform (HCP) offers several enterprise-grade features designed to enhance large-scale infrastructure management: - -1. Centralized workflow management for Terraform operations -2. Advanced role-based access control (RBAC) for fine-grained permissions -3. Policy as Code with Sentinel for governance and compliance -4. Private network connectivity for secure access to cloud resources -5. Audit logging for comprehensive tracking of all platform activities -6. Integrated secrets management with Vault -7. Service networking capabilities through Consul -8. Multi-cloud and hybrid cloud support -9. Scalable remote state management -10. Cost estimation and optimization tools -11. Customizable policy libraries for security and compliance -12. Single sign-on (SSO) and identity federation -13. API-driven automation for infrastructure provisioning -14. Collaborative features for team-based infrastructure development -15. Continuous compliance monitoring and reporting - -These features collectively provide a robust, secure, and scalable environment for enterprise-level infrastructure management and DevOps practices. +HCP Terraform Enterprise features include audit logging, single sign-on, self-hosted deployment options, Sentinel policy enforcement, team and organization management, and private module registries. These features are aimed at large organizations that need governance controls and compliance capabilities beyond what the free tier provides. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/file-provisioner@Qch8k6e4pS8OlmG_sI0hH.md b/roadmaps/terraform/content/file-provisioner@Qch8k6e4pS8OlmG_sI0hH.md index cee648478..69917976b 100644 --- a/roadmaps/terraform/content/file-provisioner@Qch8k6e4pS8OlmG_sI0hH.md +++ b/roadmaps/terraform/content/file-provisioner@Qch8k6e4pS8OlmG_sI0hH.md @@ -1,6 +1,6 @@ # file provisioner -The Terraform file provisioner is used to copy files or directories from the machine running Terraform to a newly created resource. It's useful for tasks like uploading configuration files, scripts, or other necessary data to remote systems. The file provisioner can copy a single file or recursively copy directories. It supports both source and content arguments, allowing for either file-based or inline content transfers. This provisioner is often used in conjunction with remote-exec provisioners to execute uploaded scripts. While convenient for simple file transfers, it's important to consider security implications, especially when dealing with sensitive data. For more complex or large-scale file management tasks, dedicated configuration management tools are often preferred. The file provisioner is best used for small, straightforward file transfers needed to bootstrap or configure newly created resources. +The `file` provisioner copies files or directories from the machine running Terraform to a newly created remote resource. It requires a connection block specifying how to reach the remote machine, typically over SSH or WinRM. It is commonly used to upload configuration files or scripts before executing them. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/for_each@gcdg_GhAacIWzv19ITTE_.md b/roadmaps/terraform/content/for_each@gcdg_GhAacIWzv19ITTE_.md index 962647199..b774b1b15 100644 --- a/roadmaps/terraform/content/for_each@gcdg_GhAacIWzv19ITTE_.md +++ b/roadmaps/terraform/content/for_each@gcdg_GhAacIWzv19ITTE_.md @@ -1,8 +1,6 @@ # 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. +The `for_each` meta-argument creates one instance of a resource or module for each item in a map or set of strings. Each instance is keyed by the map key or set value, making it easier to manage and reference individual items than with `count`. It is generally preferred over `count` when creating resources from a collection. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/format--validate@Xes24SqkwSaO844kLbClj.md b/roadmaps/terraform/content/format--validate@Xes24SqkwSaO844kLbClj.md index cfd83301b..60a3b307e 100644 --- a/roadmaps/terraform/content/format--validate@Xes24SqkwSaO844kLbClj.md +++ b/roadmaps/terraform/content/format--validate@Xes24SqkwSaO844kLbClj.md @@ -1,10 +1,6 @@ # Format & Validate -Terraform `format` and `validate` are two essential commands for maintaining clean and correct Terraform configurations: - -* `terraform fmt` automatically formats Terraform configuration files to a consistent style. It adjusts indentation, aligns arguments, and sorts blocks and arguments. This command helps maintain code readability and consistency across team projects. - -* `terraform validate` checks the syntax and internal consistency of Terraform configurations. It verifies that the configuration is syntactically valid, references are correct, and attribute names and types are appropriate. This command catches errors early in the development process, before attempting to apply changes to infrastructure. +Terraform provides built-in commands for formatting and validating configuration files before deployment. These commands help maintain consistent style and catch configuration errors early, before a plan or apply is attempted. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/github-actions@weIlGqGN15U8BH1yE9moA.md b/roadmaps/terraform/content/github-actions@weIlGqGN15U8BH1yE9moA.md index ce122c9a4..cbb0ef268 100644 --- a/roadmaps/terraform/content/github-actions@weIlGqGN15U8BH1yE9moA.md +++ b/roadmaps/terraform/content/github-actions@weIlGqGN15U8BH1yE9moA.md @@ -1,6 +1,6 @@ # GitHub Actions -Using Terraform with GitHub Actions allows for automated infrastructure management as part of a GitHub-based CI/CD pipeline. This integration enables automatic planning, validation, and application of Terraform configurations when changes are pushed to a repository. Typical workflow steps include checking out code, setting up Terraform, initializing the working directory, and running Terraform commands like plan and apply. GitHub Actions can be configured to run Terraform in different environments, manage state files, and handle secrets securely. It's important to configure appropriate permissions and use GitHub Secrets for sensitive data. +GitHub Actions can run Terraform commands as part of a workflow triggered by pull requests or pushes. Workflows are defined in YAML files and can use community actions from the GitHub Marketplace or call the Terraform CLI directly. Secrets for provider credentials are stored in the repository settings and injected as environment variables. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/gitlab-ci@fH27mGrdnkDQCrGGDFU6p.md b/roadmaps/terraform/content/gitlab-ci@fH27mGrdnkDQCrGGDFU6p.md index 08768939d..db5bed441 100644 --- a/roadmaps/terraform/content/gitlab-ci@fH27mGrdnkDQCrGGDFU6p.md +++ b/roadmaps/terraform/content/gitlab-ci@fH27mGrdnkDQCrGGDFU6p.md @@ -1,6 +1,6 @@ # GitLab CI -Using Terraform with GitLab CI enables automated infrastructure management within GitLab's CI/CD pipeline. A typical GitLab CI pipeline for Terraform includes stages for validation, planning, and applying changes. The pipeline can be configured to run Terraform commands automatically on code pushes or merge requests. GitLab CI variables are used to store sensitive information like cloud credentials securely. GitLab's native features like environments and approvals can be leveraged to manage different deployment stages and control when changes are applied. +GitLab CI runs Terraform pipelines using `.gitlab-ci.yml` configuration files. GitLab provides a native Terraform integration with merge request widgets that display plan output directly in the code review interface. The GitLab-managed Terraform state backend stores state securely within the GitLab instance. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/graph@vAFFgKSthyj_3Lxt-Z6pg.md b/roadmaps/terraform/content/graph@vAFFgKSthyj_3Lxt-Z6pg.md index e29bdd4f2..2c264774d 100644 --- a/roadmaps/terraform/content/graph@vAFFgKSthyj_3Lxt-Z6pg.md +++ b/roadmaps/terraform/content/graph@vAFFgKSthyj_3Lxt-Z6pg.md @@ -1,6 +1,6 @@ # graph -The terraform graph command generates a visual representation of either a configuration or execution plan. It creates a graph of resources and their dependencies in DOT format, which can be converted into an image using tools like Graphviz. This visual aid helps developers understand complex resource relationships, identify potential issues in resource ordering, and visualize the overall structure of their infrastructure. The graph can show different aspects of the Terraform configuration, including resource dependencies, data flow, and module relationships. While primarily used for debugging and documentation purposes, the graph command is also valuable for presenting infrastructure designs to stakeholders or for educational purposes. It's particularly useful in large, complex projects where understanding resource interdependencies can be challenging. +`terraform graph` outputs a visual representation of the dependency graph for the current configuration or plan. The output is in DOT format, which can be rendered with tools like Graphviz. It is useful for understanding resource dependencies and diagnosing unexpected ordering issues. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/hcp@erxow5xNRj01WepdFOhVf.md b/roadmaps/terraform/content/hcp@erxow5xNRj01WepdFOhVf.md index 2e03cb6c7..66f9328c9 100644 --- a/roadmaps/terraform/content/hcp@erxow5xNRj01WepdFOhVf.md +++ b/roadmaps/terraform/content/hcp@erxow5xNRj01WepdFOhVf.md @@ -1,3 +1,3 @@ # HCP -HCP (HashiCorp Cloud Platform) is a fully managed platform that provides HashiCorp products as a service, including Terraform. It offers a centralized way to provision, secure, connect, and run any infrastructure for any application. HCP integrates seamlessly with Terraform, providing enhanced capabilities for managing infrastructure at scale. Key features include automated workflows, centralized state management, and secure remote operations. It offers built-in collaboration tools, making it easier for teams to work together on infrastructure projects. HCP provides governance and policy enforcement capabilities, allowing organizations to maintain compliance and security standards across their infrastructure. With its integration of other HashiCorp tools like Vault for secrets management and Consul for service networking, HCP creates a comprehensive ecosystem for cloud infrastructure management. This platform is particularly beneficial for organizations looking to streamline their infrastructure operations, enhance security, and maintain consistency across multi-cloud environments. \ No newline at end of file +HCP (HashiCorp Cloud Platform) is a managed cloud offering that hosts HashiCorp products including Terraform as a service. It provides a centralized place to manage Terraform runs, state, and policies without self-hosting the Terraform Enterprise platform. \ No newline at end of file diff --git a/roadmaps/terraform/content/import-existing-resources@L7wAMGi_yU-Bbc9fXlmxZ.md b/roadmaps/terraform/content/import-existing-resources@L7wAMGi_yU-Bbc9fXlmxZ.md index 3c6e2125b..9e8c5ad71 100644 --- a/roadmaps/terraform/content/import-existing-resources@L7wAMGi_yU-Bbc9fXlmxZ.md +++ b/roadmaps/terraform/content/import-existing-resources@L7wAMGi_yU-Bbc9fXlmxZ.md @@ -1,8 +1,6 @@ # Import Existing Resources -Terraform state import is a command used to bring existing resources under Terraform management. It allows you to add resources that were created outside of Terraform (e.g., manually or by other tools) into your Terraform state. The command takes two main arguments: the Terraform resource address and the real-world resource identifier. When executed, it adds the resource to the state file without modifying the actual infrastructure. This is useful for adopting Terraform in environments with existing resources, or for recovering from scenarios where state and reality have diverged. After importing, you need to write the corresponding configuration in your Terraform files to match the imported resource. - -In Terraform v1.5.0 and later you can also create `import` blocks in any Terraform configuration file. +`terraform import` brings existing infrastructure resources under Terraform management by adding them to the state file. After importing, the configuration must be written manually to match the imported resource. This is used when adopting Terraform in environments where resources were created outside of it. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/infracost@oANePqjkwtNMwvV-_W0B7.md b/roadmaps/terraform/content/infracost@oANePqjkwtNMwvV-_W0B7.md index 2e5170258..eaf8993f1 100644 --- a/roadmaps/terraform/content/infracost@oANePqjkwtNMwvV-_W0B7.md +++ b/roadmaps/terraform/content/infracost@oANePqjkwtNMwvV-_W0B7.md @@ -1,6 +1,6 @@ # Infracost -Infracost is an open-source tool that provides real-time cost estimates for Terraform projects. It analyzes Terraform configuration files and generates detailed cost breakdowns for cloud resources across various providers like AWS, Azure, and Google Cloud. Infracost integrates into CI/CD pipelines to show cost implications of infrastructure changes during the development process. It supports diff outputs, showing how proposed changes will affect costs. This tool is particularly valuable for teams looking to optimize cloud spending and maintain cost awareness throughout the infrastructure development lifecycle. Infracost can be used standalone or integrated with other tools, helping teams make informed decisions about resource provisioning and configuration changes. +Infracost is a cost estimation tool that integrates with Terraform to show the monthly cloud cost impact of planned infrastructure changes. It parses a Terraform plan and calculates costs based on provider pricing data. It can be added to CI pipelines to display cost breakdowns in pull request comments before changes are merged. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/inputs--outputs@NsBJTYH9KXvjJuhPzjE_L.md b/roadmaps/terraform/content/inputs--outputs@NsBJTYH9KXvjJuhPzjE_L.md index f83e7e14a..d1546a0e9 100644 --- a/roadmaps/terraform/content/inputs--outputs@NsBJTYH9KXvjJuhPzjE_L.md +++ b/roadmaps/terraform/content/inputs--outputs@NsBJTYH9KXvjJuhPzjE_L.md @@ -1,8 +1,6 @@ # Inputs / Outputs -Module inputs and outputs in Terraform facilitate the flow of data into and out of modules, enabling customization and data sharing. Inputs are defined using variable blocks within a module and allow the module's behavior to be customized when it's used. They can have default values and type constraints. - -When calling a module, inputs are provided as arguments. Outputs, defined using output blocks, expose specific values from the module's resources, making them available to the calling module. This allows for data to be passed between modules or to be used in other parts of the configuration. Outputs can include computed values, resource attributes, or any Terraform expression. Properly designed inputs and outputs are crucial for creating flexible, reusable modules that can be easily integrated into various configurations. +Modules accept input values through declared variables and expose results through declared outputs. The calling module passes values for each required variable and can reference the module's outputs using the `module..` syntax. Well-defined inputs and outputs form the public interface of a module. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/inspect--modify-state@KXlLlaR0_S7gE_ZB1hNEd.md b/roadmaps/terraform/content/inspect--modify-state@KXlLlaR0_S7gE_ZB1hNEd.md index 5e1e3ad63..ea15791d5 100644 --- a/roadmaps/terraform/content/inspect--modify-state@KXlLlaR0_S7gE_ZB1hNEd.md +++ b/roadmaps/terraform/content/inspect--modify-state@KXlLlaR0_S7gE_ZB1hNEd.md @@ -1,6 +1,6 @@ # Inspect / Modify State -Terraform provides tools to inspect and modify state, enabling management of tracked resources without altering the actual infrastructure. These capabilities allow users to view the current state in human-readable format, list all resources in the state, and obtain detailed information on specific resources. For state modification, Terraform offers methods to move resources within the state or to different state files, remove resources from state without deleting the actual resource, and update the state to match real-world infrastructure. These tools are crucial for reconciling discrepancies between Terraform's state and actual infrastructure, and for managing resources across different Terraform configurations or workspaces. However, state modifications should be performed cautiously, as improper changes can lead to inconsistencies between the state and the actual infrastructure. +Terraform provides a set of commands for inspecting and modifying state directly. These are advanced operations used to fix drift, remove orphaned resources, or manually adjust state when normal plan and apply workflows are insufficient. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/integration-testing@ENkLj3z6hR2cKT7rBhYp5.md b/roadmaps/terraform/content/integration-testing@ENkLj3z6hR2cKT7rBhYp5.md index 8ddab24b7..f61f17f3e 100644 --- a/roadmaps/terraform/content/integration-testing@ENkLj3z6hR2cKT7rBhYp5.md +++ b/roadmaps/terraform/content/integration-testing@ENkLj3z6hR2cKT7rBhYp5.md @@ -1,6 +1,6 @@ # Integration Testing -Terraform integration testing involves verifying that Terraform configurations work correctly with actual cloud resources and services. These tests create real infrastructure components, interact with them, and then destroy them, ensuring that resources are properly provisioned and configured in a live environment. Integration tests typically use frameworks like Terratest or custom scripts to automate the process of applying Terraform configurations, validating the resulting infrastructure, and cleaning up afterwards. They check for correct resource creation, proper configuration of interdependent resources, and overall system behavior. While more time-consuming and potentially costly than unit tests, integration tests provide high confidence in the reliability of Terraform code in real-world scenarios. They're crucial for catching issues that may only appear when interacting with actual cloud services, such as API limitations or unexpected service behaviors. +Integration tests provision real infrastructure and verify that resources are created correctly and work together as expected. They are slower and more expensive than unit tests but catch issues that static analysis cannot detect. Terratest is a popular Go-based framework for writing integration tests against live Terraform deployments. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/jenkins@qFpaqOSoefTyKxmI-FRZt.md b/roadmaps/terraform/content/jenkins@qFpaqOSoefTyKxmI-FRZt.md index 31af884b5..1372ea10a 100644 --- a/roadmaps/terraform/content/jenkins@qFpaqOSoefTyKxmI-FRZt.md +++ b/roadmaps/terraform/content/jenkins@qFpaqOSoefTyKxmI-FRZt.md @@ -1,6 +1,6 @@ # Jenkins -Using Terraform with Jenkins enables automated infrastructure management within a Jenkins-based CI/CD pipeline. This integration allows for consistent and repeatable infrastructure deployments alongside application builds. In a typical setup, Jenkins jobs or pipelines are configured to execute Terraform commands, such as `init`, `plan`, and `apply`. Jenkins can manage different environments by using parameters or separate jobs for each environment. Proper credential management is crucial for securely handling cloud provider access keys. Jenkins' rich plugin ecosystem can enhance Terraform workflows with additional features like visualization and notification capabilities. +Jenkins can orchestrate Terraform workflows using Pipeline scripts written in Groovy. The Terraform binary is installed on agents or provided via a tool configuration. Jenkins supports approval gates between plan and apply stages and integrates with secret management tools to supply provider credentials securely. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/kics@MUkbLTMzmaVWbAJj6G3aj.md b/roadmaps/terraform/content/kics@MUkbLTMzmaVWbAJj6G3aj.md index 6c012dfdc..18966839a 100644 --- a/roadmaps/terraform/content/kics@MUkbLTMzmaVWbAJj6G3aj.md +++ b/roadmaps/terraform/content/kics@MUkbLTMzmaVWbAJj6G3aj.md @@ -1,6 +1,6 @@ # KICS -KICS (Keeping Infrastructure as Code Secure) is an open-source static analysis tool designed to scan Infrastructure as Code (IaC) files, including Terraform configurations, for security vulnerabilities, compliance issues, and infrastructure misconfigurations. It supports multiple IaC technologies and cloud providers, offering a comprehensive approach to securing cloud-native environments. KICS uses a robust set of predefined rules to detect potential security risks, ranging from insecure defaults to violations of industry standards and best practices. The tool allows for custom query development, enabling organizations to tailor scans to their specific security and compliance needs. KICS can be easily integrated into CI/CD pipelines, providing early detection of issues in the development lifecycle. Its ability to generate detailed reports and support various output formats facilitates easy interpretation of results and integration with other security and DevOps tools, making it a valuable asset in maintaining secure and compliant infrastructure deployments managed through Terraform. +KICS (Keeping Infrastructure as Code Secure) is an open-source tool from Checkmarx that scans IaC files including Terraform for security vulnerabilities, compliance issues, and misconfigurations. It covers a broad set of cloud platforms and IaC formats and supports custom queries written in the Open Policy Agent Rego language. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/lifecycle@0A8zTuCXVmcruJdfH3cNu.md b/roadmaps/terraform/content/lifecycle@0A8zTuCXVmcruJdfH3cNu.md index 898f65a6c..846ecb3cd 100644 --- a/roadmaps/terraform/content/lifecycle@0A8zTuCXVmcruJdfH3cNu.md +++ b/roadmaps/terraform/content/lifecycle@0A8zTuCXVmcruJdfH3cNu.md @@ -1,6 +1,6 @@ # 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. +The `lifecycle` block inside a resource configures how Terraform handles creation, updates, and deletion of that resource. It supports arguments like `create_before_destroy`, `prevent_destroy`, `ignore_changes`, and `replace_triggered_by`. These settings give you fine-grained control over resource replacement behavior. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/list@Y-mgCkDpawt5NrMwDH9Ki.md b/roadmaps/terraform/content/list@Y-mgCkDpawt5NrMwDH9Ki.md index b076b652a..ec8c6dd6f 100644 --- a/roadmaps/terraform/content/list@Y-mgCkDpawt5NrMwDH9Ki.md +++ b/roadmaps/terraform/content/list@Y-mgCkDpawt5NrMwDH9Ki.md @@ -1,6 +1,6 @@ # list -The terraform list command is used to display a list of resources within the Terraform state. It provides a quick overview of all the resources currently being managed by Terraform in your configuration. This command is particularly useful when working with large or complex infrastructures, allowing developers to quickly see what resources are under Terraform's control. The output includes the resource type and name for each managed resource, making it easy to identify specific elements of your infrastructure. It's often used in conjunction with other state manipulation commands to verify the contents of the state or to identify resources for further inspection or modification. +`terraform state list` prints the addresses of all resources tracked in the current state. It is a quick way to see what Terraform is managing and to find the exact resource address needed for other state subcommands. Addresses can be filtered by a resource type or module prefix. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/local-exec-provisioner@g2F5-nX4Aw-xWZiypNbnL.md b/roadmaps/terraform/content/local-exec-provisioner@g2F5-nX4Aw-xWZiypNbnL.md index b44f053d5..ef58e9c67 100644 --- a/roadmaps/terraform/content/local-exec-provisioner@g2F5-nX4Aw-xWZiypNbnL.md +++ b/roadmaps/terraform/content/local-exec-provisioner@g2F5-nX4Aw-xWZiypNbnL.md @@ -1,6 +1,6 @@ # local-exec provisioner -The local-exec provisioner in Terraform allows the execution of local commands on the machine running Terraform after a resource is created. It's useful for tasks that need to be performed locally rather than on the remote resource. This provisioner can run scripts, update local files, or trigger local processes based on the creation of cloud resources. Common use cases include updating local inventories, triggering local notifications, or running local scripts that interact with the newly created resources. While powerful, it should be used judiciously as it can make Terraform operations dependent on the local environment. The local-exec provisioner doesn't affect the resource itself and isn't tracked in Terraform's state, so it's important to design these commands to be idempotent. It's best suited for simple, local operations that don't require complex error handling or state management. +The `local-exec` provisioner runs a command on the machine executing Terraform, not on the remote resource. It is used for tasks like triggering an external API, running a local script, or writing data to a file. The command runs in a shell, and the working directory defaults to the Terraform configuration directory. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/meta-arguments@TPd00dRndj1P8674KTTrm.md b/roadmaps/terraform/content/meta-arguments@TPd00dRndj1P8674KTTrm.md index 1aa63e3b3..349f30dec 100644 --- a/roadmaps/terraform/content/meta-arguments@TPd00dRndj1P8674KTTrm.md +++ b/roadmaps/terraform/content/meta-arguments@TPd00dRndj1P8674KTTrm.md @@ -1,6 +1,6 @@ # Meta Arguments -Meta-arguments in Terraform resources provide additional control over how resources are managed and interact within the configuration. +Meta-arguments are special arguments available on any resource block that change how Terraform handles that resource. They are not specific to a provider and are built into Terraform itself. Meta-arguments include `depends_on`, `count`, `for_each`, `provider`, and `lifecycle`. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/modules-best-practices@gTMPK0tfs2JYgoL7SAGW6.md b/roadmaps/terraform/content/modules-best-practices@gTMPK0tfs2JYgoL7SAGW6.md index 678496c05..a6911c506 100644 --- a/roadmaps/terraform/content/modules-best-practices@gTMPK0tfs2JYgoL7SAGW6.md +++ b/roadmaps/terraform/content/modules-best-practices@gTMPK0tfs2JYgoL7SAGW6.md @@ -1,17 +1,6 @@ # Modules Best Practices -Terraform module best practices focus on creating reusable, maintainable, and scalable infrastructure components. - -* Modules should have a single, clear purpose and be designed with flexibility in mind, using input variables for customization. -* Outputs should be carefully chosen to provide necessary information without over-exposing internal details. -* Version your modules and use semantic versioning to manage changes. -* Keep modules small and focused, adhering to the single responsibility principle. -* Document your modules thoroughly, including usage examples and input/output descriptions. -* Use consistent naming conventions and structure across modules. -* Test modules in isolation and as part of larger systems. -* Avoid hard-coding values that might change across environments. -* Consider using nested modules for complex structures, but be mindful of over-nesting. -* Regularly review and refactor modules to incorporate improvements and maintain best practices. +Modules should be focused on a single concern and avoid hardcoding values that callers need to control. Always declare types for input variables and provide descriptions. Version-pin external modules and keep local modules small and composable. Avoid deeply nested module hierarchies, as they are harder to debug and maintain. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/modules@R2AORYmc1NgGTqLZY5Fu-.md b/roadmaps/terraform/content/modules@R2AORYmc1NgGTqLZY5Fu-.md index 661c76caa..98b087a9c 100644 --- a/roadmaps/terraform/content/modules@R2AORYmc1NgGTqLZY5Fu-.md +++ b/roadmaps/terraform/content/modules@R2AORYmc1NgGTqLZY5Fu-.md @@ -1,6 +1,6 @@ # Modules -Terraform modules are reusable components that encapsulate a set of resources, their configurations, and their interconnections. They allow for organizing Terraform code into logical, self-contained units that can be shared and reused across different projects or within the same project. Modules promote code reusability, maintainability, and consistency in infrastructure deployments. They can accept input variables, produce output values, and be nested within other modules. By using modules, teams can create standardized infrastructure components, enforce best practices, and simplify complex configurations. Modules can be sourced from local directories, version control systems, or public registries like the Terraform Registry. Effective use of modules can significantly reduce code duplication, improve infrastructure management, and enable the creation of scalable, maintainable Terraform configurations. +Modules are reusable packages of Terraform configuration that group related resources together. They allow you to abstract and share infrastructure patterns across projects and teams. Every Terraform configuration is technically a module; the directory you run Terraform from is called the root module. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/mv@0xVXwjWPFXDGRw_3p6th6.md b/roadmaps/terraform/content/mv@0xVXwjWPFXDGRw_3p6th6.md index 95a24e19f..c495f019f 100644 --- a/roadmaps/terraform/content/mv@0xVXwjWPFXDGRw_3p6th6.md +++ b/roadmaps/terraform/content/mv@0xVXwjWPFXDGRw_3p6th6.md @@ -1,9 +1,9 @@ # mv -The terraform state mv command is used to move resources within a Terraform state or between separate state files. It allows for reorganizing the state without modifying the actual infrastructure. This command is useful when refactoring Terraform configurations, moving resources between modules, or splitting a large state file into smaller ones. It takes two arguments: the source and destination addresses of the resource. The command updates all references to the moved resource, ensuring that future operations correctly target the resource at its new location. This functionality is particularly valuable when restructuring complex projects or adapting to changing organizational needs. However, it should be used cautiously, as incorrect moves can lead to state inconsistencies. +`terraform state mv` moves a resource address from one location to another within the state file. It is used when refactoring configurations, such as renaming a resource or moving it into a module, without triggering a destroy and recreate cycle. Visit the following resources to learn more: - [@official@Terraform State mv](https://developer.hashicorp.com/terraform/cli/commands/state/mv) - [@official@Moving Resources](https://developer.hashicorp.com/terraform/cli/state/move) -- [@video@Terraform — Terraform State MV ](https://www.youtube.com/watch?v=i10IMXn3l0o) \ No newline at end of file +- [@video@Terraform — Terraform State MV](https://www.youtube.com/watch?v=i10IMXn3l0o) \ No newline at end of file diff --git a/roadmaps/terraform/content/output-syntax@31fa8kBzCEn-uCrTSoPM4.md b/roadmaps/terraform/content/output-syntax@31fa8kBzCEn-uCrTSoPM4.md index 75d1d719b..990d5b7d6 100644 --- a/roadmaps/terraform/content/output-syntax@31fa8kBzCEn-uCrTSoPM4.md +++ b/roadmaps/terraform/content/output-syntax@31fa8kBzCEn-uCrTSoPM4.md @@ -1,15 +1,6 @@ # Output Syntax -Terraform output syntax is used to define values that should be made accessible after applying a Terraform configuration. The basic syntax is: - - output "name" { - value = expression - description = "Optional description" - sensitive = bool - } - - -`name` is a unique identifier for the output. `value` is the expression whose result will be output. `description` is optional and provides context. `sensitive` is a boolean flag to mark sensitive data. +An output block requires a `value` argument that specifies what to expose. Optional arguments include `description` for documentation, `sensitive` to redact the value, and `depends_on` to declare explicit dependencies. Outputs can expose any value, including resource attributes, local values, and variable values. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/output@kw32gb4HSeCEoBwkeziS_.md b/roadmaps/terraform/content/output@kw32gb4HSeCEoBwkeziS_.md index 769e03f92..1bcd5d924 100644 --- a/roadmaps/terraform/content/output@kw32gb4HSeCEoBwkeziS_.md +++ b/roadmaps/terraform/content/output@kw32gb4HSeCEoBwkeziS_.md @@ -1,6 +1,6 @@ # output -The terraform output command is used to extract the value of an output variable from the Terraform state. It allows you to view the values of outputs defined in your Terraform configuration after they have been applied. This command is useful for retrieving information about your infrastructure, such as IP addresses, resource IDs, or computed values, which can then be used in scripts or passed to other systems. When run without arguments, it displays all outputs. You can specify a particular output name to retrieve a specific value. The command supports different output formats, including JSON, making it easy to integrate with other tools or workflows. It's particularly valuable in CI/CD pipelines or when Terraform is used as part of a larger automation process. +`terraform output` displays the values of outputs defined in the configuration. Without arguments it shows all outputs; a specific output name can be passed to retrieve a single value. The `-json` flag returns output in machine-readable format, useful for scripting. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/parallelism@RtwZy60ruRpskmgr1qYYf.md b/roadmaps/terraform/content/parallelism@RtwZy60ruRpskmgr1qYYf.md index 92c7d427a..9858b5332 100644 --- a/roadmaps/terraform/content/parallelism@RtwZy60ruRpskmgr1qYYf.md +++ b/roadmaps/terraform/content/parallelism@RtwZy60ruRpskmgr1qYYf.md @@ -1,6 +1,6 @@ # Parallelism -Terraform parallelism refers to its ability to create, modify, or destroy multiple resources concurrently. By default, Terraform performs operations on up to 10 resource instances simultaneously. This parallel execution can significantly reduce the time required for applying large configurations. The level of parallelism can be adjusted using the `-parallelism` flag in Terraform commands or through configuration settings. Increasing parallelism can speed up operations, especially in large infrastructures, but may also increase load on the API endpoints of cloud providers. It's important to balance parallelism with API rate limits and resource dependencies. Some resources or providers may not support parallel operations, and Terraform automatically serializes these. Effective use of parallelism requires understanding resource dependencies and provider capabilities to optimize performance without causing errors or exceeding service limits. +Terraform applies resource changes in parallel by default, up to a configurable limit controlled by the `-parallelism` flag. Increasing parallelism can speed up large deployments but may hit API rate limits. Lowering it can reduce throttling errors when working with providers that enforce strict rate limits. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/provider@5FLOFTP_nCa3qi1wbV4qE.md b/roadmaps/terraform/content/provider@5FLOFTP_nCa3qi1wbV4qE.md index 76743740c..5cb5a356d 100644 --- a/roadmaps/terraform/content/provider@5FLOFTP_nCa3qi1wbV4qE.md +++ b/roadmaps/terraform/content/provider@5FLOFTP_nCa3qi1wbV4qE.md @@ -1,6 +1,6 @@ # 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. +The `provider` meta-argument assigns a specific provider configuration to a resource when multiple configurations of the same provider exist. This is common when managing resources across multiple regions or accounts within the same Terraform workspace. The value must match an alias defined in a `provider` block. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/provisioners@6vs1VvjeILgAPLL6g7dfy.md b/roadmaps/terraform/content/provisioners@6vs1VvjeILgAPLL6g7dfy.md index 01e60d3cf..2d187341c 100644 --- a/roadmaps/terraform/content/provisioners@6vs1VvjeILgAPLL6g7dfy.md +++ b/roadmaps/terraform/content/provisioners@6vs1VvjeILgAPLL6g7dfy.md @@ -1,6 +1,6 @@ # Provisioners -Provisioners in Terraform are used to execute scripts or other actions on local or remote machines as part of resource creation or destruction. They allow for configuration management tasks that go beyond Terraform's declarative model. Provisioners can run scripts, upload files, or execute other tools on resources after they're created. Common types include local-exec (runs commands on the machine running Terraform) and remote-exec (runs commands on a remote resource). While powerful, provisioners should be used sparingly as they can make Terraform runs less predictable and idempotent. They're often seen as a last resort when native Terraform resources or provider capabilities are insufficient. Best practices suggest using dedicated configuration management tools like Ansible or Chef instead of heavy reliance on provisioners. When used, provisioners should be designed to be idempotent and handle potential failures gracefully. +Provisioners run scripts or commands on local or remote machines as part of resource creation or destruction. They are a last resort for handling bootstrapping or configuration tasks that cannot be done through the provider API. HashiCorp recommends using purpose-built tools like cloud-init or Ansible instead where possible. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/published-modules-usage@AAg_iFggkEZNL12-6nkgK.md b/roadmaps/terraform/content/published-modules-usage@AAg_iFggkEZNL12-6nkgK.md index db7e233a8..15bbe718a 100644 --- a/roadmaps/terraform/content/published-modules-usage@AAg_iFggkEZNL12-6nkgK.md +++ b/roadmaps/terraform/content/published-modules-usage@AAg_iFggkEZNL12-6nkgK.md @@ -1,6 +1,6 @@ # Published Modules Usage -Using published modules in Terraform involves incorporating pre-built, often community-contributed modules into your infrastructure code. These modules are typically available through the Terraform Registry or other version control systems. They provide ready-made configurations for common infrastructure components, saving time and promoting best practices. To use a published module, you specify its source (usually a URL or registry path) and version in your Terraform configuration. You can then configure the module by passing input variables. Published modules can range from simple resource wrappers to complex, multi-resource configurations. They offer benefits like reduced development time, standardized implementations, and community-tested solutions. However, it's important to review and understand any published module before using it in production environments to ensure it meets your specific requirements and security standards. +Published modules are pre-built, versioned modules available on the Terraform Registry. They can be referenced directly in a `module` block using a registry source address and version constraint. Using published modules speeds up development by providing tested, maintained implementations of common infrastructure patterns. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/remote-exec-provisioner@JQE3_KakBXZdMVP_pPFNS.md b/roadmaps/terraform/content/remote-exec-provisioner@JQE3_KakBXZdMVP_pPFNS.md index ff8e3104c..3aafcb4aa 100644 --- a/roadmaps/terraform/content/remote-exec-provisioner@JQE3_KakBXZdMVP_pPFNS.md +++ b/roadmaps/terraform/content/remote-exec-provisioner@JQE3_KakBXZdMVP_pPFNS.md @@ -1,6 +1,6 @@ # remote-exec provisioner -The remote-exec provisioner in Terraform is used to invoke scripts directly on a remote resource after it has been created. This provisioner is commonly used for tasks like software installation, configuration, or any other setup required on the newly created resource. It can run either a list of commands or a script file on the remote system. The remote-exec provisioner requires a connection block to specify how to access the remote system, typically using SSH for Linux or WinRM for Windows. While useful for initial setup tasks, it's generally recommended to use this provisioner sparingly and prefer more robust configuration management tools for complex or ongoing management tasks. Care should be taken to ensure that scripts run by remote-exec are idempotent and handle potential network issues or other failures gracefully. +The `remote-exec` provisioner runs commands on the remote resource after it is created. It connects over SSH or WinRM and executes a list of inline commands or a script file. It is often used to install software or run configuration steps that cannot be handled by the provider. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/remote-state@pDm08NBVwGf9rAIZC_ZIR.md b/roadmaps/terraform/content/remote-state@pDm08NBVwGf9rAIZC_ZIR.md index e07a9ca65..b3f8a342a 100644 --- a/roadmaps/terraform/content/remote-state@pDm08NBVwGf9rAIZC_ZIR.md +++ b/roadmaps/terraform/content/remote-state@pDm08NBVwGf9rAIZC_ZIR.md @@ -1,6 +1,6 @@ # Remote State -Terraform remote state refers to storing the state file in a shared, centralized location rather than locally. This approach enables team collaboration, improves security, and ensures state consistency. Common remote backends include cloud storage services like AWS S3, Azure Blob Storage, or managed services like Terraform Cloud. Remote state allows multiple team members to safely work on the same infrastructure, prevents state file loss, and can provide locking mechanisms to avoid concurrent modifications. It's configured in the backend block of the Terraform configuration. Remote state can also be used to share outputs between different Terraform configurations, enabling modular infrastructure design. While more complex to set up initially, remote state is considered a best practice for production environments and team-based Terraform workflows. +Remote state stores the Terraform state file in a shared, remote backend such as S3, Azure Blob Storage, or Terraform Cloud. This allows multiple team members to work with the same state and prevents conflicts from concurrent operations. Remote backends also support state locking to prevent simultaneous writes. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/resource-behavior@BgZu7Xao5GjR8StVL7qhM.md b/roadmaps/terraform/content/resource-behavior@BgZu7Xao5GjR8StVL7qhM.md index 5cad11381..0fcaad214 100644 --- a/roadmaps/terraform/content/resource-behavior@BgZu7Xao5GjR8StVL7qhM.md +++ b/roadmaps/terraform/content/resource-behavior@BgZu7Xao5GjR8StVL7qhM.md @@ -1,6 +1,6 @@ # 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. +When Terraform applies a configuration, it determines what actions to take for each resource based on the difference between the desired state and the current state. Resources can be created, updated in place, destroyed and recreated, or left unchanged depending on what changed in the configuration. Some attributes require replacement rather than an in-place update. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/resource-lifecycle@76kp98rvph_8UOXZR-PBC.md b/roadmaps/terraform/content/resource-lifecycle@76kp98rvph_8UOXZR-PBC.md index 9e3516621..c81dfaf22 100644 --- a/roadmaps/terraform/content/resource-lifecycle@76kp98rvph_8UOXZR-PBC.md +++ b/roadmaps/terraform/content/resource-lifecycle@76kp98rvph_8UOXZR-PBC.md @@ -1,13 +1,6 @@ # Resource Lifecycle -Each Terraform resource is subject to the lifecycle: Create, Update or Recreate, Destroy. When executing `terraform apply`, each resource: - -* which exists in configuration but not in state is created -* which exists in configuration and state and has changed is updated -* which exists in configuration and state and has changed, but cannot updated due to API limitation is destroyed and recreated -* which exists in state, but not (anymore) in configuration is destroyed - -The lifecycle behaviour can be modified to some extend using the `lifecycle` meta argument. +The lifecycle meta-argument controls how Terraform manages a resource across plan and apply operations. Common settings include `create_before_destroy`, which ensures a replacement resource is created before the old one is removed, `prevent_destroy`, which blocks accidental deletion, and `ignore_changes`, which tells Terraform to ignore drift on specific attributes. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/rm@uR6Vjm8cek9JRzZV0iTXh.md b/roadmaps/terraform/content/rm@uR6Vjm8cek9JRzZV0iTXh.md index e47d3cc14..df2ea136c 100644 --- a/roadmaps/terraform/content/rm@uR6Vjm8cek9JRzZV0iTXh.md +++ b/roadmaps/terraform/content/rm@uR6Vjm8cek9JRzZV0iTXh.md @@ -1,6 +1,6 @@ # rm -The terraform state rm command is used to remove resources from the Terraform state without destroying the actual infrastructure. This command is useful when you want to stop managing a resource with Terraform without deleting it, or when you need to move a resource to a different state file. It takes one or more resource addresses as arguments, specifying which resources to remove from state. After removal, Terraform will no longer track or manage these resources, but they will continue to exist in your infrastructure. This command should be used carefully, as it can create discrepancies between your Terraform configuration and the actual state of your infrastructure. +`terraform state rm` removes one or more resources from the state file without destroying the actual infrastructure. This is used when you want Terraform to stop managing a resource, for example before importing it into a different workspace or before deleting it manually. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/root-vs-child-modules@6W4_akHG9YtvN6dpbZnG-.md b/roadmaps/terraform/content/root-vs-child-modules@6W4_akHG9YtvN6dpbZnG-.md index c65423cff..400744e47 100644 --- a/roadmaps/terraform/content/root-vs-child-modules@6W4_akHG9YtvN6dpbZnG-.md +++ b/roadmaps/terraform/content/root-vs-child-modules@6W4_akHG9YtvN6dpbZnG-.md @@ -1,6 +1,6 @@ # Root vs Child Modules -In Terraform, root and child modules refer to different levels of module hierarchy in a configuration. The root module is the main set of configuration files in the working directory where Terraform is executed. It's the entry point of your Terraform project and typically calls other modules. Child modules, on the other hand, are modules called by the root module or by other modules. They are reusable components that encapsulate specific resource configurations. Root modules define the overall architecture and compose child modules to create the complete infrastructure. Child modules focus on specific, repeatable tasks or resource groups. This hierarchy allows for better organization, reusability, and maintainability of Terraform code, enabling complex infrastructures to be broken down into manageable, modular components. +The root module is the working directory where Terraform is invoked. Child modules are called from the root module or from other modules using a `module` block. Child modules can be local directories or remote sources such as the Terraform Registry or a Git repository. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/run-tasks@nU1WoRtxRF9KeNhzuwNUB.md b/roadmaps/terraform/content/run-tasks@nU1WoRtxRF9KeNhzuwNUB.md index f2c6056c3..5e65fbc71 100644 --- a/roadmaps/terraform/content/run-tasks@nU1WoRtxRF9KeNhzuwNUB.md +++ b/roadmaps/terraform/content/run-tasks@nU1WoRtxRF9KeNhzuwNUB.md @@ -1,6 +1,6 @@ # Run Tasks -HCP Run Tasks, a feature of Terraform Cloud, allow for the integration of external services or custom logic into the Terraform workflow. These tasks can be configured to run before or after Terraform plans and applies, enabling additional validation, notification, or data processing steps. Run Tasks can be used for various purposes such as security scanning, cost estimation, custom policy checks, or triggering external workflows. They are executed via webhooks, allowing integration with a wide range of third-party services or internal tools. This feature enhances the flexibility and extensibility of the Terraform workflow, enabling organizations to implement custom processes and integrations tailored to their specific needs. +Run Tasks are integrations that execute external services at specific points in the Terraform run lifecycle, such as after a plan or before an apply. They can be used to trigger security scans, cost checks, or custom validation logic. Run tasks return a pass or fail result that can block or allow the apply from proceeding. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/scaling-terraform@ECcHo0KTDN27MuVTC-Fwy.md b/roadmaps/terraform/content/scaling-terraform@ECcHo0KTDN27MuVTC-Fwy.md index 6be796eea..eef8bfc60 100644 --- a/roadmaps/terraform/content/scaling-terraform@ECcHo0KTDN27MuVTC-Fwy.md +++ b/roadmaps/terraform/content/scaling-terraform@ECcHo0KTDN27MuVTC-Fwy.md @@ -1,5 +1,3 @@ # Scaling Terraform -Scaling Terraform involves strategies to manage large and complex infrastructure deployments efficiently. Key approaches include modularizing configurations to improve reusability and maintainability, using workspaces or separate state files for different environments, and implementing remote state storage with locking mechanisms. - -Efficient state management becomes crucial, often involving state splitting to reduce operation times. Adopting a CI/CD pipeline for Terraform helps automate and standardize deployment processes. Implementing proper access controls and using features like Terraform Cloud or Enterprise for team collaboration and governance becomes important. Performance optimization techniques, such as using -parallelism flag and targeted applies, help manage large-scale changes. As scale increases, considerations around cost management, security, and compliance gain prominence. Effective scaling often requires a balance between centralized control and distributed team autonomy in infrastructure management. \ No newline at end of file +As infrastructure grows, Terraform configurations must be structured to remain manageable, performant, and safe for teams to use concurrently. Scaling strategies include splitting state, parallelizing operations, enforcing consistent deployment workflows, and managing version drift across modules and providers. \ No newline at end of file diff --git a/roadmaps/terraform/content/secret-management@uVz9WwVAgMu1ZU0qjqVnc.md b/roadmaps/terraform/content/secret-management@uVz9WwVAgMu1ZU0qjqVnc.md index 5a99ece92..1614ba259 100644 --- a/roadmaps/terraform/content/secret-management@uVz9WwVAgMu1ZU0qjqVnc.md +++ b/roadmaps/terraform/content/secret-management@uVz9WwVAgMu1ZU0qjqVnc.md @@ -1,6 +1,6 @@ # Secret Management -Terraform secret management is a critical aspect of secure infrastructure-as-code practices, focusing on the protection of sensitive information like API keys, passwords, and access tokens. Instead of storing secrets directly in Terraform files, best practices advocate for using external secret management systems such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These systems allow Terraform to retrieve secrets securely during execution, significantly reducing the risk of exposure. For local development, tools like git-crypt or SOPS provide encryption for sensitive files, while Terraform's built-in encrypted state storage options safeguard secrets in state files. By marking variables as sensitive, accidental logging of secret values can be prevented. In CI/CD pipelines, it's crucial to inject secrets securely at runtime and avoid committing them to version control systems. Regular rotation of secrets and access audits further enhance security. +Secrets such as API keys, passwords, and certificates should never be stored in Terraform configuration files or committed to version control. Common approaches include injecting secrets via environment variables, using a secrets manager like HashiCorp Vault or AWS Secrets Manager as a data source, or using a backend that encrypts sensitive state values. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/security@3MnZK2V5KhBhw67SyUVPk.md b/roadmaps/terraform/content/security@3MnZK2V5KhBhw67SyUVPk.md index 31bf71a7b..2dfb8c8a5 100644 --- a/roadmaps/terraform/content/security@3MnZK2V5KhBhw67SyUVPk.md +++ b/roadmaps/terraform/content/security@3MnZK2V5KhBhw67SyUVPk.md @@ -1,6 +1,6 @@ # Security -Terraform security encompasses practices and tools to ensure the safe and compliant management of infrastructure-as-code. Key aspects include securing Terraform state files, which often contain sensitive information, by using encrypted remote backends. Access control is crucial, implementing least privilege principles for both human users and service accounts. Sensitive data management involves using vault systems or cloud-native secret managers rather than hardcoding credentials. Code review processes should include security checks, and automated scanning tools can be integrated to detect misconfigurations or policy violations. Implementing compliance-as-code with tools like Terraform Sentinel ensures adherence to organizational policies. Version control and proper git hygiene help maintain audit trails. +Securing a Terraform workflow involves protecting secrets, enforcing policy on what infrastructure can be provisioned, and scanning configurations for misconfigurations before they reach production. A layered approach combines secret management, policy as code, and static analysis tools. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/sensitive-data@16vLOPP9lTCuBh0q-UVMk.md b/roadmaps/terraform/content/sensitive-data@16vLOPP9lTCuBh0q-UVMk.md index 174f4abcd..7d1b82d1d 100644 --- a/roadmaps/terraform/content/sensitive-data@16vLOPP9lTCuBh0q-UVMk.md +++ b/roadmaps/terraform/content/sensitive-data@16vLOPP9lTCuBh0q-UVMk.md @@ -1,6 +1,6 @@ # Sensitive Data -Terraform state files often contain sensitive data like passwords, API keys, and other secrets used in resource configurations. This data is stored in plaintext within the state file, posing a security risk if the file is compromised. To mitigate this, Terraform offers several approaches: marking variables as sensitive to prevent them from appearing in logs, using encrypted remote backends for state storage, implementing strict access controls on state files, and utilizing external secret management systems. It's crucial to treat state files as sensitive and secure them accordingly. For highly sensitive environments, some teams opt to store certain secrets outside of Terraform entirely, injecting them at runtime. Regularly auditing state files for sensitive information and implementing proper security measures is essential for maintaining the confidentiality of infrastructure secrets in Terraform deployments. +Terraform state may contain sensitive data such as passwords, private keys, and tokens returned by provider APIs. State files should be stored securely, with access restricted to authorized users and systems. Remote backends with encryption at rest and access controls are strongly recommended for any production use. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/sensitive-outputs@8giL6H5944M2L0rwxjPso.md b/roadmaps/terraform/content/sensitive-outputs@8giL6H5944M2L0rwxjPso.md index aec02c5c9..fe1fb97d7 100644 --- a/roadmaps/terraform/content/sensitive-outputs@8giL6H5944M2L0rwxjPso.md +++ b/roadmaps/terraform/content/sensitive-outputs@8giL6H5944M2L0rwxjPso.md @@ -1,16 +1,6 @@ # Sensitive Outputs -Terraform sensitive outputs are a feature used to protect sensitive information in Terraform configurations. When an output is marked as sensitive, Terraform obscures its value in the console output, displaying it as `` instead of the actual value. This is crucial for protecting sensitive data like passwords or API keys. - -To mark an output as sensitive, use the sensitive argument in the output block: - - output "database_password" { - value = aws_db_instance.example.password - sensitive = true - } - - -Sensitive outputs are still accessible programmatically and are written to the state in clear text, but their values are hidden in logs and the console to prevent accidental exposure. This feature helps maintain security when sharing Terraform configurations or outputs with team members or in CI/CD pipelines. +Marking an output as sensitive tells Terraform to redact its value from CLI output and logs. The value is still stored in state and can be accessed programmatically. This is commonly used for passwords, tokens, and other secrets that should not appear in plain text in terminal output. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/show@7DZB2VeyuouFXOdFEfeZt.md b/roadmaps/terraform/content/show@7DZB2VeyuouFXOdFEfeZt.md index 42e03aaf9..e339fd589 100644 --- a/roadmaps/terraform/content/show@7DZB2VeyuouFXOdFEfeZt.md +++ b/roadmaps/terraform/content/show@7DZB2VeyuouFXOdFEfeZt.md @@ -1,6 +1,6 @@ # show -The terraform show command displays a human-readable view of the current state or a saved plan file. When used without arguments, it presents the current state of the managed infrastructure, including all resources and their attributes. If given a path to a saved plan file, it shows the changes that would be made by applying that plan. This command is useful for inspecting the current state of your infrastructure, verifying the details of specific resources, or reviewing planned changes before applying them. It provides a comprehensive overview of your Terraform-managed resources, making it valuable for debugging, auditing, and understanding the current state of your infrastructure. The output includes sensitive information if present, so care should be taken when sharing or displaying the results in unsecured environments. +`terraform show` displays a human-readable representation of the current state or a saved plan file. It is useful for reviewing what Terraform currently knows about managed resources without running a full plan. Passing a plan file shows the exact changes that will be applied. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/splitting-large-state@zCU02_5Pide5BZiuMuqEU.md b/roadmaps/terraform/content/splitting-large-state@zCU02_5Pide5BZiuMuqEU.md index 357daab6e..40841e81e 100644 --- a/roadmaps/terraform/content/splitting-large-state@zCU02_5Pide5BZiuMuqEU.md +++ b/roadmaps/terraform/content/splitting-large-state@zCU02_5Pide5BZiuMuqEU.md @@ -1,5 +1,3 @@ # Splitting Large State -Splitting large Terraform states involves breaking down a monolithic state file into smaller, more manageable units. This approach is crucial for improving performance, reducing the risk of state corruption, and enabling parallel workflows in large-scale infrastructures. Strategies include organizing resources into separate Terraform workspaces or using distinct state files for different logical components or environments. The process often involves using `terraform state mv` to relocate resources between states or `terraform state rm` followed by `import` in the new configuration. Careful planning is essential to manage dependencies between split states. Benefits include faster apply times, reduced risk of concurrent modification conflicts, and the ability to grant more granular access control. - -See `Splitting State Files` in the `State` topic for more resources. \ No newline at end of file +Large state files slow down plans and increase the risk of conflicts. Splitting infrastructure into smaller, independently managed configurations with their own state files reduces plan times and limits the impact of a failed apply. Resources in different state files communicate through remote state data sources or variable passing. \ No newline at end of file diff --git a/roadmaps/terraform/content/splitting-state-files@a0rUMnYluVUGhyhlDK5S8.md b/roadmaps/terraform/content/splitting-state-files@a0rUMnYluVUGhyhlDK5S8.md index bea3afc73..84f87de25 100644 --- a/roadmaps/terraform/content/splitting-state-files@a0rUMnYluVUGhyhlDK5S8.md +++ b/roadmaps/terraform/content/splitting-state-files@a0rUMnYluVUGhyhlDK5S8.md @@ -1,6 +1,6 @@ # Splitting State Files -Splitting Terraform state files involves dividing a large state into smaller, more manageable parts. This is typically done using Terraform workspaces or by organizing resources into separate modules with their own state files. The process helps manage complex infrastructures, improves performance, and allows for more granular access control. To split an existing state, you can use `terraform state mv` to move resources between states, or `terraform state rm` followed by `terraform import` in a new configuration. This approach is beneficial for large projects, enabling teams to work on different parts of infrastructure independently. However, it requires careful planning to manage dependencies between split states. Proper state splitting can lead to more efficient workflows, easier troubleshooting, and better alignment with organizational structures in large-scale Terraform deployments. +Large Terraform configurations can be split into multiple state files by organizing resources into separate workspaces or root modules. This reduces the blast radius of plan and apply operations, speeds up plans, and makes it easier for teams to work independently on different parts of the infrastructure. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/state-force-unlock@Trpi2ZlnXZVYJCibE2bQ8.md b/roadmaps/terraform/content/state-force-unlock@Trpi2ZlnXZVYJCibE2bQ8.md index 2f88fc1de..b926f90bb 100644 --- a/roadmaps/terraform/content/state-force-unlock@Trpi2ZlnXZVYJCibE2bQ8.md +++ b/roadmaps/terraform/content/state-force-unlock@Trpi2ZlnXZVYJCibE2bQ8.md @@ -1,6 +1,6 @@ # state force-unlock -The terraform `state force-unlock` command in Terraform is used to manually release a stuck state lock. State locking is a mechanism that prevents concurrent operations on the same state, but occasionally a lock may not be properly released due to crashes or network issues. This command allows administrators to forcibly remove the lock, enabling further Terraform operations to proceed. It should be used with extreme caution, as it can lead to state corruption if multiple users are attempting to modify the state simultaneously. Before using force-unlock, it's crucial to ensure that no other Terraform operations are genuinely in progress. This command is typically a last resort for resolving locking issues and should only be employed when certain that the lock is erroneously held and no conflicting operations are ongoing. +`terraform state force-unlock` manually releases a state lock that was not properly released after an interrupted operation. It requires the lock ID, which is displayed in the error message shown when a lock conflict is detected. This command should only be used when you are certain no other Terraform operation is running. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/state-locking@GseYuG9wT8H9R_enxWzuQ.md b/roadmaps/terraform/content/state-locking@GseYuG9wT8H9R_enxWzuQ.md index 265c2a5b7..00d837a5d 100644 --- a/roadmaps/terraform/content/state-locking@GseYuG9wT8H9R_enxWzuQ.md +++ b/roadmaps/terraform/content/state-locking@GseYuG9wT8H9R_enxWzuQ.md @@ -1,6 +1,6 @@ # State Locking -Terraform state locking is a mechanism that prevents concurrent modifications to the same state file, avoiding potential conflicts and data corruption. When enabled, Terraform acquires a lock before performing operations that could modify the state, such as apply or destroy. If the lock is unavailable, Terraform waits or fails, depending on configuration. State locking is automatically supported by many backend types, including S3 with DynamoDB, Azure Blob Storage, and Terraform Cloud. It's crucial for team environments where multiple users or automation processes might attempt simultaneous changes. While essential for data integrity, it's important to implement proper lock management to prevent stuck locks from blocking operations. +State locking prevents two Terraform operations from modifying state at the same time. When supported by the backend, Terraform acquires a lock before writing to state and releases it when the operation completes. If a lock is not released due to a crash or error, it can be manually removed with the `force-unlock` command. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/state-pull--push@wSh7bbPswcFAzOicX8VPx.md b/roadmaps/terraform/content/state-pull--push@wSh7bbPswcFAzOicX8VPx.md index 9502ec104..a6d0f74f9 100644 --- a/roadmaps/terraform/content/state-pull--push@wSh7bbPswcFAzOicX8VPx.md +++ b/roadmaps/terraform/content/state-pull--push@wSh7bbPswcFAzOicX8VPx.md @@ -1,8 +1,6 @@ # state pull / push -The `terraform state pull` and `terraform state push` commands are used for managing Terraform state in remote backends. The `pull` command retrieves the current state from the configured backend and outputs it to stdout, allowing for inspection or backup of the remote state. It's useful for debugging or for performing manual state manipulations. - -The `push` command does the opposite, uploading a local state file to the configured backend, overwriting the existing remote state. This is typically used to restore a backup or to manually reconcile state discrepancies. Both commands should be used with caution, especially push, as they can potentially overwrite important state information. +`terraform state pull` downloads the current remote state and prints it to stdout. `terraform state push` uploads a local state file to the configured backend, overwriting the remote state. These commands are used for manual state recovery or migration and should be used with caution. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/state-replace-provider@Os6AOXp1CVI_Bh3NYnX17.md b/roadmaps/terraform/content/state-replace-provider@Os6AOXp1CVI_Bh3NYnX17.md index b1c072a90..b3cdbea5d 100644 --- a/roadmaps/terraform/content/state-replace-provider@Os6AOXp1CVI_Bh3NYnX17.md +++ b/roadmaps/terraform/content/state-replace-provider@Os6AOXp1CVI_Bh3NYnX17.md @@ -1,6 +1,6 @@ # state replace-provider -The terraform `state replace-provider` command in Terraform is used to update the provider information in the state file without altering the actual infrastructure. This command is particularly useful when migrating from one provider to another, or when updating to a new major version of a provider that involves a change in the provider's namespace. It allows users to change the provider associated with resources in the state file, effectively telling Terraform to use a different provider for managing these resources in future operations. This command is crucial for maintaining state consistency during provider transitions or upgrades, especially in large-scale infrastructures. While it doesn't modify the actual resources, it updates Terraform's understanding of which provider should be used to manage them, facilitating smooth provider migrations without requiring resource recreation. +`terraform state replace-provider` updates all resource entries in the state that reference one provider to reference a different provider. This is used when migrating resources to a forked or renamed provider without destroying and recreating them. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/state@5xAE-9viD7DP_ugQ6NE_C.md b/roadmaps/terraform/content/state@5xAE-9viD7DP_ugQ6NE_C.md index 108ee8f82..80027354d 100644 --- a/roadmaps/terraform/content/state@5xAE-9viD7DP_ugQ6NE_C.md +++ b/roadmaps/terraform/content/state@5xAE-9viD7DP_ugQ6NE_C.md @@ -1,6 +1,6 @@ # State -Terraform state is a crucial concept in Terraform that tracks the current state of your managed infrastructure. It's typically stored in a file named terraform.tfstate, which maps real-world resources to your configuration. This state allows Terraform to determine which changes are necessary to achieve the desired configuration. It contains sensitive information and should be stored securely, often in remote backends like S3 or Terraform Cloud. The state can be manipulated using terraform state commands for tasks like moving resources between states or removing resources from management. Proper state management is essential for collaborative work, ensuring consistency across team members and enabling Terraform to accurately plan and apply changes to your infrastructure. +Terraform state is a file that records the current status of managed infrastructure. It maps resources in the configuration to real-world objects and stores attribute values returned by the provider after creation. State is used to compute diffs during planning and to track resource identity across operations. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/template-files@tB4zfwY4E3GmXo-XQwS-l.md b/roadmaps/terraform/content/template-files@tB4zfwY4E3GmXo-XQwS-l.md index 2a3c61b66..ad8fb3a37 100644 --- a/roadmaps/terraform/content/template-files@tB4zfwY4E3GmXo-XQwS-l.md +++ b/roadmaps/terraform/content/template-files@tB4zfwY4E3GmXo-XQwS-l.md @@ -1,6 +1,6 @@ # Template Files -Terraform template files are a powerful feature for creating customizable, reusable configuration snippets. These files, typically with a `.tftpl` extension, contain placeholders that can be filled with variables at runtime. Terraform uses the `templatefile` function to process these files, replacing variables with actual values. This approach is useful for generating configuration files, scripts, or any text-based content that needs to be parameterized. Template files enhance modularity and reduce repetition in Terraform configurations. They're commonly used for creating user data scripts for EC2 instances, generating complex JSON configurations, or preparing any text-based resource that requires dynamic content. The `templatefile` function reads the contents of a file and renders its template syntax with a given set of variables, allowing for dynamic and flexible resource configurations. +Template files use the `templatefile` function to render a file with variable substitutions at plan time. The function takes a file path and a map of values and returns the rendered string. Template files are commonly used to generate user data scripts, configuration files, or policy documents from dynamic values. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/terraform-destroy@LPI13FILvkD55hWcWbPrV.md b/roadmaps/terraform/content/terraform-destroy@LPI13FILvkD55hWcWbPrV.md index 79e8bbc9d..e56f33d70 100644 --- a/roadmaps/terraform/content/terraform-destroy@LPI13FILvkD55hWcWbPrV.md +++ b/roadmaps/terraform/content/terraform-destroy@LPI13FILvkD55hWcWbPrV.md @@ -1,6 +1,6 @@ # terraform destroy -terraform destroy is a command used to remove all resources managed by a Terraform configuration. It creates a plan to delete all resources and prompts for confirmation before execution. This command is useful for cleaning up temporary environments or decommissioning entire infrastructures. It removes resources in the reverse order of their dependencies to ensure proper teardown. While powerful, terraform destroy should be used cautiously, especially in shared or production environments, as it can lead to data loss if not carefully managed. It's often used in conjunction with terraform state commands for more granular control over resource removal. After destruction, Terraform updates the state file to reflect the changes, but it's important to manage or remove this file if the project is being completely decommissioned. +`terraform destroy` removes all resources managed by the current configuration. It is the equivalent of running `terraform apply` with every resource marked for deletion. Like apply, it shows a plan and prompts for confirmation before proceeding. Individual resources can also be targeted with the `-target` flag. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/terraform-fmt@78bGm8J5Y1I8H4qioOvWb.md b/roadmaps/terraform/content/terraform-fmt@78bGm8J5Y1I8H4qioOvWb.md index a2c2f6f68..e2b0e2b93 100644 --- a/roadmaps/terraform/content/terraform-fmt@78bGm8J5Y1I8H4qioOvWb.md +++ b/roadmaps/terraform/content/terraform-fmt@78bGm8J5Y1I8H4qioOvWb.md @@ -1,6 +1,6 @@ # terraform fmt -terraform fmt is a command in Terraform that automatically formats configuration files to a consistent style. It adjusts indentation, aligns arguments, and sorts blocks and arguments alphabetically. The command rewrites Terraform configuration files (.tf and .tfvars) in the current directory and its subdirectories. It's used to maintain a consistent coding style across projects and teams, improving readability and reducing merge conflicts. The command can be run with options like -recursive to format files in subdirectories, -diff to show the differences, or -check to validate formatting without making changes. Regularly using terraform fmt is considered a best practice in Terraform development workflows. +`terraform fmt` rewrites Terraform configuration files to the canonical format and style defined by HashiCorp. It adjusts indentation, alignment, and spacing. Running it regularly, or as part of a pre-commit hook, keeps configurations consistent across a team. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/terraform-plan@LDxAXmTKyvogvgUpvN5pT.md b/roadmaps/terraform/content/terraform-plan@LDxAXmTKyvogvgUpvN5pT.md index 33b30018c..db5daf3c2 100644 --- a/roadmaps/terraform/content/terraform-plan@LDxAXmTKyvogvgUpvN5pT.md +++ b/roadmaps/terraform/content/terraform-plan@LDxAXmTKyvogvgUpvN5pT.md @@ -1,6 +1,6 @@ # terraform plan -`terraform plan` is a command that creates an execution plan, showing what changes Terraform will make to your infrastructure. It compares the current state with the desired state defined in configuration files and outputs a detailed list of resources to be created, modified, or deleted. Importantly, it doesn't make any actual changes to infrastructure, instead helping identify potential issues before applying changes. The plan can be saved to a file for later execution or review. This command is crucial for reviewing changes before implementation, especially in complex environments, and is commonly used in code reviews and CI/CD pipelines to validate proposed infrastructure modifications. While terraform plan provides a preview, it's worth noting that it can't always predict every change due to external factors or API limitations. +`terraform plan` computes the difference between the current state and the desired configuration and displays the actions Terraform would take. It does not make any changes to infrastructure. The plan can be saved to a file and passed to `terraform apply` to ensure the exact previewed changes are applied. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/terragrunt@AEtW6j2GcfZz7IXk4sM6c.md b/roadmaps/terraform/content/terragrunt@AEtW6j2GcfZz7IXk4sM6c.md index 88c258a9e..808097b92 100644 --- a/roadmaps/terraform/content/terragrunt@AEtW6j2GcfZz7IXk4sM6c.md +++ b/roadmaps/terraform/content/terragrunt@AEtW6j2GcfZz7IXk4sM6c.md @@ -1,6 +1,6 @@ # Terragrunt -Terragrunt is a thin wrapper for Terraform that provides extra tools for keeping your configurations DRY (Don't Repeat Yourself), working with multiple Terraform modules, and managing remote state. It helps in managing large-scale infrastructure by reducing code duplication and simplifying the management of multiple environments. Key features include the ability to keep Terraform code DRY by defining inputs and backend configurations centrally, execute Terraform commands on multiple modules at once, and manage remote state for each module automatically. Terragrunt also facilitates the use of Terraform modules across different environments by allowing for easy parameter injection. It's particularly useful in complex, multi-environment setups where maintaining consistency and reducing repetition in Terraform configurations is crucial. +Terragrunt is a thin wrapper around Terraform that adds support for keeping configurations DRY, managing dependencies between modules, and running commands across multiple modules at once. It uses `terragrunt.hcl` files to define module sources, variable inputs, and backend configuration. It is widely used in large multi-account or multi-environment Terraform setups. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/terrascan@NSWG79dEygyl6pb54wLrE.md b/roadmaps/terraform/content/terrascan@NSWG79dEygyl6pb54wLrE.md index 02656cfca..fb08224f7 100644 --- a/roadmaps/terraform/content/terrascan@NSWG79dEygyl6pb54wLrE.md +++ b/roadmaps/terraform/content/terrascan@NSWG79dEygyl6pb54wLrE.md @@ -1,6 +1,6 @@ # Terrascan -Terrascan is an open-source static code analyzer for Infrastructure as Code (IaC) that helps detect compliance and security violations across multiple IaC tools, including Terraform. It scans Terraform configurations against a set of predefined policies to identify potential security risks, misconfigurations, and compliance issues before deployment. Terrascan can be integrated into CI/CD pipelines, providing early detection of vulnerabilities in the development lifecycle. It supports custom policies, allowing organizations to enforce their specific security and compliance requirements. The tool covers various cloud providers and can be extended to support additional policy types. +Terrascan is an open-source static analysis tool that scans Terraform configurations for security and compliance violations before deployment. It checks against a library of built-in policies covering common cloud security standards and supports custom rules. It can be integrated into CI pipelines to fail builds that introduce insecure configurations. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/testing-modules@H3_So6qX-s2131WHGR_GO.md b/roadmaps/terraform/content/testing-modules@H3_So6qX-s2131WHGR_GO.md index 1c6b1b8af..42270392a 100644 --- a/roadmaps/terraform/content/testing-modules@H3_So6qX-s2131WHGR_GO.md +++ b/roadmaps/terraform/content/testing-modules@H3_So6qX-s2131WHGR_GO.md @@ -1,6 +1,6 @@ # Testing Modules -Testing Terraform modules involves validating their functionality, reusability, and correctness in isolation and as part of larger systems. This process typically includes unit testing to verify individual module behavior, integration testing to ensure proper interaction with other components, and sometimes end-to-end testing for complex modules. Tests often use tools like Terratest or custom scripts to automate the creation of resources, verification of outputs, and cleanup. Key aspects include testing various input combinations, verifying resource attributes and outputs, and ensuring idempotency. Module testing also involves checking for proper handling of edge cases and error conditions. While it requires initial setup effort, thorough module testing enhances reliability, facilitates refactoring, and improves overall infrastructure code quality. +Testing modules involves validating their logic, variable handling, and output values in isolation before they are used in a larger configuration. The `terraform test` command can apply a module with test-specific variable values and assert expected output values. Keeping modules testable means writing them with clear inputs and outputs and minimal side effects. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/testing@QSftI21seX6I_xPonlfmU.md b/roadmaps/terraform/content/testing@QSftI21seX6I_xPonlfmU.md index a0b43bb1d..391906894 100644 --- a/roadmaps/terraform/content/testing@QSftI21seX6I_xPonlfmU.md +++ b/roadmaps/terraform/content/testing@QSftI21seX6I_xPonlfmU.md @@ -1,3 +1,3 @@ # Testing -Testing Terraform code involves multiple approaches to ensure reliability and correctness of infrastructure-as-code. This includes syntax validation, linting for best practices, unit testing of modules, integration testing to verify resource creation, plan testing to review expected changes, and compliance testing for organizational policies. Tools like TFLint and frameworks such as Terratest are commonly used. Automated testing in CI/CD pipelines helps catch errors early and maintain code quality. Mock providers can be employed for testing without affecting real infrastructure, while property-based testing explores different input combinations. Effective testing strategies balance thoroughness with practicality, considering factors like execution time and resource costs. \ No newline at end of file +Testing Terraform configurations verifies that infrastructure behaves as expected before and after deployment. Testing strategies range from static analysis and unit tests on modules to integration and end-to-end tests that provision real infrastructure. A layered testing approach catches different classes of problems at different stages of development. \ No newline at end of file diff --git a/roadmaps/terraform/content/tflint@YftsQYpcqJqBKPjy5tWOq.md b/roadmaps/terraform/content/tflint@YftsQYpcqJqBKPjy5tWOq.md index 697cf41a0..25c91fa53 100644 --- a/roadmaps/terraform/content/tflint@YftsQYpcqJqBKPjy5tWOq.md +++ b/roadmaps/terraform/content/tflint@YftsQYpcqJqBKPjy5tWOq.md @@ -1,8 +1,6 @@ # TFLint -TFLint is a third-party, extensible linter for Terraform code. It performs static analysis of Terraform configurations to detect potential errors, enforce best practices, and maintain code consistency. Key features include: Checking for potential errors that terraform validate might miss, enforcing naming conventions and code style rules, identifying deprecated syntax or resource types and, providing cloud provider-specific checks. - -TFLint is configurable via .tflint.hcl files and supports custom rules. It can be integrated into CI/CD pipelines for automated code quality checks. While not an official Terraform tool, TFLint is widely used in the Terraform community to complement built-in validation tools and improve overall code quality and reliability in infrastructure-as-code projects. +TFLint is a Terraform linter that goes beyond the checks provided by `terraform validate`. It detects errors specific to provider APIs, such as invalid instance types or unsupported regions, and can enforce custom coding rules through plugins. It is commonly run in CI pipelines alongside `terraform validate`. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/trivy@Vxo_gNdFl3CZXV7GLPqjD.md b/roadmaps/terraform/content/trivy@Vxo_gNdFl3CZXV7GLPqjD.md index bbf54d51e..0a29e7d3b 100644 --- a/roadmaps/terraform/content/trivy@Vxo_gNdFl3CZXV7GLPqjD.md +++ b/roadmaps/terraform/content/trivy@Vxo_gNdFl3CZXV7GLPqjD.md @@ -1,6 +1,6 @@ # Trivy -Trivy is a comprehensive, open-source security scanner primarily known for container image scanning, but it also supports Infrastructure as Code (IaC) analysis, including Terraform configurations. It can detect vulnerabilities in dependencies, misconfigurations in cloud infrastructure setups, and potential security risks in Terraform code. Trivy's IaC scanning capabilities cover various cloud providers and can identify issues related to compliance, security best practices, and common misconfigurations. The tool is designed for easy integration into CI/CD pipelines, offering fast scanning times and multiple output formats for better reporting and integration with other DevOps tools. Trivy's strength lies in its ability to provide a unified scanning solution across different aspects of the software development lifecycle, from container images to IaC, making it a versatile tool for maintaining security throughout the development and deployment process. +Trivy is a security scanner that can analyze Terraform configurations for misconfigurations in addition to scanning container images and filesystems. It checks infrastructure code against a set of built-in rules and reports issues by severity. Trivy is easy to integrate into CI workflows and supports multiple output formats. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/unit-testing@V7_NnDIY1MefV_xjCCsnI.md b/roadmaps/terraform/content/unit-testing@V7_NnDIY1MefV_xjCCsnI.md index e9b4f369b..6204ce44b 100644 --- a/roadmaps/terraform/content/unit-testing@V7_NnDIY1MefV_xjCCsnI.md +++ b/roadmaps/terraform/content/unit-testing@V7_NnDIY1MefV_xjCCsnI.md @@ -1,6 +1,6 @@ # Unit Testing -Terraform unit testing focuses on verifying the behavior of individual modules or components in isolation. It typically involves creating small, focused test cases that validate the expected outputs and resource configurations of a module given specific inputs. Tools like Terratest, a Go library, are commonly used for writing and running these tests. Unit tests for Terraform might check if resources are correctly defined, if count and for\_each meta-arguments work as expected, or if output values are calculated correctly. These tests often use mock data or minimal real infrastructure to simulate various scenarios. While they don't guarantee the actual creation of resources, unit tests are valuable for quickly catching logic errors, ensuring module interfaces work as intended, and maintaining code quality as modules evolve. +Unit tests for Terraform validate individual modules in isolation, checking that inputs produce the expected plan output without provisioning real resources. The native `terraform test` command introduced in Terraform 1.6 supports this by running configurations in a controlled context. Tools like Terratest can also be used for more complex scenarios. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/usecases-and-benefits@hRIDJHIxWc5Iav7tsu8l-.md b/roadmaps/terraform/content/usecases-and-benefits@hRIDJHIxWc5Iav7tsu8l-.md index 6cf8daca1..865738a4a 100644 --- a/roadmaps/terraform/content/usecases-and-benefits@hRIDJHIxWc5Iav7tsu8l-.md +++ b/roadmaps/terraform/content/usecases-and-benefits@hRIDJHIxWc5Iav7tsu8l-.md @@ -1,6 +1,6 @@ # 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. +Terraform is used to automate the provisioning of cloud resources, manage multi-cloud environments from a single workflow, and enforce consistent infrastructure configurations across teams. Key benefits include reproducibility, reduced human error, faster deployments, and a full audit trail of infrastructure changes through version control. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/vcs-integration@Z6dG92afC8SGwCFNTx4ac.md b/roadmaps/terraform/content/vcs-integration@Z6dG92afC8SGwCFNTx4ac.md index e7449c659..ced46a619 100644 --- a/roadmaps/terraform/content/vcs-integration@Z6dG92afC8SGwCFNTx4ac.md +++ b/roadmaps/terraform/content/vcs-integration@Z6dG92afC8SGwCFNTx4ac.md @@ -1,6 +1,6 @@ # VCS Integration -HCP's Version Control System (VCS) integration, particularly in Terraform Cloud, enables seamless connection between infrastructure code repositories and HCP services. This feature allows teams to directly link their Git repositories (from providers like GitHub, GitLab, or Bitbucket) to HCP workspaces. When configured, changes pushed to the linked repository automatically trigger Terraform runs in the corresponding workspace. This integration supports GitOps workflows, ensuring that infrastructure changes go through proper version control processes. It enables features like automatic plan generation on pull requests, providing early feedback on proposed changes. The integration also supports branch-based workflows, allowing different branches to be linked to different workspaces for staging and production environments. +HCP Terraform integrates with version control systems including GitHub, GitLab, Bitbucket, and Azure DevOps. Linking a workspace to a VCS repository triggers speculative plans on pull requests and applies on merges to the configured branch. This brings infrastructure changes into the same code review workflow as application changes. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/version-management@6zFuSNOfbPaYIE_t--2nr.md b/roadmaps/terraform/content/version-management@6zFuSNOfbPaYIE_t--2nr.md index 6eb5e1428..27c63c389 100644 --- a/roadmaps/terraform/content/version-management@6zFuSNOfbPaYIE_t--2nr.md +++ b/roadmaps/terraform/content/version-management@6zFuSNOfbPaYIE_t--2nr.md @@ -1,6 +1,6 @@ # Version Management -Version management in Terraform is crucial for maintaining consistency across different environments and team members. Tools like `tfenv` allow developers to easily switch between different versions of Terraform. `tfenv` is a version manager that installs and manages multiple Terraform versions on a single system. It enables teams to specify and use specific Terraform versions for different projects, ensuring compatibility and reproducibility. This tool, along with others like `tfswitch`, helps manage potential conflicts arising from version differences, facilitates easier upgrades, and supports working on multiple projects with varying Terraform version requirements. +Managing Terraform and provider versions across a team requires consistent tooling. `tfenv` is a popular version manager for Terraform that allows switching between installed versions based on a `.terraform-version` file. Pinning versions in `required_version` and `required_providers` blocks ensures everyone uses compatible releases. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/versioning@1T35eNO18qoyXcX7S-Jox.md b/roadmaps/terraform/content/versioning@1T35eNO18qoyXcX7S-Jox.md index e8000852c..409097fac 100644 --- a/roadmaps/terraform/content/versioning@1T35eNO18qoyXcX7S-Jox.md +++ b/roadmaps/terraform/content/versioning@1T35eNO18qoyXcX7S-Jox.md @@ -1,6 +1,6 @@ # Versioning -Terraform state versioning refers to the practice of maintaining multiple versions of the state file over time. While Terraform itself doesn't provide built-in versioning, it's typically achieved through backend configurations that support versioning, such as Amazon S3 with versioning enabled or Terraform Cloud. This approach allows teams to track changes, rollback to previous states if needed, and maintain an audit trail of infrastructure modifications. Versioning helps in recovering from accidental state corruptions or deletions, and in understanding the evolution of infrastructure over time. It's considered a best practice for production environments, enhancing disaster recovery capabilities and providing insights into infrastructure changes. +State files can be versioned using backends that support versioning, such as S3 with versioning enabled. Keeping a history of state versions allows you to roll back to a previous state if a bad apply corrupts or loses data. Terraform Cloud and Enterprise provide built-in state history and the ability to restore past versions. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/what-and-when-to-use-hcp@K_7dB-5cCYzGbwYXXaoiY.md b/roadmaps/terraform/content/what-and-when-to-use-hcp@K_7dB-5cCYzGbwYXXaoiY.md index 9ac63962d..960028b13 100644 --- a/roadmaps/terraform/content/what-and-when-to-use-hcp@K_7dB-5cCYzGbwYXXaoiY.md +++ b/roadmaps/terraform/content/what-and-when-to-use-hcp@K_7dB-5cCYzGbwYXXaoiY.md @@ -1,6 +1,6 @@ # What and when to use HCP? -HashiCorp Cloud Platform (HCP) is best used when organizations need a managed, scalable solution for their infrastructure-as-code practices. It's particularly valuable for teams seeking to streamline operations across multi-cloud environments, enhance collaboration, and maintain consistent governance. HCP is ideal when there's a need for centralized management of Terraform workflows, secure remote operations, and integrated secrets management. It's beneficial for large enterprises or growing teams that require robust access controls, policy enforcement, and audit capabilities. HCP should be considered when the complexity of self-managing HashiCorp tools becomes a burden, or when there's a desire to reduce operational overhead. It's also useful when organizations want to leverage the synergies between different HashiCorp products like Terraform, Vault, and Consul in a unified, managed environment. The platform is most effective when scaling infrastructure management needs outgrow the capabilities of standalone Terraform implementations. +HCP Terraform is appropriate when a team wants the benefits of Terraform Cloud, such as remote runs, state management, and policy enforcement, without managing infrastructure for it. It suits teams that are scaling beyond local Terraform workflows and need collaboration features, audit logs, and a managed backend. It is available in free and paid tiers. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/when-to-use@CmmoshFC1dKE4y3SMN2bl.md b/roadmaps/terraform/content/when-to-use@CmmoshFC1dKE4y3SMN2bl.md index caa05c31e..4915ddff3 100644 --- a/roadmaps/terraform/content/when-to-use@CmmoshFC1dKE4y3SMN2bl.md +++ b/roadmaps/terraform/content/when-to-use@CmmoshFC1dKE4y3SMN2bl.md @@ -1,6 +1,6 @@ # When to Use? -Provisioners in Terraform should be used judiciously, primarily when other declarative options are insufficient. They're appropriate for tasks that can't be accomplished through Terraform's resource configurations or data sources. Common scenarios include running initialization scripts on newly created servers, installing software not covered by provider-specific resources, or performing one-time setup tasks. Provisioners are useful for bootstrapping configuration management tools or handling complex, stateful operations that Terraform can't manage directly. However, they should be considered a last resort due to their potential to make Terraform runs less predictable and harder to manage. Whenever possible, prefer using cloud-init scripts, custom images, or separate configuration management tools. When provisioners are necessary, design them to be idempotent and resilient to failures to maintain Terraform's desired state consistency. +Provisioners are appropriate when no provider resource or data source can accomplish the required task and the action must happen at resource creation or destruction time. Common use cases include running initialization scripts on a new server or notifying an external system after a resource is created. They should be avoided when alternatives exist because they add complexity and are harder to test. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/workspaces@JoUWF6AQoreELxFHNi9oo.md b/roadmaps/terraform/content/workspaces@JoUWF6AQoreELxFHNi9oo.md index 9f4f902ed..025ece55a 100644 --- a/roadmaps/terraform/content/workspaces@JoUWF6AQoreELxFHNi9oo.md +++ b/roadmaps/terraform/content/workspaces@JoUWF6AQoreELxFHNi9oo.md @@ -1,6 +1,6 @@ # Workspaces -HCP workspaces, particularly in the context of Terraform Cloud, provide isolated environments for managing different sets of infrastructure. Each workspace is associated with a specific Terraform configuration and maintains its own state file, variables, and access controls. Workspaces enable teams to organize and separate infrastructure based on projects, environments, or teams. They support collaborative workflows by allowing multiple team members to work on the same infrastructure while maintaining version control and change history. HCP workspaces offer features like remote state management, secure variable storage, and integration with version control systems. They also provide run triggers for automating workflows across dependent infrastructures. With built-in access controls, organizations can enforce least-privilege principles by granting specific permissions to users or teams for each workspace. +HCP Terraform workspaces are managed environments that store state, run history, and variable values for a specific configuration. Each workspace is linked to a version control repository or configured for CLI-driven runs. Variables and sensitive values are stored per workspace and injected into runs automatically. Visit the following resources to learn more: diff --git a/roadmaps/terraform/content/workspaces@nFq-64JQoYAKjN9YkmOfO.md b/roadmaps/terraform/content/workspaces@nFq-64JQoYAKjN9YkmOfO.md index e8bf0a011..dad044e86 100644 --- a/roadmaps/terraform/content/workspaces@nFq-64JQoYAKjN9YkmOfO.md +++ b/roadmaps/terraform/content/workspaces@nFq-64JQoYAKjN9YkmOfO.md @@ -1,6 +1,6 @@ # Workspaces -Terraform workspaces allow managing multiple distinct sets of infrastructure resources within a single configuration. They provide a way to create separate instances of state for the same configuration, enabling users to maintain different environments (like development, staging, and production) or experiment with changes without affecting the main infrastructure. Each workspace has its own state file, allowing for isolated management of resources. Workspaces are particularly useful for testing changes before applying them to production or for managing slight variations in configuration across different environments. They can be easily switched between using Terraform CLI commands. For more significant environment differences, separate configuration directories or state files might be more appropriate. +Workspaces allow multiple state files to exist for the same configuration, enabling the same code to manage separate environments such as development, staging, and production. The `terraform workspace` commands create, switch, and list workspaces. The current workspace name is available in expressions as `terraform.workspace`. Visit the following resources to learn more: