ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/website/docs/commands/init.html.markdown

185 lines
8.9 KiB
Markdown
Raw Normal View History

website: document init
2014-09-27 21:28:07 +02:00
---
layout: "docs"
page_title: "Command: init"
sidebar_current: "docs-commands-init"
Add meta descriptions to all pages
2014-10-22 05:21:56 +02:00
description: |-
website: document init and new state commands
2017-02-15 22:14:32 +01:00
The `terraform init` command is used to initialize a Terraform configuration. This is the first command that should be run for any new or existing Terraform configuration. It is safe to run this command multiple times.
website: document init
2014-09-27 21:28:07 +02:00
---
# Command: init
website: Add links to relevant Learn guides in several docs pages (#25718) Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
2020-07-31 22:16:35 +02:00
> For a hands-on tutorial, try the [Get Started](https://learn.hashicorp.com/terraform/getting-started/intro?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) track on HashiCorp Learn.
command init: remove confusing uses of "environment" in the usage "environment" is a very overloaded term, so here we prefer to use the term "working directory" to talk about a local directory where operations are executed on a given Terraform configuration.
2017-06-03 01:59:52 +02:00
The `terraform init` command is used to initialize a working directory
containing Terraform configuration files. This is the first command that should
be run after writing a new Terraform configuration or cloning an existing one
from version control. It is safe to run this command multiple times.
website: document init
2014-09-27 21:28:07 +02:00
## Usage
main: new global option -chdir This new option is intended to address the previous inconsistencies where some older subcommands supported partially changing the target directory (where Terraform would use the new directory inconsistently) where newer commands did not support that override at all. Instead, now Terraform will accept a -chdir command at the start of the command line (before the subcommand) and will interpret it as a request to direct all actions that would normally be taken in the current working directory into the target directory instead. This is similar to options offered by some other similar tools, such as the -C option in "make". The new option is only accepted at the start of the command line (before the subcommand) as a way to reflect that it is a global command (not specific to a particular subcommand) and that it takes effect _before_ executing the subcommand. This also means it'll be forced to appear before any other command-specific arguments that take file paths, which hopefully communicates that those other arguments are interpreted relative to the overridden path. As a measure of pragmatism for existing uses, the path.cwd object in the Terraform language will continue to return the _original_ working directory (ignoring -chdir), in case that is important in some exceptional workflows. The path.root object gives the root module directory, which will always match the overriden working directory unless the user simultaneously uses one of the legacy directory override arguments, which is not a pattern we intend to support in the long run. As a first step down the deprecation path, this commit adjusts the documentation to de-emphasize the inconsistent old command line arguments, including specific guidance on what to use instead for the main three workflow commands, but all of those options remain supported in the same way as they were before. In a later commit we'll make those arguments produce a visible deprecation warning in Terraform's output, and then in an even later commit we'll remove them entirely so that -chdir is the single supported way to run Terraform from a directory other than the one containing the root module configuration.
2020-09-02 00:45:12 +02:00
Usage: `terraform init [options]`
website: document init
2014-09-27 21:28:07 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
This command performs several different initialization steps in order to
main: new global option -chdir This new option is intended to address the previous inconsistencies where some older subcommands supported partially changing the target directory (where Terraform would use the new directory inconsistently) where newer commands did not support that override at all. Instead, now Terraform will accept a -chdir command at the start of the command line (before the subcommand) and will interpret it as a request to direct all actions that would normally be taken in the current working directory into the target directory instead. This is similar to options offered by some other similar tools, such as the -C option in "make". The new option is only accepted at the start of the command line (before the subcommand) as a way to reflect that it is a global command (not specific to a particular subcommand) and that it takes effect _before_ executing the subcommand. This also means it'll be forced to appear before any other command-specific arguments that take file paths, which hopefully communicates that those other arguments are interpreted relative to the overridden path. As a measure of pragmatism for existing uses, the path.cwd object in the Terraform language will continue to return the _original_ working directory (ignoring -chdir), in case that is important in some exceptional workflows. The path.root object gives the root module directory, which will always match the overriden working directory unless the user simultaneously uses one of the legacy directory override arguments, which is not a pattern we intend to support in the long run. As a first step down the deprecation path, this commit adjusts the documentation to de-emphasize the inconsistent old command line arguments, including specific guidance on what to use instead for the main three workflow commands, but all of those options remain supported in the same way as they were before. In a later commit we'll make those arguments produce a visible deprecation warning in Terraform's output, and then in an even later commit we'll remove them entirely so that -chdir is the single supported way to run Terraform from a directory other than the one containing the root module configuration.
2020-09-02 00:45:12 +02:00
prepare the current working directory for use with Terraform. More details on
these are in the sections below, but in most cases it is not necessary to worry
about these individual steps.
website: document init
2014-09-27 21:28:07 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
This command is always safe to run multiple times, to bring the working
directory up to date with changes in the configuration. Though subsequent runs
may give errors, this command will never delete your existing configuration or
state.
website: Update CLI flags for existing commands
2014-12-06 00:29:00 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
## General Options
website: document init and new state commands
2017-02-15 22:14:32 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
The following options apply to all of (or several of) the initialization steps:
website: Update CLI flags for existing commands
2014-12-06 00:29:00 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
* `-input=true` Ask for input if necessary. If false, will error if
input was required.
website: Update CLI flags for existing commands
2014-12-06 00:29:00 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
* `-lock=false` Disable locking of state files during state-related operations.
update init website docs
2017-06-16 23:27:57 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
* `-lock-timeout=<duration>` Override the time Terraform will wait to acquire
a state lock. The default is `0s` (zero seconds), which causes immediate
failure if the lock is already held by another process.
update init website docs
2017-06-16 23:27:57 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
* `-no-color` Disable color codes in the command output.
update init website docs
2017-06-16 23:27:57 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
* `-upgrade` Opt to upgrade modules and plugins as part of their respective
Update init.html.markdown Fix typo and replace some "it's" with "it is", according to rules for written English.
2018-01-24 18:41:42 +01:00
installation steps. See the sections below for more details.
website: Update CLI flags for existing commands
2014-12-06 00:29:00 +01:00
command: terraform init -from-module=... This restores the earlier behavior of the first positional argument to terraform init in 0.9, but as a command line option. The positional argument was removed to improve consistency with other commands that take a working directory as their first positional argument. It was originally intended that this functionality would return in a later release along with some other general improvements to Terraform's module handling, but we're introducing here an interim solution that uses the existing module source concept, to allow for easier porting of workflows that previously depended on the automatic copy behavior. In a future release this feature may change again as the module improvements design firms up, but we expect it to be broadly compatible with this temporary state.
2017-07-29 00:23:29 +02:00
## Copy a Source Module
By default, `terraform init` assumes that the working directory already
contains a configuration and will attempt to initialize that configuration.
Optionally, init can be run against an empty directory with the
website: correct the spelling of the -from-module arg to "terraform init"
2017-08-11 02:56:11 +02:00
`-from-module=MODULE-SOURCE` option, in which case the given module will be
command: terraform init -from-module=... This restores the earlier behavior of the first positional argument to terraform init in 0.9, but as a command line option. The positional argument was removed to improve consistency with other commands that take a working directory as their first positional argument. It was originally intended that this functionality would return in a later release along with some other general improvements to Terraform's module handling, but we're introducing here an interim solution that uses the existing module source concept, to allow for easier porting of workflows that previously depended on the automatic copy behavior. In a future release this feature may change again as the module improvements design firms up, but we expect it to be broadly compatible with this temporary state.
2017-07-29 00:23:29 +02:00
copied into the target directory before any other initialization steps are
run.
This special mode of operation supports two use-cases:
* Given a version control source, it can serve as a shorthand for checking out
chnage from work to working directory Sentence correction
2018-09-09 07:40:33 +02:00
a configuration from version control and then initializing the working directory
command: terraform init -from-module=... This restores the earlier behavior of the first positional argument to terraform init in 0.9, but as a command line option. The positional argument was removed to improve consistency with other commands that take a working directory as their first positional argument. It was originally intended that this functionality would return in a later release along with some other general improvements to Terraform's module handling, but we're introducing here an interim solution that uses the existing module source concept, to allow for easier porting of workflows that previously depended on the automatic copy behavior. In a future release this feature may change again as the module improvements design firms up, but we expect it to be broadly compatible with this temporary state.
2017-07-29 00:23:29 +02:00
for it.
* If the source refers to an _example_ configuration, it can be copied into
a local directory to be used as a basis for a new configuration.
Update init.html.markdown Fix typo and replace some "it's" with "it is", according to rules for written English.
2018-01-24 18:41:42 +01:00
For routine use it is recommended to check out configuration from version
command: terraform init -from-module=... This restores the earlier behavior of the first positional argument to terraform init in 0.9, but as a command line option. The positional argument was removed to improve consistency with other commands that take a working directory as their first positional argument. It was originally intended that this functionality would return in a later release along with some other general improvements to Terraform's module handling, but we're introducing here an interim solution that uses the existing module source concept, to allow for easier porting of workflows that previously depended on the automatic copy behavior. In a future release this feature may change again as the module improvements design firms up, but we expect it to be broadly compatible with this temporary state.
2017-07-29 00:23:29 +02:00
control separately, using the version control system's own commands. This way
Update init.html.markdown Fix typo and replace some "it's" with "it is", according to rules for written English.
2018-01-24 18:41:42 +01:00
it is possible to pass extra flags to the version control system when necessary,
command: terraform init -from-module=... This restores the earlier behavior of the first positional argument to terraform init in 0.9, but as a command line option. The positional argument was removed to improve consistency with other commands that take a working directory as their first positional argument. It was originally intended that this functionality would return in a later release along with some other general improvements to Terraform's module handling, but we're introducing here an interim solution that uses the existing module source concept, to allow for easier porting of workflows that previously depended on the automatic copy behavior. In a future release this feature may change again as the module improvements design firms up, but we expect it to be broadly compatible with this temporary state.
2017-07-29 00:23:29 +02:00
and to perform other preparation steps (such as configuration generation, or
activating credentials) before running `terraform init`.
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
## Backend Initialization
During init, the root configuration directory is consulted for
[backend configuration](/docs/backends/config.html) and the chosen backend
is initialized using the given configuration settings.
website: Fix several spelling errors
2019-03-21 20:20:29 +01:00
Re-running init with an already-initialized backend will update the working
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
directory to use the new backend settings. Depending on what changed, this
may result in interactive prompts to confirm migration of workspace states.
The `-force-copy` option suppresses these prompts and answers "yes" to the
migration questions. The `-reconfigure` option disregards any existing
configuration, preventing migration of any existing state.
update init docs add -reconfigure, and fix ordering of the other flags
2017-04-20 23:34:14 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
To skip backend configuration, use `-backend=false`. Note that some other init
Update init.html.markdown Fix typo and replace some "it's" with "it is", according to rules for written English.
2018-01-24 18:41:42 +01:00
steps require an initialized backend, so it is recommended to use this flag only
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
when the working directory was already previously initialized for a particular
backend.
website: Update CLI flags for existing commands
2014-12-06 00:29:00 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
The `-backend-config=...` option can be used for
[partial backend configuration](/docs/backends/config.html#partial-configuration),
in situations where the backend settings are dynamic or sensitive and so cannot
be statically specified in the configuration file.
Update init and remote config command docs * Update init docs to be correct, and provide an example. * Update remote config docs to provide more details about the Consul backend and to provide another example.
2015-10-19 01:23:13 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
## Child Module Installation
update command docs
2017-04-04 19:48:59 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
During init, the configuration is searched for `module` blocks, and the source
code for referenced [modules](/docs/modules/) is retrieved from the locations
given in their `source` arguments.
update command docs
2017-04-04 19:48:59 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
Re-running init with modules already installed will install the sources for
any modules that were added to configuration since the last init, but will not
change any already-installed modules. Use `-upgrade` to override this behavior,
updating all modules to the latest available source code.
update command docs
2017-04-04 19:48:59 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
To skip child module installation, use `-get=false`. Note that some other init
steps can complete only when the module tree is complete, so it's recommended
to use this flag only when the working directory was already previously
initialized with its child modules.
update command docs
2017-04-04 19:48:59 +02:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
## Plugin Installation
add init -verify-plugin to website docs
2017-06-20 17:50:31 +02:00
website: Reconcile docs about plugin discovery and downloading (#18973) website: Reconcile docs about plugin discovery and downloading I'm attempting to keep things simple for normal users while making sure we've got the full behavior written down somewhere for plugin developers. This commit doesn't stand alone; it's paired with a commit in the terraform-website repo, to deal with some related content in the "extend" section.
2018-10-03 01:53:29 +02:00
During init, Terraform searches the configuration for both direct and indirect
references to providers and attempts to load the required plugins.
For [providers distributed by HashiCorp](/docs/providers/index.html),
init will automatically download and install plugins if necessary. Plugins
can also be manually installed in the user plugins directory, located at
`~/.terraform.d/plugins` on most operating systems and
website: Fix plugin path on Windows (#19423) ...and one other reference to the application data directory. Context: https://docs.microsoft.com/en-us/windows/desktop/shell/knownfolderid#folderid_roamingappdata In newer Windows versions, the folder accessible as `%APPDATA%` (and via various APIs) is actually at something like "documents and settings\user\application data\roaming", while earlier versions omit the "\roaming" part of the path. This means you can confuse people by referring to the "application data" directory by its human name, because "roaming" is the real application data directory, but it looks like a subdirectory of "application data". Thus, it's less confusing to just use the `%APPDATA%` variable, with the added benefit that you can copy and paste the path and it'll just work in most places.
2018-11-21 01:54:18 +01:00
`%APPDATA%\terraform.d\plugins` on Windows.
website: Reconcile docs about plugin discovery and downloading (#18973) website: Reconcile docs about plugin discovery and downloading I'm attempting to keep things simple for normal users while making sure we've got the full behavior written down somewhere for plugin developers. This commit doesn't stand alone; it's paired with a commit in the terraform-website repo, to deal with some related content in the "extend" section.
2018-10-03 01:53:29 +02:00
For more information about configuring and installing providers, see
[Configuration: Providers](/docs/configuration/providers.html).
On subsequent runs, init only installs providers without acceptable versions
installed. (This includes newly added providers, and providers whose installed
versions can't meet the current version constraints.) Use `-upgrade` if you want
to update _all_ providers to the newest acceptable version.
You can modify `terraform init`'s plugin behavior with the following options:
- `-upgrade` — Update all previously installed plugins to the newest version
that complies with the configuration's version constraints. This option does
not apply to manually installed plugins.
- `-get-plugins=false` — Skips plugin installation. Terraform will use plugins
installed in the user plugins directory, and any plugins already installed
for the current working directory. If the installed plugins aren't sufficient
for the configuration, init fails.
- `-plugin-dir=PATH` — Skips plugin installation and loads plugins _only_ from
the specified directory. This ignores the user plugins directory and any
plugins already installed in the current working directory. To restore the
default behavior after using this option, run init again and pass an empty
string to `-plugin-dir`.
- `-verify-plugins=false` — Skips release signature validation when
installing downloaded plugins (not recommended). Official plugin releases are
digitally signed by HashiCorp, and Terraform verifies these signatures when
automatically downloading plugins. This option disables that verification.
(Terraform does not check signatures for manually installed plugins.)
command/init: backend-config accepts key=value pairs This augments backend-config to also accept key=value pairs. This should make Terraform easier to script rather than having to generate a JSON file. You must still specify the backend type as a minimal amount in configurations, example: ``` terraform { backend "consul" {} } ``` This is required because Terraform needs to be able to detect the _absense_ of that value for unsetting, if that is necessary at some point.
2017-03-17 07:27:05 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
## Running `terraform init` in automation
command/init: backend-config accepts key=value pairs This augments backend-config to also accept key=value pairs. This should make Terraform easier to script rather than having to generate a JSON file. You must still specify the backend type as a minimal amount in configurations, example: ``` terraform { backend "consul" {} } ``` This is required because Terraform needs to be able to detect the _absense_ of that value for unsetting, if that is necessary at some point.
2017-03-17 07:27:05 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
For teams that use Terraform as a key part of a change management and
deployment pipeline, it can be desirable to orchestrate Terraform runs in some
sort of automation in order to ensure consistency between runs, and provide
other interesting features such as integration with version control hooks.
command/init: backend-config accepts key=value pairs This augments backend-config to also accept key=value pairs. This should make Terraform easier to script rather than having to generate a JSON file. You must still specify the backend type as a minimal amount in configurations, example: ``` terraform { backend "consul" {} } ``` This is required because Terraform needs to be able to detect the _absense_ of that value for unsetting, if that is necessary at some point.
2017-03-17 07:27:05 +01:00
website: more-elaborate "terraform init" docs The "terraform init" command has a lot of different functionality now, making it hard to follow all of the options in the previous presentation. Instead, here we describe each of the steps and its associated options separately, hopefully making it easier to understand what each option relates to. In addition, much of the detail around backend partial configuration is factored out into the backend configuration page, where it seems more "at home"; previously it felt hard to follow exactly how partial configuration would be used, due to the information on it being split over two different pages.
2017-07-25 02:04:28 +02:00
There are some special concerns when running `init` in such an environment,
including optionally making plugins available locally to avoid repeated
re-installation. For more information, see
website: Remove extra copy of "Running Terraform in Automation", update links This document now lives at: - https://learn.hashicorp.com/terraform/development/running-terraform-in-automation ...and terraform.io has been redirecting to there for quite a while. This commit removes the extra copy so that the text of the two versions doesn't drift, and updates existing links to point to the new location.
2018-11-14 02:13:47 +01:00
[`Running Terraform in Automation`](https://learn.hashicorp.com/terraform/development/running-terraform-in-automation).
main: new global option -chdir This new option is intended to address the previous inconsistencies where some older subcommands supported partially changing the target directory (where Terraform would use the new directory inconsistently) where newer commands did not support that override at all. Instead, now Terraform will accept a -chdir command at the start of the command line (before the subcommand) and will interpret it as a request to direct all actions that would normally be taken in the current working directory into the target directory instead. This is similar to options offered by some other similar tools, such as the -C option in "make". The new option is only accepted at the start of the command line (before the subcommand) as a way to reflect that it is a global command (not specific to a particular subcommand) and that it takes effect _before_ executing the subcommand. This also means it'll be forced to appear before any other command-specific arguments that take file paths, which hopefully communicates that those other arguments are interpreted relative to the overridden path. As a measure of pragmatism for existing uses, the path.cwd object in the Terraform language will continue to return the _original_ working directory (ignoring -chdir), in case that is important in some exceptional workflows. The path.root object gives the root module directory, which will always match the overriden working directory unless the user simultaneously uses one of the legacy directory override arguments, which is not a pattern we intend to support in the long run. As a first step down the deprecation path, this commit adjusts the documentation to de-emphasize the inconsistent old command line arguments, including specific guidance on what to use instead for the main three workflow commands, but all of those options remain supported in the same way as they were before. In a later commit we'll make those arguments produce a visible deprecation warning in Terraform's output, and then in an even later commit we'll remove them entirely so that -chdir is the single supported way to run Terraform from a directory other than the one containing the root module configuration.
2020-09-02 00:45:12 +02:00
## Passing a Different Configuration Directory
Terraform v0.13 and earlier also accepted a directory path in place of the
plan file argument to `terraform apply`, in which case Terraform would use
that directory as the root module instead of the current working directory.
That usage is still supported in Terraform v0.14, but is now deprecated and we
plan to remove it in Terraform v0.15. If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option](./#switching-working-directory-with--chdir)
instead, which works across all commands and makes Terraform consistently look
in the given directory for all files it would normaly read or write in the
current working directory.
If your previous use of this legacy pattern was also relying on Terraform
writing the `.terraform` subdirectory into the current working directory even
though the root module directory was overridden, use
[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
to direct Terraform to write the `.terraform` directory to a location other
than the current working directory.