diff --git a/cli/app.go b/cli/app.go index 71c158a6b..10f2e77bb 100644 --- a/cli/app.go +++ b/cli/app.go @@ -70,7 +70,7 @@ func NewApp(writer io.Writer, errWriter io.Writer) *App { app := cli.NewApp() app.Name = "terragrunt" - app.Usage = "Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple\nTerraform modules, remote state, and locking. For documentation, see https://github.com/gruntwork-io/terragrunt/." + app.Usage = "Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale. For documentation, see https://terragrunt.gruntwork.io/." app.Author = "Gruntwork " app.Version = version.GetVersion() app.Writer = writer diff --git a/docs/Dockerfile b/docs/Dockerfile index 270355c1a..be302fc5d 100644 --- a/docs/Dockerfile +++ b/docs/Dockerfile @@ -1,9 +1,6 @@ -FROM ruby:2.6.2-stretch +FROM ruby:3.3-bookworm MAINTAINER Gruntwork -# This project requires bundler 2, but the docker image comes with bundler 1 so we need to upgrade -RUN gem install bundler - # Copy the Gemfile and Gemfile.lock into the image and run bundle install in a way that will be cached WORKDIR /tmp ADD Gemfile Gemfile diff --git a/docs/Gemfile b/docs/Gemfile index e6527148e..83d90ddd9 100644 --- a/docs/Gemfile +++ b/docs/Gemfile @@ -16,8 +16,6 @@ gem "github-pages", group: :jekyll_plugins # If you have any plugins, put them here! group :jekyll_plugins do gem 'jekyll-sitemap', '1.4.0' - gem 'therubyracer', '0.12.3' - gem 'less', '2.6.0' gem 'jekyll-toc' gem 'jekyll-redirect-from' end @@ -26,4 +24,6 @@ end gem "wdm", "~> 0.1.1", :install_if => Gem.win_platform? gem "nokogiri", "1.16.3", group: :jekyll_plugins -gem "mini_portile2", "2.8.5", group: :jekyll_plugins \ No newline at end of file +gem "mini_portile2", "2.8.5", group: :jekyll_plugins + +gem "webrick", "~> 1.8" diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 00522a355..49e0749d7 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -20,7 +20,6 @@ GEM execjs coffee-script-source (1.12.2) colorator (1.1.0) - commonjs (0.2.7) commonmarker (0.23.10) concurrent-ruby (1.3.3) connection_pool (2.4.1) @@ -214,9 +213,6 @@ GEM rexml kramdown-parser-gfm (1.1.0) kramdown (~> 2.0) - less (2.6.0) - commonjs (~> 0.2.7) - libv8 (3.16.14.19.1) liquid (4.0.4) listen (3.9.0) rb-fsevent (~> 0.10, >= 0.10.3) @@ -245,7 +241,6 @@ GEM rb-fsevent (0.11.2) rb-inotify (0.11.1) ffi (~> 1.0) - ref (2.0.0) rexml (3.3.1) strscan rouge (3.30.0) @@ -263,9 +258,6 @@ GEM strscan (3.1.0) terminal-table (1.8.0) unicode-display_width (~> 1.1, >= 1.1.1) - therubyracer (0.12.3) - libv8 (~> 3.16.14.15) - ref typhoeus (1.4.1) ethon (>= 0.9.0) tzinfo (2.0.6) @@ -273,6 +265,7 @@ GEM unicode-display_width (1.8.0) uri (0.13.0) wdm (0.1.1) + webrick (1.8.1) PLATFORMS ruby @@ -282,11 +275,10 @@ DEPENDENCIES jekyll-redirect-from jekyll-sitemap (= 1.4.0) jekyll-toc - less (= 2.6.0) mini_portile2 (= 2.8.5) nokogiri (= 1.16.3) - therubyracer (= 0.12.3) wdm (~> 0.1.1) + webrick (~> 1.8) BUNDLED WITH 2.4.22 diff --git a/docs/README.md b/docs/README.md index 601a5ff29..15f2961b4 100644 --- a/docs/README.md +++ b/docs/README.md @@ -183,7 +183,7 @@ title: CLI options # CHANGE THIS categories: - getting-started # CHANGE THIS excerpt: >- # CHANGE THIS - Terragrunt forwards all arguments and options to Terraform. Learn more about CLI options in Terragrunt. + Terragrunt forwards all arguments and options to OpenTofu/Terraform. Learn more about CLI options in Terragrunt. tags: ["CLI"] # CHANGE THIS order: 102 # CHANGE THIS nav_title: Documentation # OPTIONAL @@ -223,8 +223,8 @@ To add a new collection based on _Collection browser_, like _Documentation_ coll --- layout: collection-browser # DO NOT CHANGE THIS title: Use cases - subtitle: Learn how to integrate Terragrunt with Terraform. - excerpt: Learn how to integrate Terragrunt with Terraform. + subtitle: Learn how to integrate Terragrunt with OpenTofu/Terraform. + excerpt: Learn how to integrate Terragrunt with OpenTofu/Terraform. permalink: /use-cases/ slug: use-cases nav_title: Documentation # OPTIONAL @@ -270,7 +270,7 @@ The Collection Browser's purpose is to wrap Jekyll collection into: categories: # <-- [CHANGE THIS] use single category. (Downcase and dashes instead of spaces) - getting-started excerpt: >- # <-- [CHANGE THIS] doc's description - Terragrunt forwards all arguments and options to Terraform. Learn more about CLI options in Terragrunt. + Terragrunt forwards all arguments and options to OpenTofu/Terraform. Learn more about CLI options in Terragrunt. tags: ["CLI", "Another tag"] # <-- [CHANGE THIS] doc's tags order: 102 # <-- [CHANGE THIS] set different number to each doc to set right order --- @@ -283,8 +283,8 @@ The Collection Browser's purpose is to wrap Jekyll collection into: --- layout: collection-browser # <-- It has to be "collection-browser" title: Use cases -subtitle: Learn how to integrate Terragrunt with Terraform. -excerpt: Learn how to integrate Terragrunt with Terraform. +subtitle: Learn how to integrate Terragrunt with OpenTofu/Terraform. +excerpt: Learn how to integrate Terragrunt with OpenTofu/Terraform. permalink: /use-cases/ slug: use-cases --- diff --git a/docs/_config.yml b/docs/_config.yml index 7da2c361d..191b598e1 100644 --- a/docs/_config.yml +++ b/docs/_config.yml @@ -21,11 +21,9 @@ title: Terragrunt url: "https://terragrunt.gruntwork.io" email: info@gruntwork.io -name: "Terragrunt | Terraform wrapper" +name: "Terragrunt | OpenTofu/Terraform wrapper" description: >- # this means to ignore newlines until "baseurl:" - Terragrunt is a thin wrapper for Terraform that provides extra tools for - keeping your Terraform configurations DRY, working with multiple Terraform - modules, and managing remote state. + Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale. baseurl: "" # the subpath of your site, e.g. /blog full_company_name: "Gruntwork, Inc" thumbnail_path: "/assets/img/terragrunt-thumbnail.png" diff --git a/docs/_docs/01_getting-started/configuration.md b/docs/_docs/01_getting-started/configuration.md index 1d699b071..cedb793a0 100644 --- a/docs/_docs/01_getting-started/configuration.md +++ b/docs/_docs/01_getting-started/configuration.md @@ -12,7 +12,7 @@ nav_title_link: /docs/ ## Terragrunt configuration file -Terragrunt configuration is defined in a `terragrunt.hcl` file. This uses the same HCL syntax as Terraform itself. +Terragrunt configuration is defined in a `terragrunt.hcl` file. This uses the same HCL syntax as OpenTofu/Terraform itself. Here’s an example: @@ -87,7 +87,7 @@ This allows Terragrunt to avoid resolving `dependency` on modules that haven’t ## Formatting hcl files -You can rewrite the hcl files to a canonical format using the `hclfmt` command built into `terragrunt`. Similar to `terraform fmt`, this command applies a subset of [the Terraform language style conventions](https://www.terraform.io/docs/configuration/style.html), along with other minor adjustments for readability. +You can rewrite the hcl files to a canonical format using the `hclfmt` command built into `terragrunt`. Similar to `terraform fmt`, this command applies a subset of [the OpenTofu/Terraform language style conventions](https://www.terraform.io/docs/configuration/style.html), along with other minor adjustments for readability. This command will recursively search for hcl files and format all of them under a given directory tree. Consider the following file structure: diff --git a/docs/_docs/01_getting-started/quick-start.md b/docs/_docs/01_getting-started/quick-start.md index d2aa717b0..517750d37 100644 --- a/docs/_docs/01_getting-started/quick-start.md +++ b/docs/_docs/01_getting-started/quick-start.md @@ -120,13 +120,13 @@ Terragrunt can help you accomplish the following: - [Key features](#key-features) - [Keep your backend configuration DRY](#keep-your-backend-configuration-dry) - [Keep your provider configuration DRY](#keep-your-provider-configuration-dry) - - [Keep your Terraform CLI arguments DRY](#keep-your-terraform-cli-arguments-dry) + - [Keep your OpenTofu/Terraform CLI arguments DRY](#keep-your-opentofuterraform-cli-arguments-dry) - [Promote immutable, versioned OpenTofu/Terraform modules across environments](#promote-immutable-versioned-opentofuterraform-modules-across-environments) - [Next steps](#next-steps) ### Keep your backend configuration DRY -_Terraform_ backends allow you to store OpenTofu/Terraform state in a shared location that everyone on your team can access, such as an S3 bucket, and provide locking around your state files to protect against race conditions. To use an OpenTofu/Terraform backend, you add a `backend` configuration to your configurations: +_OpenTofu/Terraform_ backends allow you to store OpenTofu/Terraform state in a shared location that everyone on your team can access, such as an S3 bucket, and provide locking around your state files to protect against race conditions. To use an OpenTofu/Terraform backend, you add a `backend` configuration to your configurations: ``` hcl # stage/frontend-app/main.tf @@ -320,9 +320,9 @@ $ find . -name "provider.tf" .terragrunt-cache/some-unique-hash/provider.tf ``` -### Keep your Terraform CLI arguments DRY +### Keep your OpenTofu/Terraform CLI arguments DRY -CLI flags are another common source of copy/paste in the Terraform world. For example, a typical pattern with Terraform is to define common account-level variables in an `account.tfvars` file: +CLI flags are another common source of copy/paste in the OpenTofu/Terraform world. For example, a typical pattern with OpenTofu/Terraform is to define common account-level variables in an `account.tfvars` file: ``` hcl # account.tfvars @@ -426,7 +426,7 @@ Therefore, you typically want to break up your infrastructure across multiple mo └── outputs.tf ``` -The folder structure above shows how to separate the code for each environment (`prod`, `qa`, `stage`) and for each type of infrastructure (apps, databases, VPCs). However, the downside is that it isn’t DRY. The `.tf` files will contain a LOT of duplication. You can reduce it somewhat by defining all the infrastructure in [reusable Terraform modules](https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d), but even the code to instantiate a module—including configuring the `provider`, `backend`, the module’s input variables, and `output` variables—means you still end up with dozens or hundreds of lines of copy/paste for every module in every environment: +The folder structure above shows how to separate the code for each environment (`prod`, `qa`, `stage`) and for each type of infrastructure (apps, databases, VPCs). However, the downside is that it isn’t DRY. The `.tf` files will contain a LOT of duplication. You can reduce it somewhat by defining all the infrastructure in [reusable OpenTofu/Terraform modules](https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d), but even the code to instantiate a module—including configuring the `provider`, `backend`, the module’s input variables, and `output` variables—means you still end up with dozens or hundreds of lines of copy/paste for every module in every environment: ``` hcl # prod/app/main.tf diff --git a/docs/_docs/02_features/auto-retry.md b/docs/_docs/02_features/auto-retry.md index 585c7e3c1..48b85e67c 100644 --- a/docs/_docs/02_features/auto-retry.md +++ b/docs/_docs/02_features/auto-retry.md @@ -3,7 +3,7 @@ layout: collection-browser-doc title: Auto-retry category: features categories_url: features -excerpt: Auto-Retry is a feature of terragrunt that will automatically address situations where a terraform command needs to be re-run. +excerpt: Auto-Retry is a feature of terragrunt that will automatically address situations where an OpenTofu/Terraform command needs to be re-run. tags: ["CLI"] order: 250 nav_title: Documentation @@ -12,9 +12,9 @@ nav_title_link: /docs/ ## Auto-Retry -*Auto-Retry* is a feature of `terragrunt` that will automatically address situations where a `terraform` command needs to be re-run. +*Auto-Retry* is a feature of `terragrunt` that will automatically address situations where a `tofu`/`terraform` command needs to be re-run. -Terraform can fail with transient errors which can be addressed by simply retrying the command again. In the event `terragrunt` finds one of these errors, the command will be re-run again automatically. +OpenTofu/Terraform can fail with transient errors which can be addressed by simply retrying the command again. In the event `terragrunt` finds one of these errors, the command will be re-run again automatically. ### Example @@ -46,7 +46,7 @@ retryable_errors = [ ] ``` -By default, `auto-retry` tries a maximum of three times to re-run a command, pausing for five seconds between each retry, at which point it will deem the error as not transient, and accept the `terraform` failure. +By default, `auto-retry` tries a maximum of three times to re-run a command, pausing for five seconds between each retry, at which point it will deem the error as not transient, and accept the `tofu`/`terraform` failure. However, you can override these defaults. For example, the following retries up to five times, with 60 seconds in between each retry: ```hcl diff --git a/docs/_docs/02_features/caching.md b/docs/_docs/02_features/caching.md index 671e4cc7f..c90c42641 100644 --- a/docs/_docs/02_features/caching.md +++ b/docs/_docs/02_features/caching.md @@ -12,7 +12,7 @@ nav_title_link: /docs/ ## Clearing the Terragrunt cache -Terragrunt creates a `.terragrunt-cache` folder in the current working directory as its scratch directory. It downloads your remote Terraform configurations into this folder, runs your Terraform commands in this folder, and any modules and providers those commands download also get stored in this folder. You can safely delete this folder any time and Terragrunt will recreate it as necessary. +Terragrunt creates a `.terragrunt-cache` folder in the current working directory as its scratch directory. It downloads your remote OpenTofu/Terraform configurations into this folder, runs your OpenTofu/Terraform commands in this folder, and any modules and providers those commands download also get stored in this folder. You can safely delete this folder any time and Terragrunt will recreate it as necessary. If you need to clean up a lot of these folders (e.g., after `terragrunt run-all apply`), you can use the following commands on Mac and Linux: diff --git a/docs/_docs/02_features/catalog.md b/docs/_docs/02_features/catalog.md index 2960a56a0..0073836f5 100644 --- a/docs/_docs/02_features/catalog.md +++ b/docs/_docs/02_features/catalog.md @@ -40,7 +40,7 @@ catalog { } ``` -This will recursively search for Terraform modules in the root of the repo and the `modules` directory and show a table with all the modules. You can then: +This will recursively search for OpenTofu/Terraform modules in the root of the repo and the `modules` directory and show a table with all the modules. You can then: 1. Search and filter the table: `/` and start typing. 1. Select a module in the table: use the arrow keys to go up and down and next/previous page. diff --git a/docs/_docs/02_features/debugging.md b/docs/_docs/02_features/debugging.md index 1ea51bade..ff556c3af 100644 --- a/docs/_docs/02_features/debugging.md +++ b/docs/_docs/02_features/debugging.md @@ -3,7 +3,7 @@ layout: collection-browser-doc title: Debugging category: features categories_url: features -excerpt: Learn how to debug issues with terragrunt and terraform. +excerpt: Learn how to debug issues with terragrunt and tofu/terraform. tags: ["DRY", "Use cases", "CLI"] order: 265 nav_title: Documentation @@ -12,7 +12,7 @@ nav_title_link: /docs/ ## Debugging -Terragrunt and Terraform usually play well together in helping you +Terragrunt and OpenTofu/Terraform usually play well together in helping you write DRY, re-usable infrastructure. But how do we figure out what went wrong in the rare case that they _don't_ play well? @@ -31,8 +31,8 @@ Running this command will do two things for you: - Output a file named `terragrunt-debug.tfvars.json` to your terragrunt working directory (the same one containing your `terragrunt.hcl`) -- Print instructions on how to invoke terraform against the generated file to - reproduce exactly the same terraform output as you saw when invoking +- Print instructions on how to invoke tofu/terraform against the generated file to + reproduce exactly the same tofu/terraform output as you saw when invoking `terragrunt`. This will help you to determine where the problem's root cause lies. @@ -41,11 +41,11 @@ root cause of your problem: 1. Misconfiguration of your infrastructure code. 2. An error in `terragrunt`. -3. An error in `terraform`. +3. An error in `tofu/terraform`. Let's run through a few use-cases. -### Use-case: I use locals or dependencies in terragrunt.hcl, and the terraform output isn't what I expected +### Use-case: I use locals or dependencies in terragrunt.hcl, and the tofu/terraform output isn't what I expected Consider this file structure for a fictional production environment where we have configured an application to deploy as many tasks as there are minimum @@ -107,9 +107,9 @@ terragrunt apply --terragrunt-log-level debug --terragrunt-debug After applying, you will see this output on standard error ```log -[terragrunt] Variables passed to terraform are located in "~/live/prod/app/terragrunt-debug.tfvars" -[terragrunt] Run this command to replicate how terraform was invoked: -[terragrunt] terraform apply -var-file="~/live/prod/app/terragrunt-debug.tfvars.json" "~/live/prod/app" +[terragrunt] Variables passed to tofu/terraform are located in "~/live/prod/app/terragrunt-debug.tfvars" +[terragrunt] Run this command to replicate how tofu/terraform was invoked: +[terragrunt] tofu/terraform apply -var-file="~/live/prod/app/terragrunt-debug.tfvars.json" "~/live/prod/app" ``` Well we may have to do all that, but first let's just take a look at `terragrunt-debug.tfvars.json` @@ -228,8 +228,8 @@ export TERRAGRUNT_TELEMETRY_TRACE_EXPORTER=console ```json {"Name":"run_bash","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"f91587247524593b","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:30.564217484Z","EndTime":"2024-02-08T12:32:31.570666395Z","Attributes":[{"Key":"command","Value":{"Type":"STRING","Value":"bash"}},{"Key":"args","Value":{"Type":"STRING","Value":"[-c sleep 1]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} {"Name":"parse_config_file","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"d2823047fb469bdf","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:30.380054129Z","EndTime":"2024-02-08T12:32:31.570899286Z","Attributes":[{"Key":"config_path","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2/terragrunt.hcl"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} -{"Name":"run_terraform","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"152d873a18559f07","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:31.57161757Z","EndTime":"2024-02-08T12:32:31.688157882Z","Attributes":[{"Key":"command","Value":{"Type":"STRING","Value":"terraform"}},{"Key":"args","Value":{"Type":"STRING","Value":"[init]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} -{"Name":"run_terraform","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"29341bdb65f66b1e","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:31.688240673Z","EndTime":"2024-02-08T12:32:31.793377642Z","Attributes":[{"Key":"command","Value":{"Type":"STRING","Value":"terraform"}},{"Key":"args","Value":{"Type":"STRING","Value":"[apply -auto-approve -input=false]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} +{"Name":"run_terraform","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"152d873a18559f07","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:31.57161757Z","EndTime":"2024-02-08T12:32:31.688157882Z","Attributes":[{"Key":"command","Value":{"Type":"STRING","Value":"tofu"}},{"Key":"args","Value":{"Type":"STRING","Value":"[init]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} +{"Name":"run_terraform","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"29341bdb65f66b1e","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:31.688240673Z","EndTime":"2024-02-08T12:32:31.793377642Z","Attributes":[{"Key":"command","Value":{"Type":"STRING","Value":"tofu"}},{"Key":"args","Value":{"Type":"STRING","Value":"[apply -auto-approve -input=false]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} {"Name":"run_module","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"8a01522bc65e0f1b","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:30.290680776Z","EndTime":"2024-02-08T12:32:31.793392803Z","Attributes":[{"Key":"path","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test/mod2"}},{"Key":"terraformCommand","Value":{"Type":"STRING","Value":"apply"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":0,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} {"Name":"run-all apply","SpanContext":{"TraceID":"bdf3cb9078706b7f0b4f1d92428eedc0","SpanID":"b0b007770f852066","TraceFlags":"01","TraceState":"","Remote":false},"Parent":{"TraceID":"00000000000000000000000000000000","SpanID":"0000000000000000","TraceFlags":"00","TraceState":"","Remote":false},"SpanKind":1,"StartTime":"2024-02-08T12:32:26.388519019Z","EndTime":"2024-02-08T12:32:31.793405603Z","Attributes":[{"Key":"terraformCommand","Value":{"Type":"STRING","Value":"apply"}},{"Key":"args","Value":{"Type":"STRING","Value":"[apply]"}},{"Key":"dir","Value":{"Type":"STRING","Value":"/projects/gruntwork/terragrunt-tests/trace-test"}}],"Events":null,"Links":null,"Status":{"Code":"Unset","Description":""},"DroppedAttributes":0,"DroppedEvents":0,"DroppedLinks":0,"ChildSpanCount":28,"Resource":[{"Key":"service.name","Value":{"Type":"STRING","Value":"terragrunt"}},{"Key":"service.version","Value":{"Type":"STRING","Value":"v0.55.0-29-g66bfa07b756e-dirty"}},{"Key":"telemetry.sdk.language","Value":{"Type":"STRING","Value":"go"}},{"Key":"telemetry.sdk.name","Value":{"Type":"STRING","Value":"opentelemetry"}},{"Key":"telemetry.sdk.version","Value":{"Type":"STRING","Value":"1.23.0"}}],"InstrumentationLibrary":{"Name":"terragrunt","Version":"","SchemaURL":""}} ``` diff --git a/docs/_docs/02_features/execute-terraform-commands-on-multiple-modules-at-once.md b/docs/_docs/02_features/execute-terraform-commands-on-multiple-modules-at-once.md index d1583db87..b9f58ce6f 100644 --- a/docs/_docs/02_features/execute-terraform-commands-on-multiple-modules-at-once.md +++ b/docs/_docs/02_features/execute-terraform-commands-on-multiple-modules-at-once.md @@ -1,6 +1,6 @@ --- layout: collection-browser-doc -title: Execute Terraform commands on multiple modules at once +title: Execute OpenTofu/Terraform commands on multiple modules at once category: features categories_url: features excerpt: Learn how to avoid tedious tasks of running commands on each module separately. @@ -10,9 +10,9 @@ nav_title: Documentation nav_title_link: /docs/ --- -## Execute Terraform commands on multiple modules at once +## Execute OpenTofu/Terraform commands on multiple modules at once -- [Execute Terraform commands on multiple modules at once](#execute-terraform-commands-on-multiple-modules-at-once) +- [Execute OpenTofu/Terraform commands on multiple modules at once](#execute-opentofuterraform-commands-on-multiple-modules-at-once) - [Motivation](#motivation) - [The run-all command](#the-run-all-command) - [Passing outputs between modules](#passing-outputs-between-modules) @@ -20,11 +20,11 @@ nav_title_link: /docs/ - [Dependencies between modules](#dependencies-between-modules) - [Testing multiple modules locally](#testing-multiple-modules-locally) - [Limiting the module execution parallelism](#limiting-the-module-execution-parallelism) - - [Saving terraform plan output](#saving-terraform-plan-output) + - [Saving OpenTofu/Terraform plan output](#saving-opentofuterraform-plan-output) ### Motivation -Let’s say your infrastructure is defined across multiple Terraform modules: +Let’s say your infrastructure is defined across multiple OpenTofu/Terraform modules: ```tree root @@ -40,11 +40,11 @@ root └── main.tf ``` -There is one module to deploy a frontend-app, another to deploy a backend-app, another for the MySQL database, and so on. To deploy such an environment, you’d have to manually run `terraform apply` in each of the subfolder, wait for it to complete, and then run `terraform apply` in the next subfolder. How do you avoid this tedious and time-consuming process? +There is one module to deploy a frontend-app, another to deploy a backend-app, another for the MySQL database, and so on. To deploy such an environment, you’d have to manually run `tofu apply`/`terraform apply` in each of the subfolder, wait for it to complete, and then run `tofu apply`/`terraform apply` in the next subfolder. How do you avoid this tedious and time-consuming process? ### The run-all command -To be able to deploy multiple Terraform modules in a single command, add a `terragrunt.hcl` file to each module: +To be able to deploy multiple OpenTofu/Terraform modules in a single command, add a `terragrunt.hcl` file to each module: ```tree root @@ -75,7 +75,7 @@ terragrunt run-all apply When you run this command, Terragrunt will recursively look through all the subfolders of the current working directory, find all folders with a `terragrunt.hcl` file, and run `terragrunt apply` in each of those folders concurrently. -Similarly, to undeploy all the Terraform modules, you can use the `run-all` command with `destroy`: +Similarly, to undeploy all the OpenTofu/Terraform modules, you can use the `run-all` command with `destroy`: ```bash cd root @@ -141,7 +141,7 @@ inputs = { } ``` -When you apply this module, the output will be read from the `vpc` module and passed in as an input to the `mysql` module right before calling `terraform apply`. +When you apply this module, the output will be read from the `vpc` module and passed in as an input to the `mysql` module right before calling `tofu apply`/`terraform apply`. You can also specify multiple `dependency` blocks to access multiple different module output variables. For example, in the above folder structure, you might want to reference the `domain` output of the `redis` and `mysql` modules for use as `inputs` in the `backend-app` module. To access those outputs, you would specify in `backend-app/terragrunt.hcl`: @@ -174,7 +174,7 @@ If any of the modules failed to deploy, then Terragrunt will not attempt to depl #### Unapplied dependency and mock outputs -Terragrunt will return an error indicating the dependency hasn’t been applied yet if the terraform module managed by the terragrunt config referenced in a `dependency` block has not been applied yet. This is because you cannot actually fetch outputs out of an unapplied Terraform module, even if there are no resources being created in the module. +Terragrunt will return an error indicating the dependency hasn’t been applied yet if the terraform module managed by the terragrunt config referenced in a `dependency` block has not been applied yet. This is because you cannot actually fetch outputs out of an unapplied OpenTofu/Terraform module, even if there are no resources being created in the module. This is most problematic when running commands that do not modify state (e.g `run-all plan` and `run-all validate`) on a completely new setup where no infrastructure has been deployed. You won’t be able to `plan` or `validate` a module if you can’t determine the `inputs`. If the module depends on the outputs of another module that hasn’t been applied yet, you won’t be able to compute the `inputs` unless the dependencies are all applied. However, in real life usage, you would want to run `run-all validate` or `run-all plan` on a completely new set of infrastructure. @@ -200,7 +200,7 @@ You can now run `validate` on this config before the `vpc` module is applied bec What if you wanted to restrict this behavior to only the `validate` command? For example, you might not want to use the defaults for a `plan` operation because the plan doesn’t give you any indication of what is actually going to be created. -You can use the `mock_outputs_allowed_terraform_commands` attribute to indicate that the `mock_outputs` should only be used when running those Terraform commands. So to restrict the `mock_outputs` to only when `validate` is being run, you can modify the above `terragrunt.hcl` file to: +You can use the `mock_outputs_allowed_terraform_commands` attribute to indicate that the `mock_outputs` should only be used when running those OpenTofu/Terraform commands. So to restrict the `mock_outputs` to only when `validate` is being run, you can modify the above `terragrunt.hcl` file to: ```hcl dependency "vpc" { @@ -280,7 +280,7 @@ root └── terragrunt.hcl ``` -Let’s assume you have the following dependencies between Terraform modules: +Let’s assume you have the following dependencies between OpenTofu/Terraform modules: - `backend-app` depends on `mysql`, `redis`, and `vpc` @@ -340,14 +340,14 @@ in reverse order (bottom up) ### Testing multiple modules locally -If you are using Terragrunt to configure [remote Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations) and all of your modules have the `source` parameter set to a Git URL, but you want to test with a local checkout of the code, you can use the `--terragrunt-source` parameter: +If you are using Terragrunt to configure [remote OpenTofu/Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations) and all of your modules have the `source` parameter set to a Git URL, but you want to test with a local checkout of the code, you can use the `--terragrunt-source` parameter: ```bash cd root terragrunt run-all plan --terragrunt-source /source/modules ``` -If you set the `--terragrunt-source` parameter, the `run-all` commands will assume that parameter is pointing to a folder on your local file system that has a local checkout of all of your Terraform modules. For each module that is being processed via a `run-all` command, Terragrunt will read in the `source` parameter in that module’s `terragrunt.hcl` file, parse out the path (the portion after the double-slash), and append the path to the `--terragrunt-source` parameter to create the final local path for that module. +If you set the `--terragrunt-source` parameter, the `run-all` commands will assume that parameter is pointing to a folder on your local file system that has a local checkout of all of your OpenTofu/Terraform modules. For each module that is being processed via a `run-all` command, Terragrunt will read in the `source` parameter in that module’s `terragrunt.hcl` file, parse out the path (the portion after the double-slash), and append the path to the `--terragrunt-source` parameter to create the final local path for that module. For example, consider the following `terragrunt.hcl` file: @@ -362,7 +362,7 @@ If you run `terragrunt run-all apply --terragrunt-source /source/infrastructure- ### Limiting the module execution parallelism By default Terragrunt will not impose a limit on the number of modules it executes when it traverses the dependency graph, -meaning that if it finds 5 modules it'll run terraform 5 times in parallel once in each module. Sometimes +meaning that if it finds 5 modules it'll run OpenTofu/Terraform 5 times in parallel once in each module. Sometimes this might create a problem if there are a lot of modules in the dependency graph like hitting a rate limit on some cloud provider. @@ -372,7 +372,7 @@ To limit the maximum number of module executions at any given time use the `--te terragrunt run-all apply --terragrunt-parallelism 4 ``` -### Saving terraform plan output +### Saving OpenTofu/Terraform plan output Terragrunt enables you to save the execution plan to a designated directory in binary or JSON format, which is helpful for reviewing and reusing the plan at a later time. To save the plan, use the `--terragrunt-out-dir` flag (or `TERRAGRUNT_OUT_DIR` environment variable) as demonstrated below: diff --git a/docs/_docs/02_features/hooks.md b/docs/_docs/02_features/hooks.md index 62b8348b3..188b6459b 100644 --- a/docs/_docs/02_features/hooks.md +++ b/docs/_docs/02_features/hooks.md @@ -3,7 +3,7 @@ layout: collection-browser-doc title: Before, After, and Error Hooks category: features categories_url: features -excerpt: Learn how to execute custom code before or after running Terraform, or when errors occur. +excerpt: Learn how to execute custom code before or after running OpenTofu/Terraform, or when errors occur. tags: ["hooks"] order: 240 nav_title: Documentation @@ -12,7 +12,7 @@ nav_title_link: /docs/ ## Before and After Hooks -_Before Hooks_ or _After Hooks_ are a feature of terragrunt that make it possible to define custom actions that will be called either before or after execution of the `terraform` command. +_Before Hooks_ or _After Hooks_ are a feature of terragrunt that make it possible to define custom actions that will be called either before or after execution of the `tofu`/`terraform` command. Here’s an example: @@ -20,21 +20,21 @@ Here’s an example: terraform { before_hook "before_hook" { commands = ["apply", "plan"] - execute = ["echo", "Running Terraform"] + execute = ["echo", "Running OpenTofu"] } after_hook "after_hook" { commands = ["apply", "plan"] - execute = ["echo", "Finished running Terraform"] + execute = ["echo", "Finished running OpenTofu"] run_on_error = true } } ``` -In this example configuration, whenever Terragrunt runs `terraform apply` or `terraform plan`, two things will happen: +In this example configuration, whenever Terragrunt runs `tofu apply` or `tofu plan` (or the `terraform` equivalent), two things will happen: -- Before Terragrunt runs `terraform`, it will output `Running Terraform` to the console. -- After Terragrunt runs `terraform`, it will output `Finished running Terraform`, regardless of whether or not the +- Before Terragrunt runs `tofu`/`terraform`, it will output `Running OpenTofu` to the console. +- After Terragrunt runs `tofu`/`terraform`, it will output `Finished running OpenTofu`, regardless of whether or not the command failed. Any type of hook adds extra environment variables to the hook's run command: @@ -61,7 +61,7 @@ terraform { echo "COMMAND=${TG_CTX_COMMAND} HOOK_NAME=${TG_CTX_HOOK_NAME}" ``` -In this example, whenever Terragrunt runs `terraform apply`, the `hook.sh` script will print "COMMAND=apply HOOK_NAME=test_hook" +In this example, whenever Terragrunt runs `tofu apply`/`terraform apply`, the `hook.sh` script will print "COMMAND=apply HOOK_NAME=test_hook" You can have multiple before and after hooks. Each hook will execute in the order they are defined. For example: @@ -69,26 +69,26 @@ You can have multiple before and after hooks. Each hook will execute in the orde terraform { before_hook "before_hook_1" { commands = ["apply", "plan"] - execute = ["echo", "Will run Terraform"] + execute = ["echo", "Will run OpenTofu"] } before_hook "before_hook_2" { commands = ["apply", "plan"] - execute = ["echo", "Running Terraform"] + execute = ["echo", "Running OpenTofu"] } } ``` -This configuration will cause Terragrunt to output `Will run Terraform` and then `Running Terraform` before the call -to Terraform. +This configuration will cause Terragrunt to output `Will run OpenTofu` and then `Running OpenTofu` before the call +to OpenTofu/Terraform. You can learn more about all the various configuration options supported in [the reference docs for the terraform block](/docs/reference/config-blocks-and-attributes/#terraform). ### Tflint hook -_Before Hooks_ or _After Hooks_ support natively _tflint_, a linter for Terraform code. It will validate the -Terraform code used by Terragrunt, and it's inputs. +_Before Hooks_ or _After Hooks_ support natively _tflint_, a linter for OpenTofu/Terraform code. It will validate the +OpenTofu/Terraform code used by Terragrunt, and it's inputs. Here's an example: diff --git a/docs/_docs/02_features/inputs.md b/docs/_docs/02_features/inputs.md index 8d03f3589..47fdbc069 100644 --- a/docs/_docs/02_features/inputs.md +++ b/docs/_docs/02_features/inputs.md @@ -34,16 +34,16 @@ $ terragrunt apply TF_VAR_instance_type="t2.micro" \ TF_VAR_instance_count=10 \ TF_VAR_tags='{"Name":"example-app"}' \ -terraform apply +tofu apply # or terraform apply ``` Note that Terragrunt will respect any `TF_VAR_xxx` variables you’ve manually set in your environment, ensuring that anything in `inputs` will NOT override anything you’ve already set in your environment. ### Variable precedence -Terragrunt follows the same variable precedence as [terraform](https://www.terraform.io/docs/configuration/variables.html#variable-definition-precedence). +Terragrunt follows the same variable precedence as [tofu](https://opentofu.org/docs/language/values/variables/#variable-definition-precedence). -If the same variable is assigned multiple values, Terraform will use the **last** value it finds overriding any previous values. +If the same variable is assigned multiple values, OpenTofu will use the **last** value it finds overriding any previous values. Variables are loaded in the following order: diff --git a/docs/_docs/02_features/keep-your-cli-flags-dry.md b/docs/_docs/02_features/keep-your-cli-flags-dry.md index 9f29f0cab..5736bdc8b 100644 --- a/docs/_docs/02_features/keep-your-cli-flags-dry.md +++ b/docs/_docs/02_features/keep-your-cli-flags-dry.md @@ -21,13 +21,13 @@ nav_title_link: /docs/ ### Motivation -Sometimes you may need to pass extra CLI arguments every time you run certain `terraform` commands. For example, you may want to set the `lock-timeout` setting to 20 minutes for all commands that may modify remote state so that Terraform will keep trying to acquire a lock for up to 20 minutes if someone else already has the lock rather than immediately exiting with an error. +Sometimes you may need to pass extra CLI arguments every time you run certain `tofu`/`terraform` commands. For example, you may want to set the `lock-timeout` setting to 20 minutes for all commands that may modify remote state so that OpenTofu/Terraform will keep trying to acquire a lock for up to 20 minutes if someone else already has the lock rather than immediately exiting with an error. You can configure Terragrunt to pass specific CLI arguments for specific commands using an `extra_arguments` block in your `terragrunt.hcl` file: ``` hcl terraform { - # Force Terraform to keep trying to acquire a lock for + # Force OpenTofu/Terraform to keep trying to acquire a lock for # up to 20 minutes if someone else already has the lock extra_arguments "retry_lock" { commands = [ @@ -51,18 +51,18 @@ terraform { } ``` -Each `extra_arguments` block includes an arbitrary name (in the example above, `retry_lock`), a list of `commands` to which the extra arguments should be added, and a list of `arguments` or `required_var_files` or `optional_var_files` to add. You can also pass custom environment variables using `env_vars` block, which stores environment variables in key value pairs. With the configuration above, when you run `terragrunt apply`, Terragrunt will call Terraform as follows: +Each `extra_arguments` block includes an arbitrary name (in the example above, `retry_lock`), a list of `commands` to which the extra arguments should be added, and a list of `arguments` or `required_var_files` or `optional_var_files` to add. You can also pass custom environment variables using `env_vars` block, which stores environment variables in key value pairs. With the configuration above, when you run `terragrunt apply`, Terragrunt will call OpenTofu/Terraform as follows: ```bash $ terragrunt apply # terraform apply -lock-timeout=20m ``` -You can even use built-in functions such as [get\_terraform\_commands\_that\_need\_locking]({{site.baseurl}}/docs/reference/built-in-functions/#get_terraform_commands_that_need_locking) to automatically populate the list of Terraform commands that need locking: +You can even use built-in functions such as [get\_terraform\_commands\_that\_need\_locking]({{site.baseurl}}/docs/reference/built-in-functions/#get_terraform_commands_that_need_locking) to automatically populate the list of OpenTofu/Terraform commands that need locking: ``` hcl terraform { - # Force Terraform to keep trying to acquire a lock for up to 20 minutes if someone else already has the lock + # Force OpenTofu/Terraform to keep trying to acquire a lock for up to 20 minutes if someone else already has the lock extra_arguments "retry_lock" { commands = get_terraform_commands_that_need_locking() arguments = ["-lock-timeout=20m"] @@ -76,14 +76,14 @@ You can specify one or more `extra_arguments` blocks. The `arguments` in each bl ``` hcl terraform { - # Force Terraform to keep trying to acquire a lock for + # Force OpenTofu/Terraform to keep trying to acquire a lock for # up to 20 minutes if someone else already has the lock extra_arguments "retry_lock" { commands = get_terraform_commands_that_need_locking() arguments = ["-lock-timeout=20m"] } - # Pass custom var files to Terraform + # Pass custom var files to OpenTofu/Terraform extra_arguments "custom_vars" { commands = [ "apply", @@ -101,22 +101,22 @@ terraform { } ``` -With the configuration above, when you run `terragrunt apply`, Terragrunt will call Terraform as follows: +With the configuration above, when you run `terragrunt apply`, Terragrunt will call OpenTofu/Terraform as follows: ```bash $ terragrunt apply -# terraform apply -lock-timeout=20m -var foo=bar -var region=us-west-1 +# tofu apply -lock-timeout=20m -var foo=bar -var region=us-west-1 ``` ### `extra_arguments` for `init` Extra arguments for the `init` command have some additional behavior and constraints. -In addition to being appended to the `terraform init` command that is run when you explicitly run `terragrunt init`, `extra_arguments` for `init` will also be appended to the `init` commands that are automatically run during other commands (see [Auto-Init]({{site.baseurl}}/docs/features/auto-init)). +In addition to being appended to the `tofu init`/`terraform init` command that is run when you explicitly run `terragrunt init`, `extra_arguments` for `init` will also be appended to the `init` commands that are automatically run during other commands (see [Auto-Init]({{site.baseurl}}/docs/features/auto-init)). You must *not* specify the `-from-module` option (aka. the `SOURCE` argument for terraform \< 0.10.0) or the `DIR` argument in the `extra_arguments` for `init`. This option and argument will be provided automatically by terragrunt. -Here’s an example of configuring `extra_arguments` for `init` in an environment in which terraform plugins are manually installed, rather than relying on terraform to automatically download them. +Here’s an example of configuring `extra_arguments` for `init` in an environment in which OpenTofu/Terraform plugins are manually installed, rather than relying on OpenTofu/Terraform to automatically download them. ``` hcl terraform { @@ -128,7 +128,7 @@ terraform { ] arguments = [ - "-plugin-dir=/my/terraform/plugin/dir", + "-plugin-dir=/my/tofu/plugin/dir", ] } } @@ -164,7 +164,7 @@ terraform { ] required_var_files = [ - "${get_parent_terragrunt_dir()}/terraform.tfvars" + "${get_parent_terragrunt_dir()}/tofu.tfvars" ] optional_var_files = [ @@ -179,20 +179,20 @@ terraform { See the [get\_terragrunt\_dir()]({{site.baseurl}}/docs/reference/built-in-functions/#get_terragrunt_dir) and [get\_parent\_terragrunt\_dir()]({{site.baseurl}}/docs/reference/built-in-functions/#get_parent_terragrunt_dir) documentation for more details. -With the configuration above, when you run `terragrunt run-all apply`, Terragrunt will call Terraform as follows: +With the configuration above, when you run `terragrunt run-all apply`, Terragrunt will call OpenTofu/Terraform as follows: ```bash $ terragrunt run-all apply -[backend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/backend-app/dev.tfvars -[frontend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/frontend-app/us-east-1.tfvars +[backend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/backend-app/dev.tfvars +[frontend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/frontend-app/us-east-1.tfvars $ TF_VAR_env=prod terragrunt run-all apply -[backend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/prod.tfvars -[frontend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/frontend-app/us-east-1.tfvars +[backend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/prod.tfvars +[frontend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/frontend-app/us-east-1.tfvars $ TF_VAR_env=prod TF_VAR_region=us-west-2 terragrunt run-all apply -[backend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/us-west-2.tfvars -[frontend-app] terraform apply -var-file=/my/tf/terraform.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/us-west-2.tfvars +[backend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/us-west-2.tfvars +[frontend-app] tofu apply -var-file=/my/tf/tofu.tfvars -var-file=/my/tf/prod.tfvars -var-file=/my/tf/us-west-2.tfvars ``` ### Handling whitespace @@ -217,9 +217,9 @@ terraform { } ``` -With the configuration above, when you run `terragrunt apply`, Terragrunt will call Terraform as follows: +With the configuration above, when you run `terragrunt apply`, Terragrunt will call OpenTofu/Terraform as follows: ```bash $ terragrunt apply -# terraform apply -var bucket=example.bucket.name +# tofu apply -var bucket=example.bucket.name ``` diff --git a/docs/_docs/02_features/keep-your-remote-state-configuration-dry.md b/docs/_docs/02_features/keep-your-remote-state-configuration-dry.md index f45e9b972..c06ca9cec 100644 --- a/docs/_docs/02_features/keep-your-remote-state-configuration-dry.md +++ b/docs/_docs/02_features/keep-your-remote-state-configuration-dry.md @@ -21,7 +21,7 @@ nav_title_link: /docs/ ### Motivation -Terraform supports [remote state storage](https://www.terraform.io/docs/state/remote.html) via a variety of [backends](https://www.terraform.io/docs/backends) that you normally configure in your `.tf` files as follows: +OpenTofu/Terraform supports [remote state storage](https://www.terraform.io/docs/state/remote.html) via a variety of [backends](https://www.terraform.io/docs/backends) that you normally configure in your `.tf` files as follows: ``` hcl terraform { @@ -35,7 +35,7 @@ terraform { } ``` -Unfortunately, the `backend` configuration does not support expressions, variables, or functions. This makes it hard to keep your code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) if you have multiple Terraform modules. For example, consider the following folder structure, which uses different Terraform modules to deploy a backend app, frontend app, MySQL database, and a VPC: +Unfortunately, the `backend` configuration does not support expressions, variables, or functions. This makes it hard to keep your code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) if you have multiple OpenTofu/Terraform modules. For example, consider the following folder structure, which uses different OpenTofu/Terraform modules to deploy a backend app, frontend app, MySQL database, and a VPC: ```tree ├── backend-app @@ -54,7 +54,7 @@ To keep your remote state configuration DRY, you can use Terragrunt. ### Filling in remote state settings with Terragrunt -To fill in the settings via Terragrunt, create a `terragrunt.hcl` file in the root folder, plus one `terragrunt.hcl` file in each of the Terraform modules: +To fill in the settings via Terragrunt, create a `terragrunt.hcl` file in the root folder, plus one `terragrunt.hcl` file in each of the OpenTofu/Terraform modules: ```tree ├── terragrunt.hcl @@ -93,7 +93,7 @@ EOF ``` This instructs Terragrunt to create the file `backend.tf` in the working directory (where Terragrunt calls `terraform`) -before it calls any of the Terraform commands, including `init`. This allows you to inject this backend configuration +before it calls any of the OpenTofu/Terraform commands, including `init`. This allows you to inject this backend configuration in all the modules that includes the root file and have `terragrunt` properly initialize the backend configuration with interpolated values. @@ -106,7 +106,7 @@ include "root" { } ``` -The `include` block tells Terragrunt to use the exact same Terragrunt configuration from the `terragrunt.hcl` file specified via the `path` parameter. It behaves exactly as if you had copy/pasted the Terraform configuration from the included file `generate` configuration into `mysql/terragrunt.hcl`, but this approach is much easier to maintain\! +The `include` block tells Terragrunt to use the exact same Terragrunt configuration from the `terragrunt.hcl` file specified via the `path` parameter. It behaves exactly as if you had copy/pasted the OpenTofu/Terraform configuration from the included file `generate` configuration into `mysql/terragrunt.hcl`, but this approach is much easier to maintain\! The next time you run `terragrunt`, it will automatically configure all the settings for the backend, if they aren’t configured already, by calling [terraform init](https://www.terraform.io/docs/commands/init.html). @@ -114,7 +114,7 @@ The `terragrunt.hcl` files above use two Terragrunt built-in functions: - `find_in_parent_folders()`: This function returns the absolute path to the first `terragrunt.hcl` file it finds in the parent folders above the current `terragrunt.hcl` file. In the example above, the call to `find_in_parent_folders()` in `mysql/terragrunt.hcl` will return `/your-root-folder/terragrunt.hcl`. This way, you don’t have to hard code the `path` parameter in every module. -- `path_relative_to_include()`: This function returns the relative path between the current `terragrunt.hcl` file and the path specified in its `include` block. We typically use this in a root `terragrunt.hcl` file so that each Terraform child module stores its Terraform state at a different `key`. For example, the `mysql` module will have its `key` parameter resolve to `mysql/terraform.tfstate` and the `frontend-app` module will have its `key` parameter resolve to `frontend-app/terraform.tfstate`. +- `path_relative_to_include()`: This function returns the relative path between the current `terragrunt.hcl` file and the path specified in its `include` block. We typically use this in a root `terragrunt.hcl` file so that each OpenTofu/Terraform child module stores its OpenTofu/Terraform state at a different `key`. For example, the `mysql` module will have its `key` parameter resolve to `mysql/terraform.tfstate` and the `frontend-app` module will have its `key` parameter resolve to `frontend-app/terraform.tfstate`. See [the Built-in Functions docs]({{site.baseurl}}/docs/reference/built-in-functions/#built-in-functions) for more info. @@ -122,11 +122,11 @@ See [the Built-in Functions docs]({{site.baseurl}}/docs/reference/built-in-funct The `generate` block is useful for allowing you to setup the remote state backend configuration in a DRY manner, but this introduces a bootstrapping problem: how do you create and manage the underlying storage resources for the remote -state? For example, when using the [s3 backend](https://www.terraform.io/language/settings/backends/s3), Terraform +state? For example, when using the [s3 backend](https://www.terraform.io/language/settings/backends/s3), OpenTofu/Terraform expects the S3 bucket to already exist for it to upload the state objects. -Ideally you can manage the S3 bucket using Terraform, but what about the state object for the module managing the S3 -bucket? How do you create the S3 bucket, before you run `terraform`, if you need to run `terraform` to create the +Ideally you can manage the S3 bucket using OpenTofu/Terraform, but what about the state object for the module managing the S3 +bucket? How do you create the S3 bucket, before you run `tofu`/`terraform`, if you need to run `tofu`/`terraform` to create the bucket? To handle this, Terragrunt supports a different block for managing the backend configuration: the [remote_state @@ -134,7 +134,7 @@ block](https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attribut > **NOTE** > -> `remote_state` is an alternative way of managing the Terraform backend compared to `generate`. You can not use both +> `remote_state` is an alternative way of managing the OpenTofu/Terraform backend compared to `generate`. You can not use both > methods at the same time to manage the remote state configuration. When implementing `remote_state`, be sure to remove > the corresponding `generate` block for managing the backend. @@ -235,11 +235,11 @@ remote_state { config = { skip_bucket_versioning = true # use only if the object store does not support versioning - skip_bucket_ssencryption = true # use only if non-encrypted Terraform State is required and/or the object store does not support server-side encryption + skip_bucket_ssencryption = true # use only if non-encrypted OpenTofu/Terraform State is required and/or the object store does not support server-side encryption skip_bucket_root_access = true # use only if the AWS account root user should not have access to the remote state bucket for some reason skip_bucket_enforced_tls = true # use only if you need to access the S3 bucket without TLS being enforced skip_credentials_validation = true # skip validation of AWS credentials, useful when is used S3 compatible object store different from AWS - enable_lock_table_ssencryption = true # use only if non-encrypted DynamoDB Lock Table for the Terraform State is required and/or the NoSQL database service does not support server-side encryption + enable_lock_table_ssencryption = true # use only if non-encrypted DynamoDB Lock Table for the OpenTofu/Terraform State is required and/or the NoSQL database service does not support server-side encryption accesslogging_bucket_name = # use only if you need server access logging to be enabled for your terraform state S3 bucket. Provide a value representing the name of the target bucket to be used for logs output. accesslogging_target_prefix = # use only if you want to set a specific prefix for your terraform state S3 bucket access logs when Server Access Logging is enabled. Provide a value representing the TargetPrefix to be used for the logs output objects. If set to empty , then TargetPrefix will be set to empty . If attribute is not provided at all, then TargetPrefix will be set to default value `TFStateLogs/`. @@ -250,7 +250,7 @@ remote_state { } ``` -If you experience an error for any of these configurations, confirm you are using Terraform v0.12.2 or greater. +If you experience an error for any of these configurations, confirm you are using OpenTofu or Terraform v0.12.2 or greater. Further, the config options `s3_bucket_tags`, `dynamodb_table_tags`, `accesslogging_bucket_tags`, `skip_bucket_versioning`, `skip_bucket_ssencryption`, `skip_bucket_root_access`, `skip_bucket_enforced_tls`, `skip_bucket_public_access_blocking`, `accesslogging_bucket_name`, `accesslogging_target_prefix`, and `enable_lock_table_ssencryption` are only valid for backend `s3`. They are used by terragrunt and are **not** passed on to terraform. See section [Create remote state and locking resources automatically](#create-remote-state-and-locking-resources-automatically). diff --git a/docs/_docs/02_features/keep-your-terraform-code-dry.md b/docs/_docs/02_features/keep-your-terraform-code-dry.md index f164662e2..212f5ec95 100644 --- a/docs/_docs/02_features/keep-your-terraform-code-dry.md +++ b/docs/_docs/02_features/keep-your-terraform-code-dry.md @@ -1,27 +1,27 @@ --- layout: collection-browser-doc -title: Keep your Terraform code DRY +title: Keep your OpenTofu/Terraform code DRY category: features categories_url: features -excerpt: Learn how to achieve DRY Terraform code and immutable infrastructure. +excerpt: Learn how to achieve DRY OpenTofu/Terraform code and immutable infrastructure. tags: ["DRY", "Use cases", "backend"] order: 200 nav_title: Documentation nav_title_link: /docs/ --- -## Keep your Terraform code DRY +## Keep your OpenTofu/Terraform code DRY -- [Keep your Terraform code DRY](#keep-your-terraform-code-dry) +- [Keep your OpenTofu/Terraform code DRY](#keep-your-opentofuterraform-code-dry) - [Motivation](#motivation) - - [Remote Terraform configurations](#remote-terraform-configurations) - - [Achieve DRY Terraform code and immutable infrastructure](#achieve-dry-terraform-code-and-immutable-infrastructure) + - [Remote OpenTofu/Terraform configurations](#remote-opentofuterraform-configurations) + - [Achieve DRY OpenTofu/Terraform code and immutable infrastructure](#achieve-dry-opentofuterraform-code-and-immutable-infrastructure) - [Working locally](#working-locally) - [Working with lock files](#working-with-lock-files) - [Important gotcha: Terragrunt caching](#important-gotcha-terragrunt-caching) - [Important gotcha: working with relative file paths](#important-gotcha-working-with-relative-file-paths) - [Using Terragrunt with private Git repos](#using-terragrunt-with-private-git-repos) - - [DRY common Terraform code with Terragrunt generate blocks](#dry-common-terraform-code-with-terragrunt-generate-blocks) + - [DRY common OpenTofu/Terraform code with Terragrunt generate blocks](#dry-common-opentofuterraform-code-with-terragrunt-generate-blocks) ### Motivation @@ -52,13 +52,13 @@ Consider the following file structure, which defines three environments (prod, q └── main.tf ``` -The contents of each environment will be more or less identical, except perhaps for a few settings (e.g. the prod environment may run bigger or more servers). As the size of the infrastructure grows, having to maintain all of this duplicated code between environments becomes more error prone. You can reduce the amount of copy paste using [Terraform modules](https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d), but even the code to instantiate a module and set up input variables, output variables, providers, and remote state can still create a lot of maintenance overhead. +The contents of each environment will be more or less identical, except perhaps for a few settings (e.g. the prod environment may run bigger or more servers). As the size of the infrastructure grows, having to maintain all of this duplicated code between environments becomes more error prone. You can reduce the amount of copy paste using [OpenTofu/Terraform modules](https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d), but even the code to instantiate a module and set up input variables, output variables, providers, and remote state can still create a lot of maintenance overhead. -How can you keep your Terraform code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) so that you only have to define it once, no matter how many environments you have? +How can you keep your OpenTofu/Terraform code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) so that you only have to define it once, no matter how many environments you have? -### Remote Terraform configurations +### Remote OpenTofu/Terraform configurations -Terragrunt has the ability to download remote Terraform configurations. The idea is that you define the Terraform code for your infrastructure just once, in a single repo, called, for example, `modules`: +Terragrunt has the ability to download remote OpenTofu/Terraform configurations. The idea is that you define the OpenTofu/Terraform code for your infrastructure just once, in a single repo, called, for example, `modules`: ```tree └── modules @@ -70,7 +70,7 @@ Terragrunt has the ability to download remote Terraform configurations. The idea └── main.tf ``` -This repo contains typical Terraform code, with one difference: anything in your code that should be different between environments should be exposed as an input variable. For example, the `app` module might expose the following variables: +This repo contains typical OpenTofu/Terraform code, with one difference: anything in your code that should be different between environments should be exposed as an input variable. For example, the `app` module might expose the following variables: ``` hcl variable "instance_count" { @@ -111,7 +111,7 @@ In a separate repo, called, for example, `live`, you define the code for all of └── terragrunt.hcl ``` -Notice how there are no Terraform configurations (`.tf` files) in any of the folders. Instead, each `terragrunt.hcl` file specifies a `terraform { …​ }` block that specifies from where to download the Terraform code, as well as the environment-specific values for the input variables in that Terraform code. For example, `stage/app/terragrunt.hcl` may look like this: +Notice how there are no OpenTofu/Terraform configurations (`.tf` files) in any of the folders. Instead, each `terragrunt.hcl` file specifies a `terraform { …​ }` block that specifies from where to download the OpenTofu/Terraform code, as well as the environment-specific values for the input variables in that OpenTofu/Terraform code. For example, `stage/app/terragrunt.hcl` may look like this: ``` hcl terraform { @@ -125,7 +125,7 @@ inputs = { } ``` -*(Note: the double slash (`//`) in the `source` parameter is intentional and required. It’s part of Terraform’s Git syntax for [module sources](https://www.terraform.io/docs/modules/sources.html). Terraform may display a "Terraform initialized in an empty directory" warning, but you can safely ignore it.)* +*(Note: the double slash (`//`) in the `source` parameter is intentional and required. It’s part of OpenTofu/Terraform’s Git syntax for [module sources](https://opentofu.org/docs/language/modules/sources/). OpenTofu/Terraform may display a "OpenTofu/Terraform initialized in an empty directory" warning, but you can safely ignore it.)* And `prod/app/terragrunt.hcl` may look like this: @@ -150,21 +150,21 @@ terragrunt apply When Terragrunt finds the `terraform` block with a `source` parameter in `live/stage/app/terragrunt.hcl` file, it will: -1. Download the configurations specified via the `source` parameter into the `--terragrunt-download-dir` folder (by default `.terragrunt-cache` in the working directory, which we recommend adding to `.gitignore`). This downloading is done by using the same [go-getter library](https://github.com/hashicorp/go-getter) Terraform uses, so the `source` parameter supports the exact same syntax as the [module source](https://www.terraform.io/docs/modules/sources.html) parameter, including local file paths, Git URLs, and Git URLs with `ref` parameters (useful for checking out a specific tag, commit, or branch of Git repo). Terragrunt will download all the code in the repo (i.e. the part before the double-slash `//`) so that relative paths work correctly between modules in that repo. +1. Download the configurations specified via the `source` parameter into the `--terragrunt-download-dir` folder (by default `.terragrunt-cache` in the working directory, which we recommend adding to `.gitignore`). This downloading is done by using the same [go-getter library](https://github.com/hashicorp/go-getter) OpenTofu/Terraform uses, so the `source` parameter supports the exact same syntax as the [module source](https://opentofu.org/docs/language/modules/sources/) parameter, including local file paths, Git URLs, and Git URLs with `ref` parameters (useful for checking out a specific tag, commit, or branch of Git repo). Terragrunt will download all the code in the repo (i.e. the part before the double-slash `//`) so that relative paths work correctly between modules in that repo. 2. Copy all files from the current working directory into the temporary folder. -3. Execute whatever Terraform command you specified in that temporary folder. +3. Execute whatever OpenTofu/Terraform command you specified in that temporary folder. -4. Pass any variables defined in the `inputs = { …​ }` block as environment variables (prefixed with `TF_VAR_` to your Terraform code. Notice how the `inputs` block in `stage/app/terragrunt.hcl` deploys fewer and smaller instances than prod. +4. Pass any variables defined in the `inputs = { …​ }` block as environment variables (prefixed with `TF_VAR_` to your OpenTofu/Terraform code. Notice how the `inputs` block in `stage/app/terragrunt.hcl` deploys fewer and smaller instances than prod. Check out the [terragrunt-infrastructure-modules-example](https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example) and [terragrunt-infrastructure-live-example](https://github.com/gruntwork-io/terragrunt-infrastructure-live-example) repos for fully-working sample code that demonstrates this new folder structure. -### Achieve DRY Terraform code and immutable infrastructure +### Achieve DRY OpenTofu/Terraform code and immutable infrastructure With this new approach, copy/paste between environments is minimized. The `terragrunt.hcl` files contain solely the `source` URL of the module to deploy and the `inputs` to set for that module in the current environment. To create a new environment, you copy an old one and update just the environment-specific `inputs` in the `terragrunt.hcl` files, which is about as close to the "essential complexity" of the problem as you can get. -Just as importantly, since the Terraform module code is now defined in a single repo, you can version it (e.g., using Git tags and referencing them using the `ref` parameter in the `source` URL, as in the `stage/app/terragrunt.hcl` and `prod/app/terragrunt.hcl` examples above), and promote a single, immutable version through each environment (e.g., qa → stage → prod). This idea is inspired by Kief Morris' blog post [Using Pipelines to Manage Environments with Infrastructure as Code](https://medium.com/@kief/https-medium-com-kief-using-pipelines-to-manage-environments-with-infrastructure-as-code-b37285a1cbf5). +Just as importantly, since the OpenTofu/Terraform module code is now defined in a single repo, you can version it (e.g., using Git tags and referencing them using the `ref` parameter in the `source` URL, as in the `stage/app/terragrunt.hcl` and `prod/app/terragrunt.hcl` examples above), and promote a single, immutable version through each environment (e.g., qa → stage → prod). This idea is inspired by Kief Morris' blog post [Using Pipelines to Manage Environments with Infrastructure as Code](https://medium.com/@kief/https-medium-com-kief-using-pipelines-to-manage-environments-with-infrastructure-as-code-b37285a1cbf5). ### Working locally @@ -175,7 +175,7 @@ cd live/stage/app terragrunt apply --terragrunt-source ../../../modules//app ``` -*(Note: the double slash (`//`) here too is intentional and required. Terragrunt downloads all the code in the folder before the double-slash into the temporary folder so that relative paths between modules work correctly. Terraform may display a "Terraform initialized in an empty directory" warning, but you can safely ignore it.)* +*(Note: the double slash (`//`) here too is intentional and required. Terragrunt downloads all the code in the folder before the double-slash into the temporary folder so that relative paths between modules work correctly. OpenTofu/Terraform may display a "OpenTofu/Terraform initialized in an empty directory" warning, but you can safely ignore it.)* ### Working with lock files @@ -193,7 +193,7 @@ If you need to force Terragrunt to redownload something from a remote URL, run T ### Important gotcha: working with relative file paths -One of the gotchas with downloading Terraform configurations is that when you run `terragrunt apply` in folder `foo`, Terraform will actually execute in some temporary folder such as `.terragrunt-cache/foo`. That means you have to be especially careful with relative file paths, as they will be relative to that temporary folder and not the folder where you ran Terragrunt\! +One of the gotchas with downloading OpenTofu/Terraform configurations is that when you run `terragrunt apply` in folder `foo`, OpenTofu/Terraform will actually execute in some temporary folder such as `.terragrunt-cache/foo`. That means you have to be especially careful with relative file paths, as they will be relative to that temporary folder and not the folder where you ran Terragrunt\! In particular: @@ -248,15 +248,15 @@ Note: In automated pipelines, you may need to run the following command for your ssh -T -oStrictHostKeyChecking=accept-new git@github.com || true ``` -### DRY common Terraform code with Terragrunt generate blocks +### DRY common OpenTofu/Terraform code with Terragrunt generate blocks -Terragrunt has the ability to generate code in to the downloaded remote Terraform modules before calling out to -`terraform` using the [generate block](/docs/reference/config-blocks-and-attributes#generate). This can be used to -inject common terraform configurations into all the modules that you use. +Terragrunt has the ability to generate code in to the downloaded remote OpenTofu/Terraform modules before calling out to +`tofu`/`terraform` using the [generate block](/docs/reference/config-blocks-and-attributes#generate). This can be used to +inject common OpenTofu/Terraform configurations into all the modules that you use. For example, it is common to have custom provider configurations in your code to customize authentication. Consider a -setup where you want to always assume a specific role when calling out to the terraform module. However, not all modules -expose the right variables for configuring the `aws` provider so that you can assume the role through Terraform. +setup where you want to always assume a specific role when calling out to the OpenTofu/Terraform module. However, not all modules +expose the right variables for configuring the `aws` provider so that you can assume the role through OpenTofu/Terraform. In this situation, you can use Terragrunt `generate` blocks to generate a tf file called `provider.tf` that includes the provider configuration. Add a root `terragrunt.hcl` file for each of the environments in the file layout for the live @@ -309,8 +309,8 @@ EOF } ``` -This instructs Terragrunt to create the file `provider.tf` in the working directory (where Terragrunt calls `terraform`) -before it calls any of the Terraform commands (e.g `plan`, `apply`, `validate`, etc). This allows you to inject this +This instructs Terragrunt to create the file `provider.tf` in the working directory (where Terragrunt calls `tofu`/`terraform`) +before it calls any of the OpenTofu/Terraform commands (e.g `plan`, `apply`, `validate`, etc). This allows you to inject this provider configuration in all the modules that includes the root file. To include this in the child configurations (e.g `mysql/terragrunt.hcl`), you would update all the child modules to @@ -323,5 +323,5 @@ include "root" { ``` The `include` block tells Terragrunt to use the exact same Terragrunt configuration from the `terragrunt.hcl` file -specified via the `path` parameter. It behaves exactly as if you had copy/pasted the Terraform configuration from the +specified via the `path` parameter. It behaves exactly as if you had copy/pasted the OpenTofu/Terraform configuration from the included file `generate` configuration into the child, but this approach is much easier to maintain\! diff --git a/docs/_docs/02_features/keep-your-terragrunt-architecture-dry.md b/docs/_docs/02_features/keep-your-terragrunt-architecture-dry.md index 5aa9d5b24..59aea4763 100644 --- a/docs/_docs/02_features/keep-your-terragrunt-architecture-dry.md +++ b/docs/_docs/02_features/keep-your-terragrunt-architecture-dry.md @@ -21,7 +21,7 @@ nav_title_link: /docs/ ### Motivation -As covered in [Keep your Terraform code DRY]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry) and [Keep your +As covered in [Keep your OpenTofu/Terraform code DRY]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry) and [Keep your remote state configuration DRY]({{site.baseurl}}/docs/features/keep-your-remote-state-configuration-dry), it becomes important to define base Terragrunt configuration files that are included in the child config. For example, you might have a **root** Terragrunt configuration that defines the remote state and provider configurations: diff --git a/docs/_docs/02_features/lock-file-handling.md b/docs/_docs/02_features/lock-file-handling.md index 2b2464e0f..0dbbdda57 100644 --- a/docs/_docs/02_features/lock-file-handling.md +++ b/docs/_docs/02_features/lock-file-handling.md @@ -3,7 +3,7 @@ layout: collection-browser-doc title: Lock File Handling category: features categories_url: features -excerpt: Learn how to Terragrunt handles the Terraform lock file +excerpt: Learn how to Terragrunt handles the OpenTofu/Terraform lock file tags: ["CLI", "DRY"] order: 270 nav_title: Documentation @@ -12,13 +12,13 @@ nav_title_link: /docs/ ## The short version: how to use lock files with Terragrunt -To use [Terraform lock files](https://www.terraform.io/docs/configuration/dependency-lock.html) with Terragrunt, you +To use [OpenTofu/Terraform lock files](https://opentofu.org/docs/language/files/dependency-lock/) with Terragrunt, you need to: 1. Run Terragrunt as usual (e.g., run `terragrunt plan`, `terragrunt apply`, etc.). 1. Check the `.terraform.lock.hcl` file, which will end up sitting next to your `terragrunt.hcl`, into version control. -Everything else with Terraform and Terragrunt should work as expected. To learn the details of how this works, read on! +Everything else with OpenTofu/Terraform and Terragrunt should work as expected. To learn the details of how this works, read on! ## The long version: details of how Terragrunt handles lock files @@ -26,14 +26,14 @@ Everything else with Terraform and Terragrunt should work as expected. To learn [Terraform 0.14 added support for a *lock file*](https://www.hashicorp.com/blog/terraform-0-14-introduces-a-dependency-lock-file-for-providers) -which gets created or updated every time you run `terraform init`. The file is typically generated into your working -directory (i.e., the folder in which you ran `terraform init`) and is called `.terraform.lock.hcl`. -It captures the versions of all the Terraform providers you're using. Normally, you want to check this file into -version control so that when your team members run Terraform, they get the exact same provider versions. +which gets created or updated every time you run `tofu init`/`terraform init`. The file is typically generated into your working +directory (i.e., the folder in which you ran `tofu init`/`terraform init`) and is called `.terraform.lock.hcl`. +It captures the versions of all the OpenTofu/Terraform providers you're using. Normally, you want to check this file into +version control so that when your team members run OpenTofu/Terraform, they get the exact same provider versions. -### The problem with mixing remote Terraform configurations in Terragrunt and lock files +### The problem with mixing remote OpenTofu/Terraform configurations in Terragrunt and lock files -Let's say you are using Terragrunt with [remote Terraform +Let's say you are using Terragrunt with [remote OpenTofu/Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/) and you have the following folder structure: @@ -59,7 +59,7 @@ If you ran `terragrunt apply` in the `/live/stage/vpc` folder, Terragrunt will: 1. `git clone` the VPC module in the `source` URL into a temp folder in `.terragrunt-cache/xxx/vpc`, where `xxx` is dynamically determined based on the URL. -1. Run `terraform apply` in the `.terragrunt-cache/xxx/vpc` temp folder. +1. Run `tofu apply`/`terraform apply` in the `.terragrunt-cache/xxx/vpc` temp folder. As a result, the `.terraform.lock.hcl` file will be generated in the `.terragrunt-cache/xxx/vpc` temp folder, rather than in `/live/stage/vpc`. @@ -69,10 +69,10 @@ than in `/live/stage/vpc`. To solve this problem, since version v0.27.0, Terragrunt implements the following logic for lock files: 1. If Terragrunt finds a `.terraform.lock.hcl` file in your working directory (e.g., in `/live/stage/vpc`), before - running Terraform, Terragrunt will copy that lock file into the temp folder it uses when running your Terraform code + running OpenTofu/Terraform, Terragrunt will copy that lock file into the temp folder it uses when running your OpenTofu/Terraform code (e.g., `.terragrunt-cache/xxx/vpc`). This way, if you had a lock file checked into version control, Terragrunt will - respect and use it with your Terraform code as you'd expect. -1. After running Terraform, if Terragrunt finds a `.terraform.lock.hcl` in the temp folder (e.g., + respect and use it with your OpenTofu/Terraform code as you'd expect. +1. After running OpenTofu/Terraform, if Terragrunt finds a `.terraform.lock.hcl` in the temp folder (e.g., `.terragrunt-cache/xxx/vpc`), it will copy that lock file back to your working directory (e.g., to `/live/stage/vpc`). That way, you can commit the lock file (or the changes to the lock file) to version control as usual. diff --git a/docs/_docs/02_features/provider-cache.md b/docs/_docs/02_features/provider-cache.md index b2d4eeacf..88f5188df 100644 --- a/docs/_docs/02_features/provider-cache.md +++ b/docs/_docs/02_features/provider-cache.md @@ -12,15 +12,15 @@ nav_title_link: /docs/ ## Provider Caching -Terragrunt has the ability to cache Terraform providers across all Terraform instances, ensuring that each provider is only ever downloaded and stored on disk exactly once. +Terragrunt has the ability to cache OpenTofu/Terraform providers across all OpenTofu/Terraform instances, ensuring that each provider is only ever downloaded and stored on disk exactly once. ### Why caching is useful Let's imagine that your project consists of 50 Terragrunt modules (terragrunt.hcl), each of them uses the same provider `aws`. Without caching, each of them will download the provider from the Internet and stored in its own `.terraform` directory. For clarity, the downloadable archive `terraform-provider-aws_5.36.0_darwin_arm64.zip` has a size of ~100MB, and when unzipped it takes up ~450MB of disk space. It’s easy to calculate that initializing such a project with 50 modules will cost you 5GB of traffic and 22.5GB of free space instead of 100MB and 450MB using the cache. -### Why Terraform's built-in provider caching doesn't work +### Why OpenTofu/Terraform's built-in provider caching doesn't work -Terraform has provider caching feature [Provider Plugin Cache](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-plugin-cache), that does the job well until you run multiple Terraform processes simultaneously, such as when you use `terragrunt run-all`. Then the Terraform processes begin conflict by overwriting each other’s cache, which causes the error like `Error: Failed to install provider`. As a result, Terragrunt previously had to disable concurrency for `init` steps in `run-all`, which is significantly slower. If you enable Terragrunt Provider Caching, as described in this section, that will no longer be necessary, and you should see significant performance improvements with `init`, as well as significant savings in terms of bandwidth and disk space usage. +OpenTofu/Terraform has provider caching feature [Provider Plugin Cache](https://opentofu.org/docs/cli/config/config-file/#provider-plugin-cache), that does the job well until you run multiple OpenTofu/Terraform processes simultaneously, such as when you use `terragrunt run-all`. Then the OpenTofu/Terraform processes begin conflict by overwriting each other’s cache, which causes the error like `Error: Failed to install provider`. As a result, Terragrunt previously had to disable concurrency for `init` steps in `run-all`, which is significantly slower. If you enable Terragrunt Provider Caching, as described in this section, that will no longer be necessary, and you should see significant performance improvements with `init`, as well as significant savings in terms of bandwidth and disk space usage. ### Usage @@ -42,7 +42,7 @@ By default, cached providers are stored in `terragrunt/providers` folder, which - `$HOME/Library/Caches/terragrunt/providers` on Darwin - `%LocalAppData%\terragrunt\providers` on Windows -The file structure of the cache directory is identical to the Terraform [plugin_cache_dir](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-plugin-cache) directory. If you already have a directory with providers cached by Terraform [plugin_cache_dir](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-plugin-cache), you can set this path using the flag [`terragrunt-provider-cache-dir`](https://terragrunt.gruntwork.io/docs/link/cli-options/#terragrunt-provider-cache-dir), to make cache server reuse them. +The file structure of the cache directory is identical to the OpenTofu/Terraform [plugin_cache_dir](https://opentofu.org/docs/cli/config/config-file/#provider-plugin-cache) directory. If you already have a directory with providers cached by OpenTofu/Terraform [plugin_cache_dir](https://opentofu.org/docs/cli/config/config-file/#provider-plugin-cache), you can set this path using the flag [`terragrunt-provider-cache-dir`](https://terragrunt.gruntwork.io/docs/link/cli-options/#terragrunt-provider-cache-dir), to make cache server reuse them. ```shell terragrunt plan \ @@ -78,22 +78,22 @@ terragrunt apply ### How Terragrunt Provider Caching works - Start a server on localhost. This is the _Terragrunt Provider Cache server_. -- Configure Terraform instances to use the Terragrunt Provider Cache server as a remote registry: +- Configure OpenTofu/Terraform instances to use the Terragrunt Provider Cache server as a remote registry: - - Create local CLI config file `.terraformrc` for each module that concatenates the user configuration from the Terraform [CLI config file](https://developer.hashicorp.com/terraform/cli/config/config-file) with additional sections: + - Create local CLI config file `.terraformrc` for each module that concatenates the user configuration from the OpenTofu/Terraform [CLI config file](https://opentofu.org/docs/cli/config/config-file/) with additional sections: - - [provider-installation](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-installation) forces Terraform to look for for the required providers in the cache directory and create symbolic links to them, if not found, then request them from the remote registry. - - [host](https://github.com/hashicorp/terraform/issues/28309) forces Terraform to [forward](#how-forwarding-terraform-requests-through-the-terragrunt-provider-cache-works) all provider requests through the Terragrunt Provider Cache server. The address link contains [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) and is unique for each module, used by Terragrunt Provider Cache server to associate modules with the requested providers. + - [provider-installation](https://opentofu.org/docs/cli/config/config-file/#provider-installation) forces OpenTofu/Terraform to look for for the required providers in the cache directory and create symbolic links to them, if not found, then request them from the remote registry. + - [host](https://github.com/hashicorp/terraform/issues/28309) forces OpenTofu/Terraform to [forward](#how-forwarding-opentofuterraform-requests-through-the-terragrunt-provider-cache-works) all provider requests through the Terragrunt Provider Cache server. The address link contains [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) and is unique for each module, used by Terragrunt Provider Cache server to associate modules with the requested providers. - Set environment variables: - - [TF_CLI_CONFIG_FILE](https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_plugin_cache_dir) sets to use just created local CLI config `.terragrunt-cache/.terraformrc` - - [TF*TOKEN*\*](https://developer.hashicorp.com/terraform/cli/config/config-file#environment-variable-credentials) sets per-remote-registry tokens for authentication to Terragrunt Provider Cache server. + - [TF_CLI_CONFIG_FILE](https://opentofu.org/docs/cli/config/environment-variables/#tf_plugin_cache_dir) sets to use just created local CLI config `.terragrunt-cache/.terraformrc` + - [TF*TOKEN*\*](https://opentofu.org/docs/cli/config/config-file/#environment-variable-credentials) sets per-remote-registry tokens for authentication to Terragrunt Provider Cache server. - Any time Terragrunt is going to run `init`: - - Call `terraform init`. This gets Terraform to request all the providers it needs from the Terragrunt Provider Cache server. - - The Terragrunt Provider Cache server will download the provider from the remote registry, unpack and store it into the cache directory or [create a symlink](#reusing-providers-from-the-user-plugins-directory) if the required provider exists in the user plugins directory. Note that the Terragrunt Provider Cache server will ensure that each unique provider is only ever downloaded and stored on disk once, handling concurrency (from multiple Terraform and Terragrunt instances) correctly. Along with the provider, the cache server downloads hashes and signatures of the providers to check that the files are not corrupted. - - The Terragrunt Provider Cache server returns the HTTP status _429 Locked_ to Terraform. This is because we do _not_ want Terraform to actually download any providers as a result of calling `terraform init`; we only use that command to request the Terragrunt Provider Cache Server to start caching providers. + - Call `terraform init`. This gets OpenTofu/Terraform to request all the providers it needs from the Terragrunt Provider Cache server. + - The Terragrunt Provider Cache server will download the provider from the remote registry, unpack and store it into the cache directory or [create a symlink](#reusing-providers-from-the-user-plugins-directory) if the required provider exists in the user plugins directory. Note that the Terragrunt Provider Cache server will ensure that each unique provider is only ever downloaded and stored on disk once, handling concurrency (from multiple OpenTofu/Terraform and Terragrunt instances) correctly. Along with the provider, the cache server downloads hashes and signatures of the providers to check that the files are not corrupted. + - The Terragrunt Provider Cache server returns the HTTP status _429 Locked_ to OpenTofu/Terraform. This is because we do _not_ want OpenTofu/Terraform to actually download any providers as a result of calling `terraform init`; we only use that command to request the Terragrunt Provider Cache Server to start caching providers. - At this point, all providers are downloaded and cached, so finally, we run `terragrunt init` a second time, which will find all the providers it needs in the cache, and it'll create symlinks to them nearly instantly, with no additional downloading. - - Note that if a Terraform module doesn't have a lock file, Terraform does _not_ use the cache, so it would end up downloading all the providers from scratch. To work around this, we generate `.terraform.lock.hcl` based on the request made by `terrafrom init` to the Terragrunt Provider Cache server. Since `terraform init` only requestes the providers that need to be added/updated, we can keep track of them using the Terragrunt Provider Cache server and update the Terraform lock file with the appropriate hashes without having to parse `tf` configs. + - Note that if a OpenTofu/Terraform module doesn't have a lock file, OpenTofu/Terraform does _not_ use the cache, so it would end up downloading all the providers from scratch. To work around this, we generate `.terraform.lock.hcl` based on the request made by `terrafrom init` to the Terragrunt Provider Cache server. Since `terraform init` only requestes the providers that need to be added/updated, we can keep track of them using the Terragrunt Provider Cache server and update the OpenTofu/Terraform lock file with the appropriate hashes without having to parse `tf` configs. #### Reusing providers from the user plugins directory @@ -102,9 +102,9 @@ Some plugins for some operating systems may not be available in the remote regis - %APPDATA%\terraform.d\plugins on Windows - ~/.terraform.d/plugins on other systems -#### How forwarding Terraform requests through the Terragrunt Provider Cache works +#### How forwarding OpenTofu/Terraform requests through the Terragrunt Provider Cache works -Terraform has an official documented setting [network_mirror](https://developer.hashicorp.com/terraform/cli/config/config-file#network_mirror), that works great, but has one major drawback for the local cache server - the need to use https connection with a trusted certificate. Fortunately, there is another way - using the undocumented [host](https://github.com/hashicorp/terraform/issues/28309) setting, which allows Terraform to create connections to the caching server over HTTP. +OpenTofu/Terraform has an official documented setting [network_mirror](https://developer.hashicorp.com/terraform/cli/config/config-file#network_mirror), that works great, but has one major drawback for the local cache server - the need to use https connection with a trusted certificate. Fortunately, there is another way - using the undocumented [host](https://github.com/hashicorp/terraform/issues/28309) setting, which allows OpenTofu/Terraform to create connections to the caching server over HTTP. #### Provider Cache with `providers lock` command @@ -117,7 +117,7 @@ terragrunt providers lock -platform=linux_amd64 -platform=darwin_arm64 -platform ### Configure the Terragrunt Cache Provider -Since Terragrunt Provider Cache is essentially a Private Registry server that accepts requests from Terraform, downloads and saves providers to the cache directory, there are a few more flags that are unlikely to be needed, but are useful to know about: +Since Terragrunt Provider Cache is essentially a Private Registry server that accepts requests from OpenTofu/Terraform, downloads and saves providers to the cache directory, there are a few more flags that are unlikely to be needed, but are useful to know about: - Server Hostname [`terragrunt-provider-cache-hostname`](https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-provider-cache-hostname), by default, `localhost`. - Server Port [`terragrunt-provider-cache-port`](https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-provider-cache-port), assigned automatically every time you launch the Terragurnt. diff --git a/docs/_docs/02_features/scaffold.md b/docs/_docs/02_features/scaffold.md index 0f59923e0..e87e050a7 100644 --- a/docs/_docs/02_features/scaffold.md +++ b/docs/_docs/02_features/scaffold.md @@ -14,7 +14,7 @@ nav_title_link: /docs/ Terragrunt scaffolding can generate files for you automatically using [boilerplate](https://github.com/gruntwork-io/boilerplate) templates. -Currently, one boilerplate template is supported out-of-the-box, which you can use to generate a best-practices `terragrunt.hcl` that configures a Terraform module for deployment: +Currently, one boilerplate template is supported out-of-the-box, which you can use to generate a best-practices `terragrunt.hcl` that configures a OpenTofu/Terraform module for deployment: ```bash terragrunt scaffold [TEMPLATE_URL] [--var] [--var-file] @@ -22,12 +22,12 @@ terragrunt scaffold [TEMPLATE_URL] [--var] [--var-file] Description: -- `MODULE_URL` - URL to a Terraform module. Can be a local file path, git URL, registry URL, or any other [module source URL](https://developer.hashicorp.com/terraform/language/modules/sources). +- `MODULE_URL` - URL to a OpenTofu/Terraform module. Can be a local file path, git URL, registry URL, or any other [module source URL](https://developer.hashicorp.com/terraform/language/modules/sources). - `TEMPLATE_URL` - Optional URL to a custom boilerplate template to use to generate HCL files. Can be a local file path, git URL, registry URL, or any other [module source URL](https://developer.hashicorp.com/terraform/language/modules/sources). If not specified, Terragrunt will: - Look for a `.boilerplate` folder in the module at `MODULE_URL`, and if found, use the boilerplate template in that folder. - - Failing to find that, Terragrunt will use a boilerplate template that is built-in, which creates a best-practices `terragrunt.hcl` for deploying a single Terraform module. + - Failing to find that, Terragrunt will use a boilerplate template that is built-in, which creates a best-practices `terragrunt.hcl` for deploying a single OpenTofu/Terraform module. -For example, here's how you can generate a `terragrunt.hcl` file to configure an [example MySQL Terraform module](https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example/tree/master/mysql) for deployment: +For example, here's how you can generate a `terragrunt.hcl` file to configure an [example MySQL OpenTofu/Terraform module](https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example/tree/master/mysql) for deployment: ```bash terragrunt scaffold github.com/gruntwork-io/terragrunt-infrastructure-modules-example//modules/mysql diff --git a/docs/_docs/02_features/work-with-multiple-aws-accounts.md b/docs/_docs/02_features/work-with-multiple-aws-accounts.md index 4db2475b6..b6bb00f43 100644 --- a/docs/_docs/02_features/work-with-multiple-aws-accounts.md +++ b/docs/_docs/02_features/work-with-multiple-aws-accounts.md @@ -16,13 +16,13 @@ nav_title_link: /docs/ The most secure way to manage infrastructure in AWS is to use [multiple AWS accounts](https://aws.amazon.com/organizations/getting-started/best-practices/). You define all your IAM users in one account (e.g., the "security" account) and deploy all of your infrastructure into a number of other accounts (e.g., the "dev", "stage", and "prod" accounts). To access those accounts, you login to the security account and [assume an IAM role](http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) in the other accounts. -There are a few ways to assume IAM roles when using AWS CLI tools, such as Terraform: +There are a few ways to assume IAM roles when using AWS CLI tools, such as OpenTofu/Terraform: -1. One option is to create a named [profile](http://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html), each with a different [role_arn](http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) parameter. You then tell Terraform which profile to use via the `AWS_PROFILE` environment variable. The downside to using profiles is that you have to store your AWS credentials in plaintext on your hard drive. +1. One option is to create a named [profile](http://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html), each with a different [role_arn](http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) parameter. You then tell OpenTofu/Terraform which profile to use via the `AWS_PROFILE` environment variable. The downside to using profiles is that you have to store your AWS credentials in plaintext on your hard drive. -2. Another option is to use environment variables and the [AWS CLI](https://aws.amazon.com/cli/). You first set the credentials for the security account (the one where your IAM users are defined) as the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` and run `aws sts assume-role --role-arn `. This gives you back a blob of JSON that contains new `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` values you can set as environment variables to allow Terraform to use that role. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext. The disadvantage is that assuming an IAM role requires several tedious steps. Worse yet, the credentials you get back from the `assume-role` command are only good for up to 1 hour, so you have to repeat this process often. +2. Another option is to use environment variables and the [AWS CLI](https://aws.amazon.com/cli/). You first set the credentials for the security account (the one where your IAM users are defined) as the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` and run `aws sts assume-role --role-arn `. This gives you back a blob of JSON that contains new `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` values you can set as environment variables to allow OpenTofu/Terraform to use that role. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext. The disadvantage is that assuming an IAM role requires several tedious steps. Worse yet, the credentials you get back from the `assume-role` command are only good for up to 1 hour, so you have to repeat this process often. -3. A final option is to modify your AWS provider with the [assume_role configuration](https://www.terraform.io/docs/providers/aws/#assume-role) and your S3 backend with the [role_arn parameter](https://www.terraform.io/docs/backends/types/s3.html#role_arn). You can then set the credentials for the security account (the one where your IAM users are defined) as the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` and when you run `terraform apply` or `terragrunt apply`, Terraform/Terragrunt will assume the IAM role you specify automatically. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext, and you get fresh credentials on every run of `apply`, without the complexity of calling `assume-role`. The disadvantage is that you have to modify all your Terraform / Terragrunt code to set the `role_arn` param and your Terraform backend configuration will change (and prompt you to manually confirm the update\!) every time you change the IAM role you’re using. +3. A final option is to modify your AWS provider with the [assume_role configuration](https://www.terraform.io/docs/providers/aws/#assume-role) and your S3 backend with the [role_arn parameter](https://opentofu.org/docs/language/settings/backends/s3/#assume-role-configuration). You can then set the credentials for the security account (the one where your IAM users are defined) as the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` and when you run `terraform apply` or `terragrunt apply`, OpenTofu/Terraform / Terragrunt will assume the IAM role you specify automatically. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext, and you get fresh credentials on every run of `apply`, without the complexity of calling `assume-role`. The disadvantage is that you have to modify all your OpenTofu/Terraform / Terragrunt code to set the `role_arn` param and your OpenTofu/Terraform backend configuration will change (and prompt you to manually confirm the update\!) every time you change the IAM role you’re using. To avoid these frustrating trade-offs, you can configure Terragrunt to assume an IAM role for you, as described next. @@ -49,4 +49,4 @@ iam_role = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME" Terragrunt will resolve the value of the option by first looking for the cli argument, then looking for the environment variable, then defaulting to the value specified in the config file. -Terragrunt will call the `sts assume-role` API on your behalf and expose the credentials it gets back as environment variables when running Terraform. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext, you get fresh credentials on every run of Terragrunt, without the complexity of calling `assume-role` yourself, and you don’t have to modify your Terraform code or backend configuration at all. +Terragrunt will call the `sts assume-role` API on your behalf and expose the credentials it gets back as environment variables when running OpenTofu/Terraform. The advantage of this approach is that you can store your AWS credentials in a secret store and never write them to disk in plaintext, you get fresh credentials on every run of Terragrunt, without the complexity of calling `assume-role` yourself, and you don’t have to modify your OpenTofu/Terraform code or backend configuration at all. diff --git a/docs/_docs/04_reference/built-in-functions.md b/docs/_docs/04_reference/built-in-functions.md index 50ace745d..73dd43d8f 100644 --- a/docs/_docs/04_reference/built-in-functions.md +++ b/docs/_docs/04_reference/built-in-functions.md @@ -3,16 +3,16 @@ layout: collection-browser-doc title: Built-in functions category: reference categories_url: reference -excerpt: Terragrunt allows you to use built-in functions anywhere in `terragrunt.hcl`, just like Terraform. +excerpt: Terragrunt allows you to use built-in functions anywhere in `terragrunt.hcl`, just like OpenTofu/Terraform. tags: ["functions"] order: 402 nav_title: Documentation nav_title_link: /docs/ --- -Terragrunt allows you to use built-in functions anywhere in `terragrunt.hcl`, just like Terraform\! The functions currently available are: +Terragrunt allows you to use built-in functions anywhere in `terragrunt.hcl`, just like OpenTofu/Terraform\! The functions currently available are: -- [Terraform built-in functions](#terraform-built-in-functions) +- [OpenTofu/Terraform built-in functions](#opentofuterraform-built-in-functions) - [find\_in\_parent\_folders](#find_in_parent_folders) - [path\_relative\_to\_include](#path_relative_to_include) - [path\_relative\_from\_include](#path_relative_from_include) @@ -41,9 +41,9 @@ Terragrunt allows you to use built-in functions anywhere in `terragrunt.hcl`, ju - [get\_terragrunt\_source\_cli\_flag](#get_terragrunt_source_cli_flag) - [read\_tfvars\_file](#read_tfvars_file) -## Terraform built-in functions +## OpenTofu/Terraform built-in functions -All [Terraform built-in functions](https://www.terraform.io/docs/configuration/functions.html) are supported in Terragrunt config files: +All [OpenTofu/Terraform built-in functions](https://opentofu.org/docs/language/functions/) are supported in Terragrunt config files: ```hcl terraform { @@ -53,9 +53,9 @@ terraform { remote_state { backend = "s3" config = { - bucket = trimspace(" my-terraform-bucket ") + bucket = trimspace(" my-tofu-bucket ") region = join("-", ["us", "east", "1"]) - key = format("%s/terraform.tfstate", path_relative_to_include()) + key = format("%s/tofu.tfstate", path_relative_to_include()) } } ``` @@ -161,14 +161,14 @@ The root `terragrunt.hcl` can use the `path_relative_to_include()` in its `remot remote_state { backend = "s3" config = { - bucket = "my-terraform-bucket" + bucket = "my-tofu-bucket" region = "us-east-1" - key = "${path_relative_to_include()}/terraform.tfstate" + key = "${path_relative_to_include()}/tofu.tfstate" } } ``` -The resulting `key` will be `prod/mysql/terraform.tfstate` for the prod `mysql` module and `stage/mysql/terraform.tfstate` for the stage `mysql` module. +The resulting `key` will be `prod/mysql/tofu.tfstate` for the prod `mysql` module and `stage/mysql/tofu.tfstate` for the stage `mysql` module. If you have `include` blocks, this function requires a `name` parameter when used in the child config to specify which `include` block to base the relative path on. @@ -217,7 +217,7 @@ include "root" { } ``` -The root `terragrunt.hcl` can use the `path_relative_from_include()` in combination with `path_relative_to_include()` in its `source` configuration to retrieve the relative terraform source code from the terragrunt configuration file: +The root `terragrunt.hcl` can use the `path_relative_from_include()` in combination with `path_relative_to_include()` in its `source` configuration to retrieve the relative OpenTofu/Terraform source code from the terragrunt configuration file: ```hcl terraform { @@ -286,12 +286,12 @@ remote_state { remote_state { backend = "s3" config = { - bucket = get_env("BUCKET", "my-terraform-bucket") + bucket = get_env("BUCKET", "my-tofu-bucket") } } ``` -Note that [Terraform will read environment variables](https://www.terraform.io/docs/configuration/environment-variables.html#tf_var_name) that start with the prefix `TF_VAR_`, so one way to share a variable named `foo` between Terraform and Terragrunt is to set its value as the environment variable `TF_VAR_foo` and to read that value in using this `get_env()` built-in function. +Note that [OpenTofu/Terraform will read environment variables](https://opentofu.org/docs/cli/config/environment-variables/#tf_var_name) that start with the prefix `TF_VAR_`, so one way to share a variable named `foo` between OpenTofu/Terraform and Terragrunt is to set its value as the environment variable `TF_VAR_foo` and to read that value in using this `get_env()` built-in function. ## get_platform @@ -339,11 +339,11 @@ remote_state { backend = "s3" config = { - bucket = "terraform" - dynamodb_table = "terraform" + bucket = "tofu" + dynamodb_table = "tofu" encrypt = true - key = "${get_path_from_repo_root()}/terraform.tfstate" - session_name = "terraform" + key = "${get_path_from_repo_root()}/tofu.tfstate" + session_name = "tofu" region = "us-east-1" } } @@ -365,7 +365,7 @@ This function will error if the file is not located in a Git repository. ## get_terragrunt_dir -`get_terragrunt_dir()` returns the directory where the Terragrunt configuration file (by default `terragrunt.hcl`) lives. This is useful when you need to use relative paths with [remote Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations) and you want those paths relative to your Terragrunt configuration file and not relative to the temporary directory where Terragrunt downloads the code. +`get_terragrunt_dir()` returns the directory where the Terragrunt configuration file (by default `terragrunt.hcl`) lives. This is useful when you need to use relative paths with [remote OpenTofu/Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-opentofu-terraform-configurations) and you want those paths relative to your Terragrunt configuration file and not relative to the temporary directory where Terragrunt downloads the code. For example, imagine you have the following file structure: @@ -375,7 +375,7 @@ For example, imagine you have the following file structure: │ └── terragrunt.hcl ``` -Inside of `/terraform-code/frontend-app/terragrunt.hcl` you might try to write code that looks like this: +Inside of `/tofu-code/frontend-app/terragrunt.hcl` you might try to write code that looks like this: ```hcl terraform { @@ -397,7 +397,7 @@ terraform { } ``` -Note how the `source` parameter is set, so Terragrunt will download the `frontend-app` code from the `modules` repo into a temporary folder and run `terraform` in that temporary folder. Note also that there is an `extra_arguments` block that is trying to allow the `frontend-app` to read some shared variables from a `common.tfvars` file. Unfortunately, the relative path (`../common.tfvars`) won’t work, as it will be relative to the temporary folder\! Moreover, you can’t use an absolute path, or the code won’t work on any of your teammates' computers. +Note how the `source` parameter is set, so Terragrunt will download the `frontend-app` code from the `modules` repo into a temporary folder and run `tofu`/`terraform` in that temporary folder. Note also that there is an `extra_arguments` block that is trying to allow the `frontend-app` to read some shared variables from a `common.tfvars` file. Unfortunately, the relative path (`../common.tfvars`) won’t work, as it will be relative to the temporary folder\! Moreover, you can’t use an absolute path, or the code won’t work on any of your teammates' computers. To make the relative path work, you need to use `get_terragrunt_dir()` to combine the path with the folder where the `terragrunt.hcl` file lives: @@ -424,11 +424,11 @@ terraform { ## get_working_dir -`get_working_dir()` returns the absolute path where Terragrunt runs Terraform commands. This is useful when you need to manage substitutions of vars inside a \*.tfvars file located right inside terragrunt's tmp dir. +`get_working_dir()` returns the absolute path where Terragrunt runs OpenTofu/Terraform commands. This is useful when you need to manage substitutions of vars inside a \*.tfvars file located right inside terragrunt's tmp dir. ## get_parent_terragrunt_dir -`get_parent_terragrunt_dir()` returns the absolute directory where the Terragrunt parent configuration file (by default `terragrunt.hcl`) lives. This is useful when you need to use relative paths with [remote Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations) and you want those paths relative to your parent Terragrunt configuration file and not relative to the temporary directory where Terragrunt downloads the code. +`get_parent_terragrunt_dir()` returns the absolute directory where the Terragrunt parent configuration file (by default `terragrunt.hcl`) lives. This is useful when you need to use relative paths with [remote OpenTofu/Terraform configurations]({{site.baseurl}}/docs/features/keep-your-terraform-code-dry/#remote-opentofu-terraform-configurations) and you want those paths relative to your parent Terragrunt configuration file and not relative to the temporary directory where Terragrunt downloads the code. This function is very similar to [get_terragrunt_dir()](#get_terragrunt_dir) except it returns the root instead of the leaf of your terragrunt configuration folder. @@ -462,7 +462,7 @@ terraform { } ``` -The common.tfvars located in the terraform root folder will be included by all applications, whatever their relative location to the root. +The common.tfvars located in the root folder will be included by all applications, whatever their relative location to the root. If you have `include` blocks, this function requires a `name` parameter when used in the child config to specify which `include` block to base the parent dir on. @@ -486,12 +486,12 @@ terraform { `get_original_terragrunt_dir()` returns the directory where the original Terragrunt configuration file (by default `terragrunt.hcl`) lives. This is primarily useful when one Terragrunt config is being read from another: e.g., if -`/terraform-code/terragrunt.hcl` calls `read_terragrunt_config("/foo/bar.hcl")`, and within `bar.hcl`, you call -`get_original_terragrunt_dir()`, you'll get back `/terraform-code`. +`/tofu-code/terragrunt.hcl` calls `read_terragrunt_config("/foo/bar.hcl")`, and within `bar.hcl`, you call +`get_original_terragrunt_dir()`, you'll get back `/tofu-code`. ## get_terraform_commands_that_need_vars -`get_terraform_commands_that_need_vars()` returns the list of terraform commands that accept `-var` and `-var-file` parameters. This function is used when defining [extra_arguments]({{site.baseurl}}/docs/features/keep-your-cli-flags-dry/#multiple-extra_arguments-blocks). +`get_terraform_commands_that_need_vars()` returns the list of OpenTofu/Terraform commands that accept `-var` and `-var-file` parameters. This function is used when defining [extra_arguments]({{site.baseurl}}/docs/features/keep-your-cli-flags-dry/#multiple-extra_arguments-blocks). ```hcl terraform { @@ -504,11 +504,11 @@ terraform { ## get_terraform_commands_that_need_input -`get_terraform_commands_that_need_input()` returns the list of terraform commands that accept the `-input=(true or false)` parameter. This function is used when defining [extra_arguments]({{site.baseurl}}/docs/features/keep-your-cli-flags-dry/#multiple-extra_arguments-blocks). +`get_terraform_commands_that_need_input()` returns the list of OpenTofu/Terraform commands that accept the `-input=(true or false)` parameter. This function is used when defining [extra_arguments]({{site.baseurl}}/docs/features/keep-your-cli-flags-dry/#multiple-extra_arguments-blocks). ```hcl terraform { - # Force Terraform to not ask for input value if some variables are undefined. + # Force OpenTofu/Terraform to not ask for input value if some variables are undefined. extra_arguments "disable_input" { commands = get_terraform_commands_that_need_input() arguments = ["-input=false"] @@ -522,7 +522,7 @@ terraform { ```hcl terraform { - # Force Terraform to keep trying to acquire a lock for up to 20 minutes if someone else already has the lock + # Force OpenTofu/Terraform to keep trying to acquire a lock for up to 20 minutes if someone else already has the lock extra_arguments "retry_lock" { commands = get_terraform_commands_that_need_locking() arguments = ["-lock-timeout=20m"] @@ -536,7 +536,7 @@ terraform { ```hcl terraform { - # Force Terraform to run with reduced parallelism + # Force OpenTofu/Terraform to run with reduced parallelism extra_arguments "parallelism" { commands = get_terraform_commands_that_need_parallelism() arguments = ["-parallelism=5"] @@ -646,7 +646,7 @@ If the command you are running has the potential to output sensitive values, you super_secret_value = run_cmd("--terragrunt-quiet", "./decrypt_secret.sh", "foo") ``` -**Note:** This will prevent terragrunt from displaying the output from the command in its output. However, the value could still be displayed in the Terraform output if Terraform does not treat it as a [sensitive value](https://www.terraform.io/docs/configuration/outputs.html#sensitive-suppressing-values-in-cli-output). +**Note:** This will prevent terragrunt from displaying the output from the command in its output. However, the value could still be displayed in the OpenTofu/Terraform output if OpenTofu/Terraform does not treat it as a [sensitive value](https://www.terraform.io/docs/configuration/outputs.html#sensitive-suppressing-values-in-cli-output). Invocations of `run_cmd` are cached based on directory and executed command, so cached values are re-used later, rather than executed multiple times. Here's an example: @@ -791,7 +791,7 @@ inputs = merge( ) ``` -If you absolutely need to fallback to a default value you can make use of the Terraform `try` function: +If you absolutely need to fallback to a default value you can make use of the OpenTofu/Terraform `try` function: ```hcl locals { diff --git a/docs/_docs/04_reference/cli-options.md b/docs/_docs/04_reference/cli-options.md index 22623b323..7f00e972c 100644 --- a/docs/_docs/04_reference/cli-options.md +++ b/docs/_docs/04_reference/cli-options.md @@ -14,7 +14,7 @@ nav_title_link: /docs/ This page documents the CLI commands and options available with Terragrunt: - [CLI commands](#cli-commands) - - [All Terraform built-in commands](#all-terraform-built-in-commands) + - [All OpenTofu/Terraform built-in commands](#all-opentofuterraform-built-in-commands) - [run-all](#run-all) - [plan-all (DEPRECATED: use run-all)](#plan-all-deprecated-use-run-all) - [apply-all (DEPRECATED: use run-all)](#apply-all-deprecated-use-run-all) @@ -90,7 +90,7 @@ This page documents the CLI commands and options available with Terragrunt: Terragrunt supports the following CLI commands: -- [All Terraform built-in commands](#all-terraform-built-in-commands) +- [All OpenTofu/Terraform built-in commands](#all-opentofuterraform-built-in-commands) - [run-all](#run-all) - [plan-all (DEPRECATED: use run-all)](#plan-all-deprecated-use-run-all) - [apply-all (DEPRECATED: use run-all)](#apply-all-deprecated-use-run-all) @@ -109,11 +109,11 @@ Terragrunt supports the following CLI commands: - [catalog](#catalog) - [graph](#graph) -### All Terraform built-in commands +### All OpenTofu/Terraform built-in commands -Terragrunt is a thin wrapper for Terraform, so except for a few of the special commands defined in these docs, -Terragrunt forwards all other commands to Terraform. For example, when you run `terragrunt apply`, Terragrunt executes -`terraform apply`. +Terragrunt is an orchestration tool for OpenTofu/Terraform, so except for a few of the special commands defined in these docs, +Terragrunt forwards all other commands to OpenTofu/Terraform. For example, when you run `terragrunt apply`, Terragrunt executes +`tofu apply`/`terraform apply`. Examples: @@ -129,13 +129,13 @@ Run `terraform --help` to get the full list. ### run-all -Runs the provided terraform command against a `stack`, where a `stack` is a +Runs the provided OpenTofu/Terraform command against a `stack`, where a `stack` is a tree of terragrunt modules. The command will recursively find terragrunt -modules in the current directory tree and run the terraform command in +modules in the current directory tree and run the OpenTofu/Terraform command in dependency order (unless the command is destroy, in which case the command is run in reverse dependency order). -Make sure to read [Execute Terraform +Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -157,14 +157,14 @@ or `terraform_remote_state` data sources! Please [see here for more information](https://github.com/gruntwork-io/terragrunt/issues/720#issuecomment-497888756). **[NOTE]** Using `run-all` with `apply` or `destroy` silently adds the `-auto-approve` flag to the command line -arguments passed to Terraform due to issues with shared `stdin` making individual approvals impossible. Please +arguments passed to OpenTofu/Terraform due to issues with shared `stdin` making individual approvals impossible. Please [see here for more information](https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment-358306268) ### plan-all (DEPRECATED: use run-all) **DEPRECATED: Use `run-all plan` instead.** -Display the plans of a `stack` by running `terragrunt plan` in each subfolder. Make sure to read [Execute Terraform +Display the plans of a `stack` by running `terragrunt plan` in each subfolder. Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -189,7 +189,7 @@ information](https://github.com/gruntwork-io/terragrunt/issues/720#issuecomment- **DEPRECATED: Use `run-all apply` instead.** -Apply a `stack` by running `terragrunt apply` in each subfolder. Make sure to read [Execute Terraform +Apply a `stack` by running `terragrunt apply` in each subfolder. Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -204,7 +204,7 @@ This will recursively search the current working directory for any folders that [`dependency`](/docs/reference/config-blocks-and-attributes/#dependency) and [`dependencies`](/docs/reference/config-blocks-and-attributes/#dependencies) blocks. -**[NOTE]** Using `apply-all` silently adds the `-auto-approve` flag to the command line arguments passed to Terraform +**[NOTE]** Using `apply-all` silently adds the `-auto-approve` flag to the command line arguments passed to OpenTofu/Terraform due to issues with shared `stdin` making individual approvals impossible. Please [see here for more information](https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment-358306268) @@ -212,7 +212,7 @@ information](https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment- **DEPRECATED: Use `run-all output` instead.** -Display the outputs of a `stack` by running `terragrunt output` in each subfolder. Make sure to read [Execute Terraform +Display the outputs of a `stack` by running `terragrunt output` in each subfolder. Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -237,7 +237,7 @@ information](https://github.com/gruntwork-io/terragrunt/issues/720#issuecomment- **DEPRECATED: Use `run-all destroy` instead.** -Destroy a `stack` by running `terragrunt destroy` in each subfolder. Make sure to read [Execute Terraform +Destroy a `stack` by running `terragrunt destroy` in each subfolder. Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -252,7 +252,7 @@ This will recursively search the current working directory for any folders that [`dependency`](/docs/reference/config-blocks-and-attributes/#dependency) and [`dependencies`](/docs/reference/config-blocks-and-attributes/#dependencies) blocks. -**[NOTE]** Using `destroy-all` silently adds the `-auto-approve` flag to the command line arguments passed to Terraform +**[NOTE]** Using `destroy-all` silently adds the `-auto-approve` flag to the command line arguments passed to OpenTofu/Terraform due to issues with shared `stdin` making individual approvals impossible. Please [see here for more information](https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment-358306268) @@ -260,7 +260,7 @@ information](https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment- **DEPRECATED: Use `run-all validate` instead.** -Validate `stack` by running `terragrunt validate` in each subfolder. Make sure to read [Execute Terraform +Validate `stack` by running `terragrunt validate` in each subfolder. Make sure to read [Execute OpenTofu/Terraform commands on multiple modules at once](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/) for context. @@ -302,8 +302,8 @@ Might produce output such as: Emits information about the input variables that are configured with the given terragrunt configuration. Specifically, this command will print out unused -inputs (inputs that are not defined as a terraform variable in the -corresponding module) and undefined required inputs (required terraform +inputs (inputs that are not defined as an OpenTofu/Terraform variable in the +corresponding module) and undefined required inputs (required OpenTofu/Terraform variables that are not currently being passed in). Example: @@ -338,12 +338,12 @@ Note that this only checks for variables passed in in the following ways: - `TF_VAR` environment variables defined in the environment. -Be aware that other ways to pass variables to `terraform` are not checked by this command. +Be aware that other ways to pass variables to `tofu`/`terraform` are not checked by this command. Additionally, there are **two modes** in which the `validate-inputs` command can be run: **relaxed** (default) and **strict**. If you run the `validate-inputs` command without flags, relaxed mode will be enabled by default. In relaxed mode, any unused variables -that are passed, but not used by the underlying Terraform configuration, will generate a warning, but not an error. Missing required variables will _always_ return an error, whether `validate-inputs` is running in relaxed or strict mode. +that are passed, but not used by the underlying OpenTofu/Terraform configuration, will generate a warning, but not an error. Missing required variables will _always_ return an error, whether `validate-inputs` is running in relaxed or strict mode. To enable strict mode, you can pass the `--terragrunt-strict-validate` flag like so: @@ -409,7 +409,7 @@ terragrunt hclfmt ``` This will recursively search the current working directory for any folders that contain Terragrunt configuration files -and run the equivalent of `terraform fmt` on them. +and run the equivalent of `tofu fmt`/`terraform fmt` on them. ### hclvalidate @@ -422,7 +422,7 @@ terragrunt hclvalidate ``` This will search all hcl files from the configuration stack in the current working directory and run the equivalent -of `terraform validate` on them. +of `tofu validate`/`terraform validate` on them. For convenience in programmatically parsing these findings, you can also pass the `--terragrunt-hclvalidate-json` flag to output the results in JSON format. @@ -442,9 +442,9 @@ terragrunt hclvalidate --terragrunt-hclvalidate-show-config-path ### aws-provider-patch -Overwrite settings on nested AWS providers to work around several Terraform bugs. Due to +Overwrite settings on nested AWS providers to work around several OpenTofu/Terraform bugs. Due to [issue #13018](https://github.com/hashicorp/terraform/issues/13018) and -[issue #26211](https://github.com/hashicorp/terraform/issues/26211), the `import` command may fail if your Terraform +[issue #26211](https://github.com/hashicorp/terraform/issues/26211), the `import` command may fail if your OpenTofu/Terraform code uses a module that has a `provider` block nested within it that sets any of its attributes to computed values. This command is a hacky attempt at working around this problem by allowing you to temporarily hard-code those attributes so `import` can work. @@ -467,7 +467,7 @@ provider "aws" { } ``` -Both the `region` and `role_arn` parameters are set to dynamic values, which will trigger those Terraform bugs. To work +Both the `region` and `role_arn` parameters are set to dynamic values, which will trigger those OpenTofu/Terraform bugs. To work around it, run the following command: ```bash @@ -481,8 +481,8 @@ terragrunt aws-provider-patch \ When you run the command above, Terragrunt will: -1. Run `terraform init` to download the code for all your modules into `.terraform/modules`. -1. Scan all the Terraform code in `.terraform/modules`, find AWS `provider` blocks, and for each one, hard-code: +1. Run `tofu init`/`terraform init` to download the code for all your modules into `.terraform/modules`. +1. Scan all the OpenTofu/Terraform code in `.terraform/modules`, find AWS `provider` blocks, and for each one, hard-code: 1. The `region` param to `"eu-west-1"`. 1. The `role_arn` within the `assume_role` block to `""`. 1. The `allowed_account_ids` param to `["0000000"]`. @@ -499,7 +499,7 @@ provider "aws" { } ``` -This should allow you to run `import` on the module and work around those Terraform bugs. When you're done running +This should allow you to run `import` on the module and work around those OpenTofu/Terraform bugs. When you're done running `import`, remember to delete your overridden code! E.g., Delete the `.terraform` or `.terragrunt-cache` folders. ### render-json @@ -596,7 +596,7 @@ This may produce output such as: ### scaffold -Generate Terragrunt files from existing Terraform modules. +Generate Terragrunt files from existing OpenTofu/Terraform modules. More details in [scaffold section](https://terragrunt.gruntwork.io/docs/features/scaffold/). @@ -608,7 +608,7 @@ More details in [catalog section](https://terragrunt.gruntwork.io/docs/features/ ### graph -Run the provided terraform command against the graph of dependencies for the module in the current working directory. The graph consists of all modules that depend on the module in the current working directory via a `depends_on` or `dependencies` block, plus all the modules that depend on those modules, and all the modules that depend on those modules, and so on, recursively up the tree, up to the Git repository root, or the path specified via the optional `--graph-root` argument. +Run the provided OpenTofu/Terraform command against the graph of dependencies for the module in the current working directory. The graph consists of all modules that depend on the module in the current working directory via a `depends_on` or `dependencies` block, plus all the modules that depend on those modules, and all the modules that depend on those modules, and so on, recursively up the tree, up to the Git repository root, or the path specified via the optional `--graph-root` argument. The Command will be executed following the order of dependencies: so it'll run on the module in the current working directory first, then on modules that depend on it directly, then on the modules that depend on those modules, and so on. Note that if the command is `destroy`, it will execute in the opposite order of the dependencies. @@ -711,11 +711,11 @@ Notes: ## CLI options -Terragrunt forwards all options to Terraform. The only exceptions are `--version` and arguments that start with the +Terragrunt forwards all options to OpenTofu/Terraform. The only exceptions are `--version` and arguments that start with the prefix `--terragrunt-` (e.g., `--terragrunt-config`). The currently available options are: - [CLI commands](#cli-commands) - - [All Terraform built-in commands](#all-terraform-built-in-commands) + - [All OpenTofu/Terraform built-in commands](#all-opentofuterraform-built-in-commands) - [run-all](#run-all) - [plan-all (DEPRECATED: use run-all)](#plan-all-deprecated-use-run-all) - [apply-all (DEPRECATED: use run-all)](#apply-all-deprecated-use-run-all) @@ -805,7 +805,7 @@ explanation). This argument is not used with the `run-all` commands. **Environment Variable**: `TERRAGRUNT_TFPATH`
**Requires an argument**: `--terragrunt-tfpath /path/to/terraform-binary`
-A custom path to the Terraform binary. The default is `tofu` in a directory on your PATH. +A custom path to the OpenTofu/Terraform binary. The default is `tofu` in a directory on your PATH. **NOTE**: This will override the `terraform` binary that is used by `terragrunt` in all instances, including `dependency` lookups. This setting will also override any [terraform_binary]({{site.baseurl}}/docs/reference/config-blocks-and-attributes/#terraform_binary) @@ -832,7 +832,7 @@ _(Prior to Terragrunt v0.48.6, this environment variable was called `TERRAGRUNT_ - [run-all](#run-all) -When passed in, Terragrunt will no longer automatically append `-auto-approve` to the underlying Terraform commands run +When passed in, Terragrunt will no longer automatically append `-auto-approve` to the underlying OpenTofu/Terraform commands run with `run-all`. Note that due to the interactive prompts, this flag will also **automatically assume `--terragrunt-parallelism 1`**. @@ -849,7 +849,7 @@ When passed in, don't automatically retry commands which fail with transient err **CLI Arg**: `--terragrunt-non-interactive`
**Environment Variable**: `TERRAGRUNT_NON_INTERACTIVE` (set to `true`)
-_(Prior to Terragrunt v0.48.6, this environment variable was called `TF_INPUT` (set to `false`), and is still available for backwards compatibility. NOTE: [TF_INPUT](https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_input) is native to Terraform!)_ +_(Prior to Terragrunt v0.48.6, this environment variable was called `TF_INPUT` (set to `false`), and is still available for backwards compatibility. NOTE: [TF_INPUT](https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_input) is native to OpenTofu/Terraform!)_ When passed in, don't show interactive user prompts. This will default the answer for all Terragrunt (not OpenTofu/Terraform) prompts to `yes` except for the listed cases below. This is useful if you need to run Terragrunt in an automated setting (e.g. from a script). May @@ -878,7 +878,7 @@ Is how you would make Terragrunt apply without any user prompts from Terragrunt Set the directory where Terragrunt should execute the `terraform` command. Default is the current working directory. Note that for the `run-all` commands, this parameter has a different meaning: Terragrunt will apply or destroy all the -Terraform modules in the subfolders of the `terragrunt-working-dir`, running `terraform` in the root of each module it +OpenTofu/Terraform modules in the subfolders of the `terragrunt-working-dir`, running `terraform` in the root of each module it finds. ### terragrunt-download-dir @@ -887,7 +887,7 @@ finds. **Environment Variable**: `TERRAGRUNT_DOWNLOAD`
**Requires an argument**: `--terragrunt-download-dir /path/to/dir-to-download-terraform-code`
-The path where to download Terraform code when using [remote Terraform +The path where to download OpenTofu/Terraform code when using [remote OpenTofu/Terraform configurations](https://blog.gruntwork.io/terragrunt-how-to-keep-your-terraform-code-dry-and-maintainable-f61ae06959d8). Default is `.terragrunt-cache` in the working directory. We recommend adding this folder to your `.gitignore`. @@ -897,10 +897,10 @@ Default is `.terragrunt-cache` in the working directory. We recommend adding thi **Environment Variable**: `TERRAGRUNT_SOURCE`
**Requires an argument**: `--terragrunt-source /path/to/local-terraform-code`
-Download Terraform configurations from the specified source into a temporary folder, and run Terraform in that temporary -folder. The source should use the same syntax as the [Terraform module +Download OpenTofu/Terraform configurations from the specified source into a temporary folder, and run OpenTofu/Terraform in that temporary +folder. The source should use the same syntax as the [OpenTofu/Terraform module source](https://www.terraform.io/docs/modules/sources.html) parameter. If you specify this argument for the `run-all` -commands, Terragrunt will assume this is the local file path for all of your Terraform modules, and for each module +commands, Terragrunt will assume this is the local file path for all of your OpenTofu/Terraform modules, and for each module processed by the `run-all` command, Terragrunt will automatically append the path of `source` parameter in each module to the `--terragrunt-source` parameter you passed in. @@ -937,7 +937,7 @@ Note that this only performs literal matches on the URL portion. For example, a **CLI Arg**: `--terragrunt-source-update`
**Environment Variable**: `TERRAGRUNT_SOURCE_UPDATE` (set to `true`)
-When passed in, delete the contents of the temporary folder before downloading Terraform source code into it. +When passed in, delete the contents of the temporary folder before downloading OpenTofu/Terraform source code into it. ### terragrunt-ignore-dependency-errors @@ -951,8 +951,8 @@ When passed in, the `*-all` commands continue processing components even if a de **Environment Variable**: `TERRAGRUNT_IAM_ROLE`
**Requires an argument**: `--terragrunt-iam-role "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"`
-Assume the specified IAM role ARN before running Terraform or AWS commands. This is a convenient way to use Terragrunt -and Terraform with multiple AWS accounts. +Assume the specified IAM role ARN before running OpenTofu/Terraform or AWS commands. This is a convenient way to use Terragrunt +and OpenTofu/Terraform with multiple AWS accounts. ### terragrunt-iam-assume-role-duration @@ -1022,7 +1022,7 @@ any modules during the execution of the commands. **CLI Arg**: `--terragrunt-strict-validate`
-When passed in, and running `terragrunt validate-inputs`, enables strict mode for the `validate-inputs` command. When strict mode is enabled, an error will be returned if any variables required by the underlying Terraform configuration are not passed in, OR if any unused variables are passed in. By default, `terragrunt validate-inputs` runs in relaxed mode. In relaxed mode, an error is only returned when a variable required by the underlying Terraform configuration is not passed in. +When passed in, and running `terragrunt validate-inputs`, enables strict mode for the `validate-inputs` command. When strict mode is enabled, an error will be returned if any variables required by the underlying OpenTofu/Terraform configuration are not passed in, OR if any unused variables are passed in. By default, `terragrunt validate-inputs` runs in relaxed mode. In relaxed mode, an error is only returned when a variable required by the underlying OpenTofu/Terraform configuration is not passed in. ### terragrunt-ignore-dependency-order @@ -1087,7 +1087,7 @@ When passed it, sets logging level for terragrunt. All supported levels are: If specified, Terragrunt output won't contain any color. -NOTE: This option does not disable Terraform output colors. Use the Terraform [`-no-color`](https://developer.hashicorp.com/terraform/cli/commands/plan#no-color) argument. +NOTE: This option does not disable OpenTofu/Terraform output colors. Use the OpenTofu/Terraform [`-no-color`](https://developer.hashicorp.com/terraform/cli/commands/plan#no-color) argument. ### terragrunt-check @@ -1273,7 +1273,7 @@ Once this flag has been tested thoroughly, we will consider making it the defaul **CLI Arg**: `--terragrunt-include-module-prefix`
**Environment Variable**: `TERRAGRUNT_INCLUDE_MODULE_PREFIX` (set to `true`)
-When this flag is set output from Terraform sub-commands is prefixed with module path. +When this flag is set output from OpenTofu/Terraform sub-commands is prefixed with module path. ### terragrunt-fail-on-state-bucket-creation @@ -1308,7 +1308,7 @@ When this flag is set, Terragrunt will output its logs in JSON format. **CLI Arg**: `--terragrunt-tf-logs-to-json`
**Environment Variable**: `TERRAGRUNT_TF_JSON_LOG` (set to `true`)
-When this flag is set, Terragrunt will wrap Terraform `stdout` and `stderr` in JSON log messages. Works only with `--terragrunt-json-log` flag. +When this flag is set, Terragrunt will wrap OpenTofu/Terraform `stdout` and `stderr` in JSON log messages. Works only with `--terragrunt-json-log` flag. ### terragrunt-provider-cache @@ -1318,7 +1318,7 @@ When this flag is set, Terragrunt will wrap Terraform `stdout` and `stderr` in J - [run-all](#run-all) -Enables Terragrunt's provider caching. This forces Terraform to make provider requests through the Terragrunt Provider Cache server. Make sure to read [Provider Caching](https://terragrunt.gruntwork.io/docs/features/provider-cache/) for context. +Enables Terragrunt's provider caching. This forces OpenTofu/Terraform to make provider requests through the Terragrunt Provider Cache server. Make sure to read [Provider Caching](https://terragrunt.gruntwork.io/docs/features/provider-cache/) for context. ### terragrunt-provider-cache-dir @@ -1328,7 +1328,7 @@ Enables Terragrunt's provider caching. This forces Terraform to make provider re - [run-all](#run-all) -The path to the Terragrunt provider cache directory. By default, `terragrunt/providers` folder in the user cache directory: `$HOME/.cache` on Unix systems, `$HOME/Library/Caches` on Darwin, `%LocalAppData%` on Windows. The file structure of the cache directory is identical to the Terraform [plugin_cache_dir](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-plugin-cache) directory. Make sure to read [Provider Caching](https://terragrunt.gruntwork.io/docs/features/provider-cache/) for context. +The path to the Terragrunt provider cache directory. By default, `terragrunt/providers` folder in the user cache directory: `$HOME/.cache` on Unix systems, `$HOME/Library/Caches` on Darwin, `%LocalAppData%` on Windows. The file structure of the cache directory is identical to the OpenTofu/Terraform [plugin_cache_dir](https://developer.hashicorp.com/terraform/cli/config/config-file#provider-plugin-cache) directory. Make sure to read [Provider Caching](https://terragrunt.gruntwork.io/docs/features/provider-cache/) for context. ### terragrunt-provider-cache-hostname diff --git a/docs/_docs/04_reference/config-blocks-and-attributes.md b/docs/_docs/04_reference/config-blocks-and-attributes.md index 43dc87f4c..28816ba56 100644 --- a/docs/_docs/04_reference/config-blocks-and-attributes.md +++ b/docs/_docs/04_reference/config-blocks-and-attributes.md @@ -11,7 +11,7 @@ nav_title: Documentation nav_title_link: /docs/ --- -The Terragrunt configuration file uses the same HCL syntax as Terraform itself in `terragrunt.hcl`. +The Terragrunt configuration file uses the same HCL syntax as OpenTofu/Terraform itself in `terragrunt.hcl`. Terragrunt also supports [JSON-serialized HCL](https://github.com/hashicorp/hcl/blob/hcl2/json/spec.md) in a `terragrunt.hcl.json` file: where `terragrunt.hcl` is mentioned you can always use `terragrunt.hcl.json` instead. @@ -56,19 +56,19 @@ The following is a reference of all the supported blocks and attributes in the c ### terraform -The `terraform` block is used to configure how Terragrunt will interact with Terraform. This includes specifying where -to find the Terraform configuration files, any extra arguments to pass to the `terraform` CLI, and any hooks to run -before or after calling Terraform. +The `terraform` block is used to configure how Terragrunt will interact with OpenTofu/Terraform. This includes specifying where +to find the OpenTofu/Terraform configuration files, any extra arguments to pass to the `tofu`/`terraform` binary, and any hooks to run +before or after calling OpenTofu/Terraform. The `terraform` block supports the following arguments: -- `source` (attribute): Specifies where to find Terraform configuration files. This parameter supports the exact same syntax as the - [module source](https://www.terraform.io/docs/modules/sources.html) parameter for Terraform `module` blocks **except +- `source` (attribute): Specifies where to find OpenTofu/Terraform configuration files. This parameter supports the exact same syntax as the + [module source](https://opentofu.org/docs/language/modules/sources/) parameter for OpenTofu/Terraform `module` blocks **except for the Terraform registry** (see below note), including local file paths, Git URLs, and Git URLS with `ref` parameters. Terragrunt will download all the code in the repo (i.e. the part before the double-slash `//`) so that relative paths work correctly between modules in that repo. - - The `source` parameter can be configured to pull Terraform modules from any Terraform module registry using + - The `source` parameter can be configured to pull OpenTofu/Terraform modules from any Terraform module registry using the `tfr` protocol. The `tfr` protocol expects URLs to be provided in the format `tfr://REGISTRY_HOST/MODULE_SOURCE?version=VERSION`. For example, to pull the `terraform-aws-modules/vpc/aws` module from the public Terraform registry, you can use the following as the source parameter: @@ -92,54 +92,54 @@ The `terraform` block supports the following arguments: information about using modules from the Terraform Registry with Terragrunt. - `include_in_copy` (attribute): A list of glob patterns (e.g., `["*.txt"]`) that should always be copied into the - Terraform working directory. When you use the `source` param in your Terragrunt config and run `terragrunt `, + OpenTofu/Terraform working directory. When you use the `source` param in your Terragrunt config and run `terragrunt `, Terragrunt will download the code specified at source into a scratch folder (`.terragrunt-cache`, by default), copy - the code in your current working directory into the same scratch folder, and then run `terraform ` in that + the code in your current working directory into the same scratch folder, and then run `tofu ` (or `terraform `) in that scratch folder. By default, Terragrunt excludes hidden files and folders during the copy step. This feature allows you to specify glob patterns of files that should always be copied from the Terragrunt working directory. Additional notes: - The path should be specified relative to the source directory. - This list is also used when using a local file source (e.g., `source = "../modules/vpc"`). For example, if your - terraform module source contains a hidden file that you want to copy over (e.g., a `.python-version` file), you + OpenTofu/Terraform module source contains a hidden file that you want to copy over (e.g., a `.python-version` file), you can specify that in this list to ensure it gets copied over to the scratch copy (e.g., `include_in_copy = [".python-version"]`). -- `extra_arguments` (block): Nested blocks used to specify extra CLI arguments to pass to the `terraform` CLI. Learn more +- `extra_arguments` (block): Nested blocks used to specify extra CLI arguments to pass to the `tofu`/`terraform` binary. Learn more about its usage in the [Keep your CLI flags DRY]({{site.baseurl}}/docs/features/keep-your-cli-flags-dry/) use case overview. Supports the following arguments: - - `arguments` (required) : A list of CLI arguments to pass to `terraform`. - - `commands` (required) : A list of `terraform` sub commands that the arguments will be passed to. - - `env_vars` (optional) : A map of key value pairs to set as environment variables when calling `terraform`. - - `required_var_files` (optional): A list of file paths to terraform vars files (`.tfvars`) that will be passed in to + - `arguments` (required) : A list of CLI arguments to pass to `tofu`/`terraform`. + - `commands` (required) : A list of `tofu`/`terraform` sub commands that the arguments will be passed to. + - `env_vars` (optional) : A map of key value pairs to set as environment variables when calling `tofu`/`terraform`. + - `required_var_files` (optional): A list of file paths to OpenTofu/Terraform vars files (`.tfvars`) that will be passed in to `terraform` as `-var-file=`. - - `optional_var_files` (optional): A list of file paths to terraform vars files (`.tfvars`) that will be passed in to - `terraform` like `required_var_files`, only any files that do not exist are ignored. + - `optional_var_files` (optional): A list of file paths to OpenTofu/Terraform vars files (`.tfvars`) that will be passed in to + `tofu`/`terraform` like `required_var_files`, only any files that do not exist are ignored. -- `before_hook` (block): Nested blocks used to specify command hooks that should be run before `terraform` is called. - Hooks run from the directory with the terraform module, except for hooks related to `terragrunt-read-config` and +- `before_hook` (block): Nested blocks used to specify command hooks that should be run before `tofu`/`terraform` is called. + Hooks run from the directory with the OpenTofu/Terraform module, except for hooks related to `terragrunt-read-config` and `init-from-module`. These hooks run in the terragrunt configuration directory (the directory where `terragrunt.hcl` lives). Supports the following arguments: - - `commands` (required) : A list of `terraform` sub commands for which the hook should run before. + - `commands` (required) : A list of `tofu`/`terraform` sub commands for which the hook should run before. - `execute` (required) : A list of command and arguments that should be run as the hook. For example, if `execute` is set as `["echo", "Foo"]`, the command `echo Foo` will be run. - `working_dir` (optional) : The path to set as the working directory of the hook. Terragrunt will switch directory to this path prior to running the hook command. Defaults to the terragrunt configuration directory for - `terragrunt-read-config` and `init-from-module` hooks, and the terraform module directory for other command hooks. + `terragrunt-read-config` and `init-from-module` hooks, and the OpenTofu/Terraform module directory for other command hooks. - `run_on_error` (optional) : If set to true, this hook will run even if a previous hook hit an error, or in the - case of "after" hooks, if the Terraform command hit an error. Default is false. - - `suppress_stdout` (optional) : If set to true, the stdout output of the executed commands will be suppressed. This can be useful when there are scripts relying on terraform's output and any other output would break their parsing. + case of "after" hooks, if the OpenTofu/Terraform command hit an error. Default is false. + - `suppress_stdout` (optional) : If set to true, the stdout output of the executed commands will be suppressed. This can be useful when there are scripts relying on OpenTofu/Terraform's output and any other output would break their parsing. -- `after_hook` (block): Nested blocks used to specify command hooks that should be run after `terraform` is called. +- `after_hook` (block): Nested blocks used to specify command hooks that should be run after `tofu`/`terraform` is called. Hooks run from the terragrunt configuration directory (the directory where `terragrunt.hcl` lives). Supports the same arguments as `before_hook`. - `error_hook` (block): Nested blocks used to specify command hooks that run when an error is thrown. The error must match one of the expressions listed in the `on_errors` attribute. Error hooks are executed after the before/after hooks. -In addition to supporting before and after hooks for all terraform commands, the following specialized hooks are also +In addition to supporting before and after hooks for all OpenTofu/Terraform commands, the following specialized hooks are also supported: - `terragrunt-read-config` (after hook only): `terragrunt-read-config` is a special hook command that you can use with @@ -153,25 +153,25 @@ supported: is [Auto-Init](https://terragrunt.gruntwork.io/docs/features/auto-init/), which configures the backend and downloads provider plugins and modules. If you wish to run a hook when Terragrunt is using `go-getter` to download remote configurations, use `init-from-module` for the command. If you wish to execute a hook when Terragrunt is using - terraform `init` for Auto-Init, use `init` for the command. For example, an `after_hook` for the command + `tofu init`/`terraform init` for Auto-Init, use `init` for the command. For example, an `after_hook` for the command `init-from-module` will run after terragrunt clones the module, while an `after_hook` for the command `init` will run - after terragrunt runs `terraform init` on the cloned module. + after terragrunt runs `tofu init`/`terraform init` on the cloned module. - Hooks for both `init-from-module` and `init` only run if the requisite stage needs to run. That is, if terragrunt detects that the module is already cloned in the terragrunt cache, this stage will be skipped and thus the hooks will not run. Similarly, if terragrunt detects that it does not need to run `init` in the auto init feature, the `init` stage is skipped along with the related hooks. - The working directory for hooks associated with `init-from-module` will run in the terragrunt config directory, - while the working directory for hooks associated with `init` will be the terraform module. + while the working directory for hooks associated with `init` will be the OpenTofu/Terraform module. Complete Example: ```hcl terraform { - # Pull the terraform configuration at the github repo "acme/infrastructure-modules", under the subdirectory + # Pull the OpenTofu/Terraform configuration at the github repo "acme/infrastructure-modules", under the subdirectory # "networking/vpc", using the git tag "v0.0.1". source = "git::git@github.com:acme/infrastructure-modules.git//networking/vpc?ref=v0.0.1" - # For any terraform commands that use locking, make sure to configure a lock timeout of 20 minutes. + # For any OpenTofu/Terraform commands that use locking, make sure to configure a lock timeout of 20 minutes. extra_arguments "retry_lock" { commands = get_terraform_commands_that_need_locking() arguments = ["-lock-timeout=20m"] @@ -254,7 +254,7 @@ Local File Path Example with allowed hidden files: ```hcl terraform { - # Pull the terraform configuration from the local file system. Terragrunt will make a copy of the source folder in the + # Pull the OpenTofu/Terraform configuration from the local file system. Terragrunt will make a copy of the source folder in the # Terragrunt working directory (typically `.terragrunt-cache`). source = "../modules/networking/vpc" @@ -269,34 +269,34 @@ terraform { #### A note about using modules from the registry The key design of Terragrunt is to act as a preprocessor to convert **shared service modules** in the registry into a **root -module**. In Terraform, modules can be loosely categorized into two types: +module**. In OpenTofu/Terraform, modules can be loosely categorized into two types: -- **Root Module**: A Terraform module that is designed for running `terraform init` and the other workflow commands +- **Root Module**: An OpenTofu/Terraform module that is designed for running `tofu init`/`terraform init` and the other workflow commands (`apply`, `plan`, etc). This is the entrypoint module for deploying your infrastructure. Root modules are identified - by the presence of key blocks that setup configuration about how Terraform behaves, like `backend` blocks (for - configuring state) and `provider` blocks (for configuring how Terraform interacts with the cloud APIs). -- **Shared Module**: A Terraform module that is designed to be included in other Terraform modules through `module` + by the presence of key blocks that setup configuration about how OpenTofu/Terraform behaves, like `backend` blocks (for + configuring state) and `provider` blocks (for configuring how OpenTofu/Terraform interacts with the cloud APIs). +- **Shared Module**: A OpenTofu/Terraform module that is designed to be included in other OpenTofu/Terraform modules through `module` blocks. These modules are missing many of the key blocks that are required for running the workflow commands of - terraform. + OpenTofu/Terraform. Terragrunt further distinguishes shared modules between **service modules** and **modules**: -- **Shared Service Module**: A Terraform module that is designed to be standalone and applied directly. These modules +- **Shared Service Module**: An OpenTofu/Terraform module that is designed to be standalone and applied directly. These modules are not root modules in that they are still missing the key blocks like `backend` and `provider`, but aside from that do not need any additional configuration or composition to deploy. For example, the [terraform-aws-modules/vpc](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest) module can be deployed by itself without composing with other modules or resources. -- **Shared Module**: A Terraform module that is designed to be composed with other modules. That is, these modules must - be embedded in another Terraform module and combined with other resources or modules. For example, the +- **Shared Module**: An OpenTofu/Terraform module that is designed to be composed with other modules. That is, these modules must + be embedded in another OpenTofu/Terraform module and combined with other resources or modules. For example, the [consul-security-group-rules module](https://registry.terraform.io/modules/hashicorp/consul/aws/latest/submodules/consul-security-group-rules) Terragrunt started off with features that help directly deploy **Root Modules**, but over the years have implemented many features that allow you to turn **Shared Service Modules** into **Root Modules** by injecting the key configuration -blocks that are necessary for Terraform modules to act as **Root Modules**. +blocks that are necessary for OpenTofu/Terraform modules to act as **Root Modules**. Modules on the Terraform Registry are primarily designed to be used as **Shared Modules**. That is, you won't be able to -`git clone` the underlying repository and run `terraform init` or `apply` directly on the module without modification. +`git clone` the underlying repository and run `tofu init`/`terraform init` or `apply` directly on the module without modification. Unless otherwise specified, almost all the modules will require composition with other modules/resources to deploy. When using modules in the registry, it helps to think about what blocks and resources are necessary to operate the module, and translating those into Terragrunt blocks that generate them. @@ -305,7 +305,7 @@ Note that in many cases, Terragrunt may not be able to deploy modules from the r to turn any **Shared Module** into a **Root Module**, there are two key technical limitations that prevent Terragrunt from converting ALL shared modules: -- Every complex input must have a `type` associated with it. Otherwise, Terraform will interpret the input that +- Every complex input must have a `type` associated with it. Otherwise, OpenTofu/Terraform will interpret the input that Terragrunt passes through as `string`. This includes `list` and `map`. - Derived sensitive outputs must be marked as `sensitive`. Refer to the [terraform tutorial on sensitive variables](https://learn.hashicorp.com/tutorials/terraform/sensitive-variables#reference-sensitive-variables) for more @@ -320,13 +320,13 @@ instead of the module repository.** ### remote_state The `remote_state` block is used to configure how Terragrunt will set up the remote state configuration of your -Terraform code. You can read more about Terragrunt's remote state functionality in [Keep your remote state configuration +OpenTofu/Terraform code. You can read more about Terragrunt's remote state functionality in [Keep your remote state configuration DRY](/docs/features/keep-your-remote-state-configuration-dry/) use case overview. The `remote_state` block supports the following arguments: - `backend` (attribute): Specifies which remote state backend will be configured. This should be one of the - [backend types](https://www.terraform.io/docs/backends/types/index.html) that Terraform supports. + [available backends](https://opentofu.org/docs/language/settings/backends/configuration/#available-backends) that Opentofu/Terraform supports. - `disable_init` (attribute): When `true`, skip automatic initialization of the backend by Terragrunt. Some backends have support in Terragrunt to be automatically created if the storage does not exist. Currently `s3` and `gcs` are the @@ -339,13 +339,13 @@ The `remote_state` block supports the following arguments: backend. This is a map that expects two properties: - `path`: The path where the generated file should be written. If a relative path, it'll be relative to the Terragrunt - working dir (where the terraform code lives). + working dir (where the OpenTofu/Terraform code lives). - `if_exists` (attribute): What to do if a file already exists at `path`. Valid values are: `overwrite` (overwrite the existing file), `overwrite_terragrunt` (overwrite the existing file if it was generated by terragrunt; otherwise, error) `skip` (skip code generation and leave the existing file as-is), `error` (exit with an error). -- `config` (attribute): An arbitrary map that is used to fill in the backend configuration in Terraform. All the - properties will automatically be included in the Terraform backend block (with a few exceptions: see below). For +- `config` (attribute): An arbitrary map that is used to fill in the backend configuration in OpenTofu/Terraform. All the + properties will automatically be included in the OpenTofu/Terraform backend block (with a few exceptions: see below). For example, if you had the following `remote_state` block: ```hcl @@ -359,7 +359,7 @@ The `remote_state` block supports the following arguments: } ``` - This is equivalent to the following `terraform` code: + This is equivalent to the following OpenTofu/Terraform code: ```hcl terraform { @@ -424,11 +424,11 @@ For the `s3` backend, the following additional properties are supported in the ` - `accesslogging_bucket_tags`: A map of key value pairs to associate as tags on the created S3 bucket to store de access logs. - `disable_aws_client_checksums`: When `true`, disable computing and checking checksums on the request and response, such as the CRC32 check for DynamoDB. See [#1059](https://github.com/gruntwork-io/terragrunt/issues/1059) for issue where this is a useful workaround. -- `accesslogging_bucket_name`: (Optional) When provided as a valid `string`, create an S3 bucket with this name to store the access logs for the S3 bucket used to store Terraform state. If not provided, or string is empty or invalid S3 bucket name, then server access logging for the S3 bucket storing the terraform state will be disabled. **Note:** When access logging is enabled supported encryption for state bucket is only `AES256`. Reference: [S3 server access logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) -- `accesslogging_target_prefix`: (Optional) When provided as a valid `string`, set the `TargetPrefix` for the access log objects in the S3 bucket used to store Terraform state. If set to **empty**`string`, then `TargetPrefix` will be set to **empty** `string`. If attribute is not provided at all, then `TargetPrefix` will be set to **default** value `TFStateLogs/`. This attribute won't take effect if the `accesslogging_bucket_name` attribute is not present. +- `accesslogging_bucket_name`: (Optional) When provided as a valid `string`, create an S3 bucket with this name to store the access logs for the S3 bucket used to store OpenTofu/Terraform state. If not provided, or string is empty or invalid S3 bucket name, then server access logging for the S3 bucket storing the Opentofu/Terraform state will be disabled. **Note:** When access logging is enabled supported encryption for state bucket is only `AES256`. Reference: [S3 server access logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) +- `accesslogging_target_prefix`: (Optional) When provided as a valid `string`, set the `TargetPrefix` for the access log objects in the S3 bucket used to store Opentofu/Terraform state. If set to **empty**`string`, then `TargetPrefix` will be set to **empty** `string`. If attribute is not provided at all, then `TargetPrefix` will be set to **default** value `TFStateLogs/`. This attribute won't take effect if the `accesslogging_bucket_name` attribute is not present. - `bucket_sse_algorithm`: (Optional) The algorithm to use for server side encryption of the state bucket. Defaults to `aws:kms`. - `bucket_sse_kms_key_id`: (Optional) The KMS Key to use when the encryption algorithm is `aws:kms`. Defaults to the AWS Managed `aws/s3` key. -- `assume_role`: (Optional) A configuration `map` to use when assuming a role (starting with Terraform 1.6). Override top level arguments +- `assume_role`: (Optional) A configuration `map` to use when assuming a role (starting with Terraform 1.6 for Terraform). Override top level arguments - `role_arn` - (Optional) The role to be assumed. - `external_id` - (Optional) The external ID to use when assuming the role. - `session_name` - (Optional) The session name to use when assuming the role. @@ -447,7 +447,7 @@ For the `gcs` backend, the following additional properties are supported in the Example with S3: ```hcl -# Configure terraform state to be stored in S3, in the bucket "my-terraform-state" in us-east-1 under a key that is +# Configure OpenTofu/Terraform state to be stored in S3, in the bucket "my-tofu-state" in us-east-1 under a key that is # relative to included terragrunt config. For example, if you had the following folder structure: # # . @@ -457,16 +457,16 @@ For the `gcs` backend, the following additional properties are supported in the # └── terragrunt.hcl # # And the following is defined in the root terragrunt.hcl config that is included in the child, the state file for the -# child module will be stored at the key "child/terraform.tfstate". +# child module will be stored at the key "child/tofu.tfstate". # # Note that since we are not using any of the skip args, this will automatically create the S3 bucket -# "my-terraform-state" and DynamoDB table "my-lock-table" if it does not already exist. +# "my-tofu-state" and DynamoDB table "my-lock-table" if it does not already exist. # terragrunt.hcl remote_state { backend = "s3" config = { - bucket = "my-terraform-state" - key = "${path_relative_to_include()}/terraform.tfstate" + bucket = "my-tofu-state" + key = "${path_relative_to_include()}/tofu.tfstate" region = "us-east-1" encrypt = true dynamodb_table = "my-lock-table" @@ -487,9 +487,9 @@ terraform { Example with GCS: ```hcl -# Configure terraform state to be stored in GCS, in the bucket "my-terraform-state" in the "my-terraform" GCP project in +# Configure OpenTofu/Terraform state to be stored in GCS, in the bucket "my-tofu-state" in the "my-tofu" GCP project in # the eu region under a key that is relative to included terragrunt config. This will also apply the labels -# "owner=terragrunt_test" and "name=terraform_state_storage" to the bucket if it is created by Terragrunt. +# "owner=terragrunt_test" and "name=tofu_state_storage" to the bucket if it is created by Terragrunt. # # For example, if you had the following folder structure: # @@ -500,24 +500,24 @@ Example with GCS: # └── terragrunt.hcl # # And the following is defined in the root terragrunt.hcl config that is included in the child, the state file for the -# child module will be stored at the key "child/terraform.tfstate". +# child module will be stored at the key "child/tofu.tfstate". # # Note that since we are not using any of the skip args, this will automatically create the GCS bucket -# "my-terraform-state" if it does not already exist. +# "my-tofu-state" if it does not already exist. # terragrunt.hcl remote_state { backend = "gcs" config = { - project = "my-terraform" + project = "my-tofu" location = "eu" - bucket = "my-terraform-state" - prefix = "${path_relative_to_include()}/terraform.tfstate" + bucket = "my-tofu-state" + prefix = "${path_relative_to_include()}/tofu.tfstate" gcs_bucket_labels = { owner = "terragrunt_test" - name = "terraform_state_storage" + name = "tofu_state_storage" } } } @@ -585,8 +585,8 @@ Examples: remote_state { backend = "s3" config = { - bucket = "my-terraform-state" - key = "${path_relative_to_include()}/terraform.tfstate" + bucket = "my-tofu-state" + key = "${path_relative_to_include()}/tofu.tfstate" region = "us-east-1" encrypt = true dynamodb_table = "my-lock-table" @@ -626,8 +626,8 @@ terraform { remote_state { backend = "s3" config = { - bucket = "my-terraform-state" - key = "${path_relative_to_include()}/terraform.tfstate" + bucket = "my-tofu-state" + key = "${path_relative_to_include()}/tofu.tfstate" region = "us-east-1" encrypt = true dynamodb_table = "my-lock-table" @@ -823,7 +823,7 @@ remote_state { config = { encrypt = true bucket = "__FILL_IN_BUCKET_NAME__" - key = "${path_relative_to_include()}/terraform.tfstate" + key = "${path_relative_to_include()}/tofu.tfstate" region = "us-west-2" } } @@ -964,7 +964,7 @@ The `dependency` block is used to configure module dependencies. Each dependency module as block attributes you can reference throughout the configuration. You can learn more about `dependency` blocks in the [Dependencies between modules section](/docs/features/execute-terraform-commands-on-multiple-modules-at-once/#dependencies-between-modules) of the -"Execute Terraform commands on multiple modules at once" use case overview. +"Execute Opentofu/Terraform commands on multiple modules at once" use case overview. You can define more than one `dependency` block. Each label you provide to the block identifies another `dependency` that you can reference in your config. @@ -1045,7 +1045,7 @@ but the outputs for `account` and `vpc` will be fetched serially as terragrunt n tree to retrieve the outputs at each level. This recursive parsing happens due to the necessity to parse the entire `terragrunt.hcl` configuration (including -`dependency` blocks) in full before being able to call `terraform output`. +`dependency` blocks) in full before being able to call `tofu output`/`terraform output`. However, terragrunt includes an optimization to only fetch the lowest level outputs (`securitygroup` and `ecr` in this example) provided that the following conditions are met in the immediate dependencies: @@ -1053,7 +1053,7 @@ example) provided that the following conditions are met in the immediate depende - The remote state is managed using `remote_state` blocks. - The dependency optimization feature flag is enabled (`disable_dependency_optimization = false`, which is the default). - The `remote_state` block itself does not depend on any `dependency` outputs (`locals` and `include` are ok). -- You are not relying on `before_hook`, `after_hook`, or `extra_arguments` to the `terraform init` call. NOTE: +- You are not relying on `before_hook`, `after_hook`, or `extra_arguments` to the `tofu init`/`terraform init` call. NOTE: terragrunt will not automatically detect this and you will need to explicitly opt out of the dependency optimization flag. @@ -1064,7 +1064,7 @@ state for the target module without parsing the `dependency` blocks, avoiding th The `dependencies` block is used to enumerate all the Terragrunt modules that need to be applied in order for this module to be able to apply. Note that this is purely for ordering the operations when using `run-all` commands of -Terraform. This does not expose or pull in the outputs like `dependency` blocks. +OpenTofu/Terraform. This does not expose or pull in the outputs like `dependency` blocks. The `dependencies` block supports the following arguments: @@ -1082,8 +1082,8 @@ dependencies { ### generate -The `generate` block can be used to arbitrarily generate a file in the terragrunt working directory (where `terraform` -is called). This can be used to generate common terraform configurations that are shared across multiple terraform +The `generate` block can be used to arbitrarily generate a file in the terragrunt working directory (where `tofu`/`terraform` +is called). This can be used to generate common OpenTofu/Terraform configurations that are shared across multiple OpenTofu/Terraform modules. For example, you can use `generate` to generate the provider blocks in a consistent fashion by defining a `generate` block in the parent terragrunt config. @@ -1092,7 +1092,7 @@ The `generate` block supports the following arguments: - `name` (label): You can define multiple `generate` blocks in a single terragrunt config. As such, each block needs a name to differentiate between the other blocks. - `path` (attribute): The path where the generated file should be written. If a relative path, it'll be relative to the - Terragrunt working dir (where the terraform code lives). + Terragrunt working dir (where the OpenTofu/Terraform code lives). - `if_exists` (attribute): What to do if a file already exists at `path`. Valid values are: `overwrite` (overwrite the existing file), `overwrite_terragrunt` (overwrite the existing file if it was generated by terragrunt; otherwise, error) `skip` (skip code generation and leave the existing file as-is), `error` (exit with an error). @@ -1109,7 +1109,7 @@ Example: ```hcl # When using this terragrunt config, terragrunt will generate the file "provider.tf" with the aws provider block before -# calling to terraform. Note that this will overwrite the `provider.tf` file if it already exists. +# calling to OpenTofu/Terraform. Note that this will overwrite the `provider.tf` file if it already exists. generate "provider" { path = "provider.tf" if_exists = "overwrite" @@ -1187,15 +1187,15 @@ More details in [engine section](https://terragrunt.gruntwork.io/docs/features/e ### inputs -The `inputs` attribute is a map that is used to specify the input variables and their values to pass in to Terraform. -Each entry of the map will be passed to Terraform using [the environment variable -mechanism](https://www.terraform.io/docs/configuration/variables.html#environment-variables). This means that each input +The `inputs` attribute is a map that is used to specify the input variables and their values to pass in to OpenTofu/Terraform. +Each entry of the map will be passed to OpenTofu/Terraform using [the environment variable +mechanism](https://opentofu.org/docs/language/values/variables/#environment-variables). This means that each input will be set using the form `TF_VAR_variablename`, with the value in `json` encoded format. Note that because the values are being passed in with environment variables and `json`, the type information is lost -when crossing the boundary between Terragrunt and Terraform. You must specify the proper [type -constraint](https://www.terraform.io/docs/configuration/variables.html#type-constraints) on the variable in Terraform in -order for Terraform to process the inputs to the right type. +when crossing the boundary between Terragrunt and OpenTofu/Terraform. You must specify the proper [type +constraint](https://opentofu.org/docs/language/values/variables/#type-constraints) on the variable in OpenTofu/Terraform in +order for OpenTofu/Terraform to process the inputs to the right type. Example: @@ -1249,7 +1249,7 @@ It supports all terragrunt functions, i.e. `path_relative_from_include()`. ### prevent_destroy -Terragrunt `prevent_destroy` boolean flag allows you to protect selected Terraform module. It will prevent `destroy` or +Terragrunt `prevent_destroy` boolean flag allows you to protect selected OpenTofu/Terraform module. It will prevent `destroy` or `destroy-all` command to actually destroy resources of the protected module. This is useful for modules you want to carefully protect, such as a database, or a module that provides auth. @@ -1282,7 +1282,7 @@ root └── terragrunt.hcl ``` -In some cases, the root level `terragrunt.hcl` file is solely used to DRY up your Terraform configuration by being +In some cases, the root level `terragrunt.hcl` file is solely used to DRY up your OpenTofu/Terraform configuration by being included in the other `terragrunt.hcl` files. In this case, you do not want the `run-all` commands to process the root level `terragrunt.hcl` since it does not define any infrastructure by itself. To make the `run-all` commands skip the root level `terragrunt.hcl` file, you can set `skip = true`: @@ -1297,7 +1297,7 @@ set `skip = true` will be skipped. ### iam_role -The `iam_role` attribute can be used to specify an IAM role that Terragrunt should assume prior to invoking Terraform. +The `iam_role` attribute can be used to specify an IAM role that Terragrunt should assume prior to invoking OpenTofu/Terraform. The precedence is as follows: `--terragrunt-iam-role` command line option → `TERRAGRUNT_IAM_ROLE` env variable → `iam_role` attribute of the `terragrunt.hcl` file in the module directory → `iam_role` attribute of the included @@ -1316,7 +1316,7 @@ iam_role = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME" ### iam_assume_role_duration -The `iam_assume_role_duration` attribute can be used to specify the STS session duration, in seconds, for the IAM role that Terragrunt should assume prior to invoking Terraform. +The `iam_assume_role_duration` attribute can be used to specify the STS session duration, in seconds, for the IAM role that Terragrunt should assume prior to invoking OpenTofu/Terraform. The precedence is as follows: `--terragrunt-iam-assume-role-duration` command line option → `TERRAGRUNT_IAM_ASSUME_ROLE_DURATION` env variable → `iam_assume_role_duration` attribute of the `terragrunt.hcl` file in the module directory → `iam_assume_role_duration` attribute of the included @@ -1330,7 +1330,7 @@ iam_assume_role_duration = 14400 ### iam_assume_role_session_name -The `iam_assume_role_session_name` attribute can be used to specify the STS session name, for the IAM role that Terragrunt should assume prior to invoking Terraform. +The `iam_assume_role_session_name` attribute can be used to specify the STS session name, for the IAM role that Terragrunt should assume prior to invoking OpenTofu/Terraform. The precedence is as follows: `--terragrunt-iam-assume-role-session-name` command line option → `TERRAGRUNT_IAM_ASSUME_ROLE_SESSION_NAME` env variable → `iam_assume_role_session_name` attribute of the `terragrunt.hcl` file in the module directory → `iam_assume_role_session_name` attribute of the included @@ -1379,7 +1379,7 @@ iam_web_identity_token = "/path/to/token/file" ### terraform_binary -The terragrunt `terraform_binary` string option can be used to override the default terraform binary path (which is +The terragrunt `terraform_binary` string option can be used to override the default binary Terragrunt calls (which is `tofu`). The precedence is as follows: `--terragrunt-tfpath` command line option → `TERRAGRUNT_TFPATH` env variable → @@ -1387,8 +1387,8 @@ The precedence is as follows: `--terragrunt-tfpath` command line option → `TER ### terraform_version_constraint -The terragrunt `terraform_version_constraint` string overrides the default minimum supported version of terraform. -Terragrunt only officially supports the latest version of terraform, however in some cases an old terraform is needed. +The terragrunt `terraform_version_constraint` string overrides the default minimum supported version of OpenTofu/Terraform. +Terragrunt usually only officially supports the latest version of OpenTofu/Terraform, however in some cases an old version of OpenTofu/Terraform is needed. Example: diff --git a/docs/_docs/05_rfc/template.md b/docs/_docs/05_rfc/template.md index 8c7b49602..bfb5fdc3a 100644 --- a/docs/_docs/05_rfc/template.md +++ b/docs/_docs/05_rfc/template.md @@ -30,7 +30,7 @@ template and fill in each respective section. This section should describe why you need this feature in Terragrunt. This should include a description of: - The problem you are trying to solve. -- The reason why Terraform can't solve this problem, or data points that suggest there is a long enough time horizon for +- The reason why OpenTofu/Terraform can't solve this problem, or data points that suggest there is a long enough time horizon for implementation that it makes sense to workaround it in Terragrunt. - Use cases for the problem. Why is it important that we have this feature? diff --git a/docs/_includes/get-access.html b/docs/_includes/get-access.html index 50d17cd5e..6b4fada56 100644 --- a/docs/_includes/get-access.html +++ b/docs/_includes/get-access.html @@ -1,8 +1,8 @@
Get access to over 300,000 lines of off-the-shelf, battle-tested, production-grade - Terraform & Terragrunt infrastructure code. + OpenTofu/Terraform & Terragrunt infrastructure code. Explore Gruntwork.io
- \ No newline at end of file + diff --git a/docs/_includes/use-cases-box.html b/docs/_includes/use-cases-box.html index cac4d16ab..12173768b 100644 --- a/docs/_includes/use-cases-box.html +++ b/docs/_includes/use-cases-box.html @@ -3,7 +3,7 @@

Use cases

- Keep your Terraform code DRY + Keep your OpenTofu/Terraform code DRY
Keep your remote state configuration DRY @@ -12,7 +12,7 @@

Use cases

Keep your CLI flags DRY
- Execute Terraform commands on multiple modules at once + Execute OpenTofu/Terraform commands on multiple modules at once
Work with multiple AWS accounts diff --git a/docs/_pages/docs/index.html b/docs/_pages/docs/index.html index 8fad21f88..5d114a183 100644 --- a/docs/_pages/docs/index.html +++ b/docs/_pages/docs/index.html @@ -1,8 +1,8 @@ --- layout: collection-browser title: Documentation -subtitle: Learn how to integrate Terragrunt with Terraform. -excerpt: Learn how to integrate Terragrunt with Terraform. +subtitle: Learn how to integrate Terragrunt with OpenTofu/Terraform. +excerpt: Learn how to integrate Terragrunt with OpenTofu/Terraform. permalink: /docs/ slug: docs nav_title: Documentation diff --git a/docs/_pages/index/_header.html b/docs/_pages/index/_header.html index 104d4a303..fb1464a9a 100644 --- a/docs/_pages/index/_header.html +++ b/docs/_pages/index/_header.html @@ -5,11 +5,10 @@ Hero
-

DRY and maintainable Terraform code.

+

DRY and maintainable OpenTofu/Terraform code.

- Terragrunt is a thin wrapper that provides extra tools for - keeping your configurations DRY, working with multiple - Terraform modules, and managing remote state. + Terragrunt is a flexible orchestration tool that allows + Infrastructure as Code to scale. Get Started
diff --git a/docs/_pages/index/_key-features.html b/docs/_pages/index/_key-features.html index 9189d5211..884cfd32e 100644 --- a/docs/_pages/index/_key-features.html +++ b/docs/_pages/index/_key-features.html @@ -4,14 +4,14 @@

Key features

- Keep your Terraform code DRY -

Keep your Terraform code DRY

-

Define Terraform code once, no matter how many environments you have.

+ Keep your OpenTofu/Terraform code DRY +

Keep your OpenTofu/Terraform code DRY

+

Define OpenTofu/Terraform code once, no matter how many environments you have.

- Keep your Terraform code DRY + Keep your OpenTofu/Terraform code DRY
@@ -34,7 +34,7 @@

Keep your Terraform code DRY

Keep your backend configuration DRY

Get rid of duplicated backend code. - Define how to manage your Terraform state once in + Define how to manage your OpenTofu/Terraform state once in a root directory and inherit in all child modules.

Learn more
@@ -46,13 +46,13 @@

Keep your backend configuration DRY

- Keep your Terraform CLI arguments DRY -

Keep your Terraform CLI arguments DRY

-

Set CLI arguments for repeatable Terraform commands once in Terragrunt configuration.

+ Keep your OpenTofu/Terraform CLI arguments DRY +

Keep your OpenTofu/Terraform CLI arguments DRY

+

Set CLI arguments for repeatable OpenTofu/Terraform commands once in Terragrunt configuration.

Learn more
- Keep your Terraform CLI arguments DRY + Keep your OpenTofu/Terraform CLI arguments DRY
@@ -62,11 +62,11 @@

Keep your Terraform CLI arguments DRY

- Execute Terraform commands on multiple modules at once - Execute Terraform commands on multiple modules at once + Execute OpenTofu/Terraform commands on multiple modules at once + Execute OpenTofu/Terraform commands on multiple modules at once
-

Execute Terraform commands on multiple modules at once

+

Execute OpenTofu/Terraform commands on multiple modules at once

Run one command for all modules instead of executing it in each module independently.

Learn more
@@ -79,7 +79,7 @@

Execute Terraform commands on multiple modules at once

Before & After hooks

-

Execute custom code before or after running Terraform.

+

Execute custom code before or after running OpenTofu/Terraform.

diff --git a/docs/docker-compose.yml b/docs/docker-compose.yml index 978a609d6..4aa91c798 100644 --- a/docs/docker-compose.yml +++ b/docs/docker-compose.yml @@ -1,5 +1,3 @@ -version: '3' - services: web: build: .