I'm attempting to run a terraform_plan in my prod environment, but I receive the following error:
│ Error: instance profile is required to re-create mounting cluster
│
│ with databricks_mount.gfc_databricks_delta_lake,
│ on gfc_mount_delta_lake.tf line 1, in resource "databricks_mount" "gfc_databricks_delta_lake":
│ 1: resource "databricks_mount" "gfc_databricks_delta_lake" {
│
╵
Here's the code for the mount:
resource "databricks_mount" "gfc_databricks_delta_lake" {
depends_on = [
databricks_cluster.gfc_automation_cluster,
databricks_instance_profile.gfc_instance_profile
]
provider = databricks.workspace_00
name = "gfc"
cluster_id = databricks_cluster.gfc_automation_cluster.id
s3 {
bucket_name = "XXX"
}
}
This code, along with the code for the instance profiles and automation clusters, is identical between our dev and prod environment. Still, the error only pops up in prod.
What's puzzling is that the databricks_mount is pointed to a cluster that already has an instance profile. The instance profile exists in the Terraform state file, Databricks, and AWS.
One thing that's strange is that the cluster that's supposed to be using that instance profile is missing from Databricks, but is present in the state file. Could be a clue.
You need to set DATABRICKS_HOST and DATABRICKS_TOKEN environment variables.
You can add the following lines to your .bashrc or .zshrc to automatically set these values as environment variables when you open up a new terminal session
export DATABRICKS_HOST="insert_databricks_workspace_url"
export DATABRICKS_TOKEN="insert_databricks_api_token"
Per Databricks Provider Terraform Documentation,
You can use host and token parameters to supply credentials to the workspace. When environment variables are preferred, then you can specify DATABRICKS_HOST and DATABRICKS_TOKEN instead. Environment variables are the second most recommended way of configuring this provider.
source
I'm trying to create a databricks instance profile using the sample code from the documentation.
Terraform can generate the plan successfully but when I try to apply it it gives me this error:
╷
│ Error: cannot create instance profile: authentication is not configured for provider.. Please check https://registry.terraform.io/providers/databrickslabs/databricks/latest/docs#authentication for details
│
│ with databricks_instance_profile.shared,
│ on IAM.tf line 73, in resource "databricks_instance_profile" "shared":
│ 73: resource "databricks_instance_profile" "shared" {
I have setup username/password authentication for databricks in my terraform tfvars files and this works - it is able to actually provision a workspace, but fails when creating the instance profile.
Appreciate any inputs on what I'm doing wrong.
Usually this kind of problems arise when you create a workspace & attempt to use it in the same terraform template. The solution for that is to have two declarations of the Databricks provider - one will be used for creation of the workspace, and second - for creation of the objects inside workspace. The AWS provisioning guide is a part of official documentation and contains full example:
provider "databricks" {
alias = "mws"
host = "https://accounts.cloud.databricks.com"
username = var.databricks_account_username
password = var.databricks_account_password
}
# Notice "provider = databricks.mws" !
resource "databricks_mws_credentials" "this" {
provider = databricks.mws
account_id = var.databricks_account_id
role_arn = aws_iam_role.cross_account_role.arn
credentials_name = "${local.prefix}-creds"
depends_on = [aws_iam_role_policy.this]
}
provider "databricks" {
host = var.databricks_host
token = var.databricks_token
}
resource "databricks_instance_profile" "shared" {
depends_on = [databricks_mws_workspaces.this]
instance_profile_arn = aws_iam_instance_profile.shared.arn
}
Another common issue arises from the fact that Terraform is trying to run as many tasks as possible in parallel, so it may attempt to create Terraform resource before workspace is created - this is explicitly documented in the AWS provisioning guide, so you need to add depends_on = [databricks_mws_workspaces.this] to all databricks resources, so Terraform won't attempt to create Databricks objects before creating workspace:
P.S. It's also recommended to upgrade to the latest version of provider (0.4.4 as of right now) that has better error messages for such problems.
I am new to Terraform, apologies for asking such a basic question. I am trying to create an s3 bucket resource using terraform. Below is my code,
resource "aws_s3_bucket" "my_very_first_bucket" {
bucket = "hetal-s3-my-very-first-bucket"
region = "ap-south-1"
}
The command terraform init was executed successfully but I am getting below error while executing terraform apply.
C:\Users\Hetal Rachh\IdeaProjects\demo>terraform apply
provider.aws.region
The region where AWS operations will take place. Examples
are us-east-1, us-west-2, etc.
Enter a value: ap-south-1
╷
│ Error: Computed attributes cannot be set
│
│ on s3.tf line 3, in resource "aws_s3_bucket" "my_very_first_bucket":
│ 3: region = "ap-south-1"
│
│ Computed attributes cannot be set, but a value was set for "region".
╵
May I know what am I doing wrong here? Please help. Thanks in advance.
The error that you are getting is because AWS provider does not use region for the S3 resource. However, S3 provides an attribute with the same name after it is created successfully. The question you are getting is probably because you have not set any provider related configuration. What you could do is add the following at the top of the s3.tf file:
provider aws {
region = "ap-south-1"
}
For the S3 bucket, you would then have:
resource "aws_s3_bucket" "my_very_first_bucket" {
bucket = "hetal-s3-my-very-first-bucket"
}
Here is the Terraform provider documentation for S3: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket. At the bottom, see the exported attributes for S3: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket#attributes-reference.
I'm just getting started with terraform and I'd like to be able to use AWS S3 as my backend for storing the state of my projects.
terraform {
backend "s3" {
bucket = "tfstate"
key = "app-state"
region = "us-east-1"
}
}
I feel like it is sensible to setup my S3 bucket, IAM groups and polices for the backend storage infrastructure with terraform as well.
If I setup my backend state before I apply my initial terraform infrastructure, it reasonably complains that the backend bucket is not yet created. So, my question becomes, how do I setup my terraform backend with terraform, while keeping my state for the backend tracked by terraform. Seems like a nested dolls problem.
I have some thoughts about how to script around this, for example, checking to see if the bucket exists or some state has been set, then bootstrapping terraform and finally copying the terraform tfstate up to s3 from the local file system after the first run. But before going down this laborious path, I thought I'd make sure I wasn't missing something obvious.
To set this up using terraform remote state, I usually have a separate folder called remote-state within my dev and prod terraform folder.
The following main.tf file will set up your remote state for what you posted:
provider "aws" {
region = "us-east-1"
}
resource "aws_s3_bucket" "terraform_state" {
bucket = "tfstate"
lifecycle {
prevent_destroy = true
}
}
resource "aws_s3_bucket_versioning" "terraform_state" {
bucket = aws_s3_bucket.terraform_state.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_dynamodb_table" "terraform_state_lock" {
name = "app-state"
read_capacity = 1
write_capacity = 1
hash_key = "LockID"
attribute {
name = "LockID"
type = "S"
}
}
Then get into this folder using cd remote-state, and run terraform init && terraform apply - this should only need to be run once. You might add something to bucket and dynamodb table name to separate your different environments.
Building on the great contribution from Austin Davis, here is a variation that I use which includes a requirement for data encryption:
provider "aws" {
region = "us-east-1"
}
resource "aws_s3_bucket" "terraform_state" {
bucket = "tfstate"
versioning {
enabled = true
}
lifecycle {
prevent_destroy = true
}
}
resource "aws_dynamodb_table" "terraform_state_lock" {
name = "app-state"
read_capacity = 1
write_capacity = 1
hash_key = "LockID"
attribute {
name = "LockID"
type = "S"
}
}
resource "aws_s3_bucket_policy" "terraform_state" {
bucket = "${aws_s3_bucket.terraform_state.id}"
policy =<<EOF
{
"Version": "2012-10-17",
"Id": "RequireEncryption",
"Statement": [
{
"Sid": "RequireEncryptedTransport",
"Effect": "Deny",
"Action": ["s3:*"],
"Resource": ["arn:aws:s3:::${aws_s3_bucket.terraform_state.bucket}/*"],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
},
"Principal": "*"
},
{
"Sid": "RequireEncryptedStorage",
"Effect": "Deny",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::${aws_s3_bucket.terraform_state.bucket}/*"],
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
},
"Principal": "*"
}
]
}
EOF
}
As you've discovered, you can't use terraform to build the components terraform needs in the first place.
While I understand the inclination to have terraform "track everything", it is very difficult, and more headache than it's worth.
I generally handle this situation by creating a simple bootstrap shell script. It creates things like:
The s3 bucket for state storage
Adds versioning to said bucket
a terraform IAM user and group with certain policies I'll need for terraform builds
While you should only need to run this once (technically), I find that when I'm developing a new system, I spin up and tear things down repeatedly. So having those steps in one script makes that a lot simpler.
I generally build the script to be idempotent. This way, you can run it multiple times without concern that you're creating duplicate buckets, users, etc
I created a terraform module with a few bootstrap commands/instructions to solve this:
https://github.com/samstav/terraform-aws-backend
There are detailed instructions in the README, but the gist is:
# conf.tf
module "backend" {
source = "github.com/samstav/terraform-aws-backend"
backend_bucket = "terraform-state-bucket"
}
Then, in your shell (make sure you haven't written your terraform {} block yet):
terraform get -update
terraform init -backend=false
terraform plan -out=backend.plan -target=module.backend
terraform apply backend.plan
Now write your terraform {} block:
# conf.tf
terraform {
backend "s3" {
bucket = "terraform-state-bucket"
key = "states/terraform.tfstate"
dynamodb_table = "terraform-lock"
}
}
And then you can re-init:
terraform init -reconfigure
What I usually do is start without remote backend for creating initial infrastructure as you said , S3 , IAM roles and other essential stuff. Once I have that I just add backend configuration and run terraform init to migrate to S3.
It's not the best case but in most cases I don't rebuild my entire environment everyday so this semi automated approach is good enough.
I also separate next "layers" (VPC, Subnets, IGW, NAT ,etc) of infrastructure to different states.
Setting up a Terraform backend leveraging an AWS s3 bucket is relatively easy.
First, create a bucket in the region of your choice (eu-west-1 for the example), named terraform-backend-store (remember to choose a unique name.)
To do so, open your terminal and run the following command, assuming that you have properly set up the AWS CLI (otherwise, follow the instructions at the official documentation):
aws s3api create-bucket --bucket terraform-backend-store \
--region eu-west-1 \
--create-bucket-configuration \
LocationConstraint=eu-west-1
# Output:
{
"Location": "http://terraform-backend-store.s3.amazonaws.com/"
}
The command should be self-explanatory; to learn more check the documentation here.
Once the bucket is in place, it needs a proper configuration for security and reliability.
For a bucket that holds the Terraform state, it’s common-sense enabling the server-side encryption. Keeping it simple, try first AES256 method (although I recommend to use KMS and implement a proper key rotation):
aws s3api put-bucket-encryption \
--bucket terraform-backend-store \
--server-side-encryption-configuration={\"Rules\":[{\"ApplyServerSideEncryptionByDefault\":{\"SSEAlgorithm\":\"AES256\"}}]}
# Output: expect none when the command is executed successfully
Next, it’s crucial restricting the access to the bucket; create an unprivileged IAM user as follows:
aws iam create-user --user-name terraform-deployer
# Output:
{
"User": {
"UserName": "terraform-deployer",
"Path": "/",
"CreateDate": "2019-01-27T03:20:41.270Z",
"UserId": "AIDAIOSFODNN7EXAMPLE",
"Arn": "arn:aws:iam::123456789012:user/terraform-deployer"
}
}
Take note of the Arn from the command’s output (it looks like: “Arn”: “arn:aws:iam::123456789012:user/terraform-deployer”).
To correctly interact with the s3 service and DynamoDB at a later stage to implement the locking, our IAM user must hold a sufficient set of permissions.
It is recommended to have severe restrictions in place for production environments, though, for the sake of simplicity, start assigning AmazonS3FullAccess and AmazonDynamoDBFullAccess:
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --user-name terraform-deployer
# Output: expect none when the command execution is successful
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess --user-name terraform-deployer
# Output: expect none when the command execution is successful
The freshly created IAM user must be enabled to execute the required actions against your s3 bucket. You can do this by creating and applying the right policy, as follows:
cat <<-EOF >> policy.json
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/terraform-deployer"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::terraform-remote-store"
}
]
}
EOF
This basic policy file grants the principal with arn “arn:aws:iam::123456789012:user/terraform-deployer”, to execute all the available actions (“Action”: “s3:*") against the bucket with arn “arn:aws:s3:::terraform-remote-store”.
Again, in production is desired to force way stricter policies. For reference, have a look at the AWS Policy Generator.
Back to the terminal and run the command as shown below, to enforce the policy in your bucket:
aws s3api put-bucket-policy --bucket terraform-remote-store --policy file://policy.json
# Output: none
As the last step, enable the bucket’s versioning:
aws s3api put-bucket-versioning --bucket terraform-remote-store --versioning-configuration Status=Enabled
It allows saving different versions of the infrastructure’s state and rollback easily to a previous stage without struggling.
The AWS s3 bucket is ready, time to integrate it with Terraform. Listed below, is the minimal configuration required to set up this remote backend:
# terraform.tf
provider "aws" {
region = "${var.aws_region}"
shared_credentials_file = "~/.aws/credentials"
profile = "default"
}
terraform {
backend "s3" {
bucket = "terraform-remote-store"
encrypt = true
key = "terraform.tfstate"
region = "eu-west-1"
}
}
# the rest of your configuration and resources to deploy
Once in place, terraform must be initialized (again).
terraform init
The remote backend is ready for a ride, test it.
What about locking?
Storing the state remotely brings a pitfall, especially when working in scenarios where several tasks, jobs, and team members have access to it. Under these circumstances, the risk of multiple concurrent attempts to make changes to the state is high. Here comes to help the lock, a feature that prevents opening the state file while already in use.
You can implement the lock creating an AWS DynamoDB Table, used by terraform to set and unset the locks.
Provision the resource using terraform itself:
# create-dynamodb-lock-table.tf
resource "aws_dynamodb_table" "dynamodb-terraform-state-lock" {
name = "terraform-state-lock-dynamo"
hash_key = "LockID"
read_capacity = 20
write_capacity = 20
attribute {
name = "LockID"
type = "S"
}
tags {
Name = "DynamoDB Terraform State Lock Table"
}
}
and deploy it as shown:
terraform plan -out "planfile" && terraform apply -input=false -auto-approve "planfile"
Once the command execution is completed, the locking mechanism must be added to your backend configuration as follow:
# terraform.tf
provider "aws" {
region = "${var.aws_region}"
shared_credentials_file = "~/.aws/credentials"
profile = "default"
}
terraform {
backend "s3" {
bucket = "terraform-remote-store"
encrypt = true
key = "terraform.tfstate"
region = "eu-west-1"
dynamodb_table = "terraform-state-lock-dynamo"
}
}
# the rest of your configuration and resources to deploy
All done. Remember to run again terraform init and enjoy your remote backend.
What I have been doing to address this is that, You can comment out the "backend" block for the initial run, and do a selected terraform apply on only the state bucket and any related resources(like bucket policies).
# backend "s3" {
# bucket = "foo-bar-state-bucket"
# key = "core-terraform.tfstate"
# region = "eu-west-1"
# }
#}
provider "aws" {
region = "eu-west-1"
profile = "terraform-iam-user"
shared_credentials_file = "~/.aws/credentials"
}
terraform apply --target aws_s3_bucket.foobar-terraform --target aws_s3_bucket_policy.foobar-terraform
This will provision your s3 state bucket, and will store .tfstate file locally in your working directory.
Later, Uncomment the "backend" block and reconfigure the backend terraform init --reconfigure
, which will prompt you to copy your locally present .tfstate file, (tracking state of your backend s3 bucket) to the remote backend which is now available to be used by terraform for any subsequent runs.
Prompt for copying exisitng state to remote backend
There are some great answers here & I'd like to offer an alternative to managing your back end state;
Set up a Terraform Cloud Account (it's free for up to 5 users).
Create a workspace for your organization (Version control workflow is typical)
Select your VCS such as github or bitbucket (where you store your terraform plans and modules)
Terraform Cloud will give you the instructions needed for your new OAuth Connection
Once that's setup you'll have the option to set up an SSH keypair which is typically not needed & you can click the Skip & Finish button
Once your terraform cloud account is set up & connected to your VCS repos where you store your terraform plans & modules...
Add your terraform module repos in terraform cloud, by clicking on the Registry tab. You will need to ensure that your terraform modules are versioned / tagged & follow proper naming convention. If you have a terraform module that creates a load balancer in AWS, you would name the terraform module repository (in github for example), like this: terraform-aws-loadbalancer. As long as it starts with terraform-aws- you're good. Then you add a version tag to it such as 1.0.0
So let's say you create a terraform plan that points to that load balancer module, this is how you point your backend config to terraform cloud & to the load balancer module:
backend-state.tf contents:
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "YOUR-TERRAFORM-CLOUD-ORG"
workspaces {
# name = "" ## For single workspace jobs
# prefix = "" ## for multiple workspaces
# you can use name instead of prefix
prefix = "terraform-plan-name-"
}
}
}
terraform plan main.tf contents;
module "aws_alb" {
source = "app.terraform.io/YOUR-TERRAFORM-CLOUD-ORG/loadbalancer/aws"
version = "1.0.0"
name = "load-balancer-test"
security_groups = [module.aws_sg.id]
load_balancer_type = "application"
internal = false
subnets = [data.aws_subnet.public.id]
idle_timeout = 1200
# access_logs_enabled = true
# access_logs_s3bucket = "BUCKET-NAME"
tags = local.tags
}
Locally from your terminal (using Mac OSX as an example);
terraform init
# if you're using name instead of prefix in your backend set
# up, no need to run terraform workspace cmd
terraform workspace new test
terraform plan
terraform apply
You'll see the apply happening in terraform cloud under your workspaces with this name: terraform-plan-name-test
"test" is appended to your workspace prefix name which is defined in your backend-state.tf above. You end up with a GUI / Console full of your terraform plans within your workspace, the same way you can see your Cloudformation Stacks in AWS. I find devops that are used to Cloudformation and transitioning to Terraform, like this set up.
One advantage is, within Terraform Cloud you can easily set it up so that a plan (stack build) is triggered with a git commit or merge to the master branch.
1 reference:
https://www.terraform.io/docs/language/settings/backends/remote.html#basic-configuration
I would Highly recommend using Terragrunt to keep your Terraform code manageable and DRY (the Don't repeat yourself principle).
Terragrunt has many capabilities - for your specific case I would suggest following the Keep your remote state configuration DRY section.
I'll add a short and simplified summary below.
Problems with managing remote state with Terraform
Let's say you have the following Terraform infrastructure:
├── backend-app
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
├── frontend-app
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
├── mysql
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
└── mongo
├── main.tf
└── other_resources.tf
└── variables.tf
Each app is a terraform module that you'll want to store its Terraform state in a remote backend.
Without Terragrunt you'll have to write the backend configuration block for each application in order to save the current state in a remote state storage:
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "frontend-app/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "my-lock-table"
}
}
Managing a few modules like in the above example its not a burden to add this file for each one of them - but it won't last for real world scenarious.
Wouldn't it be better if we could do some kind of inheritance (like in Object oriented programming)?
This is made easy with Terragrunt.
Terragrunt to the rescue
Back to the modules structure.
With Terragrunt we just need add add a root terragrunt.hcl with all the configurations and for each module you add a child terragrunt.hcl which contains only on statement:
├── terragrunt.hcl #<---- Root
├── backend-app
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
│ └── terragrunt.hcl #<---- Child
├── frontend-app
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
│ └── terragrunt.hcl #<---- Child
├── mysql
│ ├── main.tf
│ └── other_resources.tf
│ └── variables.tf
│ └── terragrunt.hcl #<---- Child
└── mongo
├── main.tf
└── other_resources.tf
└── variables.tf
└── terragrunt.hcl. #<---- Child
The root terragrunt.hcl will keep your remote state configuration and the children will only have the following statement:
include {
path = find_in_parent_folders()
}
This include block tells Terragrunt to use the exact same Terragrunt configuration from the root terragrunt.hcl file specified via the path parameter.
The next time you run terragrunt, it will automatically configure all the settings in the remote_state.config block, if they aren’t configured already, by calling terraform init.
The backend.tf file will be created automatically for you.
Summary
You can have hundreds of modules with nested hierarchy (for example divided into regions,tenants, applications etc') and still be able to maintain only one configuration of the remote state.
The way I have overcome this issue is by creating the project remote state in the first init plan apply cycle and initializing the remote state in the second init plan apply cycle.
# first init plan apply cycle
# Configure the AWS Provider
# https://www.terraform.io/docs/providers/aws/index.html
provider "aws" {
version = "~> 2.0"
region = "us-east-1"
}
resource "aws_s3_bucket" "terraform_remote_state" {
bucket = "terraform-remote-state"
acl = "private"
tags = {
Name = "terraform-remote-state"
Environment = "Dev"
}
}
# add this sniped and execute the
# the second init plan apply cycle
# https://www.terraform.io/docs/backends/types/s3.html
terraform {
backend "s3" {
bucket = "terraform-remote-state"
key = "path/to/my/key"
region = "us-east-1"
}
}
Managing terraform state bucket with terraform is kind of chicken and egg problem. One of the way we can address is:
Create terraform state bucket with terraform with local backend and then migrate the state to newly create state bucket.
It can be a bit tricky if you are trying to achieve this with a CI/CD pipeline and trying to make the job idempotent in nature.
Modularise backend configuration in a separate file.
terraform.tf
terraform {
required_version = "~> 1.3.6"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.48.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
main.tf
module "remote_state" {
# you can write your own module or use any community module which
# creates a S3 bucket and dynamoDB table (ideally with replication and versioning)
source = "../modules/module-for-s3-bucket-and-ddtable"
bucket_name = "terraform-state-bucket-name"
dynamodb_table_name = "terraform-state-lock"
}
backend.tf
terraform {
backend "s3" {
bucket = "terraform-state-bucket-name"
key = "state.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-state-lock"
}
}
With following steps we can manage and create state S3 bucket in the same state.
function configure_state() {
# Disable S3 bucket backend
mv backend.tf backend.tf.backup
# Since S3 config is not present terraform local state will be initialized
# Or copied from s3 bucket if it already existed
terraform init -migrate-state -auto-approve
# Terraform apply will create the S3 bucket backend and save the state in local state
terraform apply -target module.remote_state
# It will re-enable S3 backend configuration for storing state
mv backend.tf.backup backend.tf
#It will migrate the state from local to S3 bucket
terraform init -migrate-state -auto-approve
}
there is a version issue here within terraform, for me it is working for the mentioned version. also, it is good to have the terraform state on the bucket.
terraform {
required_version = "~> 0.12.12"
backend "gcs" {
bucket = "bbucket-name"
prefix = "terraform/state"
}
}
As a word of caution, I would not create a terraform statefile with terraform in case someone inadvertently deletes it. So use scripts like aws-cli or boto3 which do not maintain state and keep those scripts limited to a variable for s3 bucket name. You will not really change the script for terraform state bucket in the long run except for creating additional folders inside the bucket which can be done outside terraform in the resource level.
All of the answers provided are very good. I just want to emphasize the "key" attribute. When you get into advanced applications of Terraform, you will eventually need to reference these S3 keys in order to pull remote state into a current project, or to leverage 'terraform move'.
It really helps to use intelligent key names when you plan your "terraform" stanza to define your backend.
I recommend the following as a base key name:
account_name/{development:production}/region/module_name/terraform.tfstate
Revise to fit your needs, but going back and fixing all my key names as I expanded my use of Terraform across many accounts and regions was not fun at all.
You can just simply use terraform cloud and configure your backend as follows:
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "your-tf-organization-name"
workspaces {
name = "your-workspace-name"
}
}
}
Assuming that you are running terraform locally and not on some virtual server and that you want to store terraform state in S3 bucket that doesn't exist. This is how I would approach it,
Create terraform script, that provisions S3 bucket
Create terraform script that provisions your infrastructure
At the end of your terraform script to provision bucket to be used by second terraform script for storing state files, include code to provision null resource.
In the code block for the null resource using local-exec provisioner run command to go into the directory where your second terraform script exist followed by usual terraform init to initialize the backend then terraform plan, then terraform apply
I've made a script according to that answer. Keep in mind you'll need to import DynamoDB to your tf state as it is created through aws cli.