Add content and links to multiple TF topics (#6142)

* add content to modules, provisioners and workspaces

* fix style on module best practices

src/data/roadmaps/terraform/content/ci--cd-integration@O194eWh529jj4VDhKxNSj.md

@@ -1 +1,5 @@
-# CI / CD Integration
+# 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.

src/data/roadmaps/terraform/content/circle-ci@6OoAdvikyp0byMH2oZhyQ.md

@@ -1 +1,9 @@
-# Circle CI
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Deploy infrastructure with Terraform and CircleCI](https://developer.hashicorp.com/terraform/tutorials/automation/circle-ci)
+- [@opensource@CircleCI Terraform Orb](https://circleci.com/developer/orbs/orb/circleci/terraform)
+- [@article@How I deployed terraform resources with CircleCI](https://medium.com/nerd-for-tech/how-i-deployed-terraform-resources-with-circleci-628aa29ed514)

src/data/roadmaps/terraform/content/creating-local-modules@wQN1QrK9VB_fHlXrBzDoU.md

@@ -1 +1,9 @@
-# Creating Local Modules
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Build and use a local moduke](https://developer.hashicorp.com/terraform/tutorials/modules/module-create)
+- [@article@How to create reusable infrastructure with Terraform modules](https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d)
+- [@video@Creating a module in Terraform](https://www.youtube.com/watch?v=OeL2AlsdNaQ)

src/data/roadmaps/terraform/content/creation--destroy-time@CJfCpRN_oVf6n_EfLNJSV.md

@@ -1 +1,11 @@
-# Creation / Destroy Time
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Creation time provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax#creation-time-provisioners)
+- [@official@Destroy time provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax#destroy-time-provisioners)
+- [@article@How to: Terraform destroy time provisioners](https://support.hashicorp.com/hc/en-us/articles/11119084989587-How-to-Terraform-Destroy-time-Provisioners)

src/data/roadmaps/terraform/content/custom-provisioners@HEr-BBxE3jRKTqRnguds1.md

@@ -1 +1,10 @@
-# Custom Provisioners
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Terraform provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax)
+- [@article@Terraform provisioners - Why you should avoid them](https://spacelift.io/blog/terraform-provisioners)

src/data/roadmaps/terraform/content/data-sources@huXZz55P7kVJwTn5BS_Wk.md

@@ -1 +1,9 @@
-# Data Sources
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Terraform data sources](https://developer.hashicorp.com/terraform/language/data-sources)
+- [@article@Terraform Data Sources – How They Are Utilized](https://spacelift.io/blog/terraform-data-sources-how-they-are-utilised)
+- [@video@Data Sources in Terraform](https://www.youtube.com/watch?v=Y92Q5nW5-5g)

src/data/roadmaps/terraform/content/file-provisioner@Qch8k6e4pS8OlmG_sI0hH.md

@@ -1 +1,8 @@
-# file provisioner
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Terraform file provisioner](https://developer.hashicorp.com/terraform/language/resources/provisioners/file)
+- [@article@The file provisioner](https://learning-ocean.com/tutorials/terraform/terraform-file-provisioner/)

src/data/roadmaps/terraform/content/github-actions@weIlGqGN15U8BH1yE9moA.md

@@ -1 +1,9 @@
-# GitHub Actions
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Automate Terraform with GitHub Actions](https://developer.hashicorp.com/terraform/tutorials/automation/github-actions)
+- [@article@Terraform with GitHub Actions : How to Manage & Scale](https://spacelift.io/blog/github-actions-terraform)
+- [@opensource@setup-terraform](https://github.com/hashicorp/setup-terraform)

src/data/roadmaps/terraform/content/gitlab-ci@fH27mGrdnkDQCrGGDFU6p.md

@@ -1 +1,9 @@
-# GitLab CI
+# 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.
+
+Learn more from the following resources:
+
+- [@article@Infrastructure as Code with Terraform and GitLab](https://docs.gitlab.com/ee/user/infrastructure/iac/)
+- [@article@How to Implement GitLab CI/CD Pipeline with Terraform](https://spacelift.io/blog/gitlab-terraform)
+- [@video@Automate deploying to AWS using Terraform with GitLab CICD pipeline](https://www.youtube.com/watch?v=oqOzM_WBqZc)

src/data/roadmaps/terraform/content/inputs--outputs@NsBJTYH9KXvjJuhPzjE_L.md

@@ -1 +1,9 @@
-# Inputs / Outputs
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Accessing module output values](https://developer.hashicorp.com/terraform/language/modules/syntax#accessing-module-output-values)

src/data/roadmaps/terraform/content/jenkins@qFpaqOSoefTyKxmI-FRZt.md

@@ -1 +1,9 @@
-# Jenkins
+# 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.
+
+Learn more from the following resources:
+
+- [@article@Terraform with Jenkins – How to Manage Workflows](https://spacelift.io/blog/terraform-jenkins)
+- [£article@How to run Terraform in your Jenkins CI/CD pipeline.](https://blog.digger.dev/how-to-run-terraform-in-jenkins/)
+- [@video@How to Use Terraform and Jenkins to Automate Infrastructure Setup](https://www.youtube.com/watch?v=kIDiP3Unj7Y)

src/data/roadmaps/terraform/content/local-exec-provisioner@g2F5-nX4Aw-xWZiypNbnL.md

@@ -1 +1,9 @@
-# local-exec provisioner
+# 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.
+
+Learn more from the following resources:
+
+- [@official@local-exec Provisioner](https://developer.hashicorp.com/terraform/language/resources/provisioners/local-exec)
+- [@video@Terraform - Local exec](https://www.youtube.com/watch?v=2dVq8L2LBc0)
+- [@article@Local-Exec Provisioner](https://learning-ocean.com/tutorials/terraform/terraform-local-exec-provisioner/)

src/data/roadmaps/terraform/content/modules-best-practices@gTMPK0tfs2JYgoL7SAGW6.md

@@ -1 +1,20 @@
-# Modules Best Practices
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Module best practices](https://developer.hashicorp.com/terraform/tutorials/modules/module#module-best-practices)
+- [@article@Terraform Modules Guide: Best Practices & Examples](https://www.env0.com/blog/terraform-modules)
+- [@video@Best practices for modularizing a Terraform project | PlatformCon 2023](https://www.youtube.com/watch?v=byzwaTng3ac)

src/data/roadmaps/terraform/content/modules@R2AORYmc1NgGTqLZY5Fu-.md

@@ -1 +1,3 @@
-# Modules
+# 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.

src/data/roadmaps/terraform/content/provisioners@6vs1VvjeILgAPLL6g7dfy.md

@@ -1 +1,3 @@
-# Provisioners
+# 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.

src/data/roadmaps/terraform/content/published-modules-usage@AAg_iFggkEZNL12-6nkgK.md

@@ -1 +1,9 @@
-# Published Modules Usage
+# 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.
+
+Learn more from the following resources:
+
+- [@opensource@Terraform Registry - Modules](https://registry.terraform.io/browse/modules)
+- [@official@Publishing Modules](https://developer.hashicorp.com/terraform/registry/modules/publish)
+- [@video@Terraform - Publish modules](https://www.youtube.com/watch?v=9vBp1D3myH8)

src/data/roadmaps/terraform/content/remote-exec-provisioner@JQE3_KakBXZdMVP_pPFNS.md

@@ -1 +1,9 @@
-# remote-exec provisioner
+# 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.
+
+Learn more from the following resources:
+
+- [@official@Remote-exec provisioner](https://developer.hashicorp.com/terraform/language/resources/provisioners/remote-exec)
+- [@article@Terraform remote-exec provisioner](https://learning-ocean.com/tutorials/terraform/terraform-remote-exec-provisioner/)
+- [@video@Terraform - remote-exec](https://www.youtube.com/watch?v=kjDXbGeLvRw)

src/data/roadmaps/terraform/content/root-vs-child-modules@6W4_akHG9YtvN6dpbZnG-.md

@@ -1 +1,9 @@
-# Root vs Child Modules
+# 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.
+
+Learn more from the following resources:
+
+- [@official@The root module](https://developer.hashicorp.com/terraform/language/modules#the-root-module)
+- [@official@Child modules](https://developer.hashicorp.com/terraform/language/modules#child-modules)
+- [@article@What is the difference between Terraform "Module" and "Child Module"](https://stackoverflow.com/questions/77671412/what-is-the-difference-between-terraform-module-and-child-module)

src/data/roadmaps/terraform/content/template-files@tB4zfwY4E3GmXo-XQwS-l.md

@@ -1 +1,9 @@
-# Template Files
+# 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.
+
+Learn more from the following resources:
+
+- [@official@templatefile function](https://developer.hashicorp.com/terraform/language/functions/templatefile)
+- [@article@What are Terraform templates?](https://spacelift.io/blog/terraform-templates)
+- [@video@Using templatefile in Terraform](https://www.youtube.com/watch?v=cRYYFCekOIk)

src/data/roadmaps/terraform/content/when-to-use@CmmoshFC1dKE4y3SMN2bl.md

@@ -1 +1,8 @@
-# When to Use?
+# 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.
+
+Learn more from the following resources:
+
+- [@article@My thoughts on why you should use Terraform Provisioners as a final option](https://thomasthornton.cloud/2023/05/11/my-thoughts-on-why-you-should-use-terraform-provisioners-as-a-final-option/)
+- [@article@Why Terraform Provisioners Are The Last Resort?](https://k21academy.com/terraform-iac/terraform-provisioners/)

src/data/roadmaps/terraform/content/workspaces@nFq-64JQoYAKjN9YkmOfO.md

@@ -1 +1,9 @@
-# Workspaces
+# 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.
+
+Learn more with the following resources:
+
+- [@official@Workspaces](https://developer.hashicorp.com/terraform/language/state/workspaces)
+- [@article@What are Terraform workspaces?](https://spacelift.io/blog/terraform-workspaces)
+- [@video@Structuring Repositories for Terraform Workspaces - Hashicorp](https://www.youtube.com/watch?v=IDLGpkRmDXg)