jprdonnelly/opentf
1
0
Fork 0
mirror of https://github.com/opentffoundation/opentf.git synced 2025-12-25 01:00:16 -05:00
Code Issues Packages Projects Releases Wiki Activity

Versioned docs: replacing docs links with relative variants (#1537)

Browse Source 
Signed-off-by: Janos <86970079+janosdebugs@users.noreply.github.com>
Signed-off-by: Damian Stasik <920747+damianstasik@users.noreply.github.com>
Signed-off-by: Roman Grinovski <roman.grinovski@gmail.com>
Co-authored-by: Damian Stasik <920747+damianstasik@users.noreply.github.com>
Co-authored-by: Roman Grinovski <roman.grinovski@gmail.com>
This commit is contained in:
Janos
2024-04-24 13:24:30 +02:00
committed by GitHub
parent f31de2d6bc
commit a15a6c9657
241 changed files with 1243 additions and 988 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
website/docs/language/settings/backends/configuration.mdx
View File

@@ -6,7 +6,7 @@ description: >-
# Backend Configuration
A backend defines where OpenTofu stores its [state](/docs/language/state) data files.
A backend defines where OpenTofu stores its [state](../../../language/state/index.mdx) data files.
OpenTofu uses persisted state data to keep track of the resources it manages. Most non-trivial OpenTofu configurations either intergrate with TACOS (TF Automation and Collaboration Software) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
@@ -14,14 +14,14 @@ This page describes how to configure a backend by adding the [`backend` block](#
## Available Backends
By default, OpenTofu uses a backend called [`local`](/docs/language/settings/backends/local), which stores state as a local file on disk. You can also configure one of the built-in backends included in this documentation.
By default, OpenTofu uses a backend called [`local`](../../../language/settings/backends/local.mdx), which stores state as a local file on disk. You can also configure one of the built-in backends included in this documentation.
Some of these backends act like plain remote disks for state files, while others support locking the state while operations are being performed. This helps prevent conflicts and inconsistencies. The built-in backends listed are the only backends. You cannot load additional backends as plugins.
## Using a Backend Block
You do not need to configure a backend when using TACOS (TF Automation and Collaboration Software) because
it automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](/docs/language/settings/tf-cloud), it cannot include a `backend` block.
it automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](../../../language/settings/tf-cloud.mdx), it cannot include a `backend` block.
To configure a backend, add a nested `backend` block within the top-level
`terraform` block. The following example configures the `remote` backend.
@@ -79,7 +79,7 @@ or state operations.
After you initialize, OpenTofu creates a `.terraform/` directory locally. This directory contains the most recent backend configuration, including any authentication parameters you provided to the OpenTofu CLI. Do not check this directory into Git, as it may contain sensitive credentials for your remote backend.
The local backend configuration is different and entirely separate from the `terraform.tfstate` file that contains [state data](/docs/language/state) about your real-world infrastruture. OpenTofu stores the `terraform.tfstate` file in your remote backend.
The local backend configuration is different and entirely separate from the `terraform.tfstate` file that contains [state data](../../../language/state/index.mdx) about your real-world infrastruture. OpenTofu stores the `terraform.tfstate` file in your remote backend.
When you change backends, OpenTofu gives you the option to migrate
your state to the new backend. This lets you adopt backends without losing
@@ -98,7 +98,7 @@ automatically by an automation script running OpenTofu. When some or all of
the arguments are omitted, we call this a _partial configuration_.
With a partial configuration, the remaining configuration arguments must be
provided as part of [the initialization process](/docs/cli/init).
provided as part of [the initialization process](../../../cli/init/index.mdx).
There are several ways to supply the remaining arguments:
@@ -181,12 +181,12 @@ both the configuration itself as well as the type of backend (for example
from "consul" to "s3").
OpenTofu will automatically detect any changes in your configuration
and request a [reinitialization](/docs/cli/init). As part of
and request a [reinitialization](../../../cli/init/index.mdx). As part of
the reinitialization process, OpenTofu will ask if you'd like to migrate
your existing state to the new configuration. This allows you to easily
switch from one backend to another.
If you're using multiple [workspaces](/docs/language/state/workspaces),
If you're using multiple [workspaces](../../../language/state/workspaces.mdx),
OpenTofu can copy all workspaces to the destination. If OpenTofu detects
you have multiple workspaces, it will ask if this is what you want to do.
@@ -197,7 +197,7 @@ want to migrate your state. You can respond "no" in this scenario.
If you no longer want to use any backend, you can simply remove the
configuration from the file. OpenTofu will detect this like any other
change and prompt you to [reinitialize](/docs/cli/init).
change and prompt you to [reinitialize](../../../cli/init/index.mdx).
As part of the reinitialization, OpenTofu will ask if you'd like to migrate
your state back down to normal local state. Once this is complete then