terraform-state

Everything for state related terraform

s3

Create an S3 bucket to store the Terraform state files and a DynamoDB table to support state locking. The bucket has server-side encryption enabled by default and the bucket policy enforces it for all uploads.

Available variables

Name	Description	Type	Default	Required
project	Project name	string	n/a	yes

Output

Name	Description
bucket_id	Id (name) of the S3 bucket
locktable_id	Id (name) of the DynamoDB lock table
tf_policy_arn	The ARN of the policy for Terraform users to access the state and lock table
tf_policy_id	The ID of the policy for Terraform users to access the state and lock table
tf_policy_name	The name of the policy for Terraform users to access the state and lock table

Example

module "s3" {
  source  = "github.com/skyscrapers/terraform-state//s3?ref=4.0.0"
  project = "some-project"
}

After applying the module, you can configure your Terraform backend like this:

terraform {
  backend "s3" {
    key            = "something" # this should be different for each Terraform configuration / stack you have
    bucket         = "terraform-remote-state-some-project"
    region         = "eu-west-1"
    encrypt        = true
    dynamodb_table = "terraform-remote-state-lock-some-project"
    acl            = "bucket-owner-full-control"
  }
}

Multi-account AWS Architecture

When running Terraform on a multi-account AWS setup (e.g. an account per environment), it's recommended to setup a single S3 bucket (and DynamoDB lock table) in an "administrative" AWS account for the Terraform state. Please read the Terraform S3 backend documentation for more information on this topic.

azurerm

Creates an Azure resource group, a Storage account and a storage container to use as a Terraform backend.

Variables

Name	Description	Type	Default	Required
location	Azure region where to deploy the storage account	`any`	n/a	yes
project	Project name	`any`	n/a	yes
tags	Additional tags to add to the created resources	`map`	`{}`	no

Outputs

Name	Description
resource_group_id	Resource group ID where the storage account is deployed
resource_group_name	Resource group name where the storage account is deployed
storage_account_id	Storage account ID where the Terraform backend should point to
storage_account_name	Storage account name where the Terraform backend should point to
storage_container_id	Storage container ID where to put the Terraform state files
storage_container_name	Storage container name where to put the Terraform state files

Examples

module "tf_backend_azurerm" {
  source   = "github.com/skyscrapers/terraform-state//azurerm?ref=5.0.0"
  project  = "someproject"
  location = "North Europe"
}

After applying the module, you can configure your Terraform backend like this:

terraform {
  backend "azurerm" {
    key                  = "stacks/aks-cluster.tfstate"
    resource_group_name  = "terraform-remote-state-someproject"
    storage_account_name = "tfbackendsomeproject"
    container_name       = "tf-state"
  }
}

Expected Usage

I have a couple of questions about how you all intended this module to be used. I have an existing Terraform definition with an existing state for two workspaces: default and development.

terraform {
  backend "s3" {
    encrypt        = true
    bucket         = "app-terraform-remote-state-storage-s3"
    dynamodb_table = "app-terraform-remote-state-lock-dynamo"
    region         = "us-west-2"
    key            = "terraform.tfstate"
  }
}

Is the expectation that I'd add this as a module, change the bucket and dynamodb_table values to match module.s3.bucket_id and module.s3.locktable_id and all would be fine? Or is there some other expected workflow? e.g.

diff --git a/main.tf b/main.tf
index 93526f6..57bf1b8 100644
--- a/terraform.tf
+++ b/terraform.tf
@@ -17,14 +17,21 @@ provider "template" {
   version = "~> 1.0"
 }
 
+module "s3" {
+  source  = "github.com/skyscrapers/terraform-state//s3?ref=3.0.0"
+  project = "app"
+}
+
 terraform {
   required_version = "~> 0.11"
 
   backend "s3" {
     encrypt        = true
-    bucket         = "app-terraform-remote-state-storage-s3"
-    dynamodb_table = "app-terraform-remote-state-lock-dynamo"
+    bucket         = "terraform-remote-state-app"
+    dynamodb_table = "terraform-remote-state-lock-app"
     region         = "us-west-2"
     key            = "terraform.tfstate"
   }
 }

The reason I ask is that it seems to be a bit of a chicken and egg scenario. I need these resources before I can provision my environment so I can store state and yet it is will be part of the environment too.

Also, what is the expected way to handle multiple workspaces? It seems like switching workspaces will cause the environment to try and reprovision the state storage resources.

skyscrapers / terraform-state Goto Github PK

terraform-state's Introduction

terraform-state

s3

Available variables

Output

Example

Multi-account AWS Architecture

azurerm

Variables

Outputs

Examples

terraform-state's People

Contributors

Stargazers

Watchers

Forkers

terraform-state's Issues

Recommend Projects

Recommend Topics

Recommend Org