Organizing state with workspaces using the S3 backend for multiple terraform projects

[Carter Bancroft]

The workspaces concept using the S3 backend seems to force separate services towards being in their own bucket and I'm wondering if there are strategies for avoiding this, or if maybe I'm using Terraform wrong.

Say I have two hypothetical services that are distinct and have their own associated infrastructure, an internal API and a public API. How could I keep state contained to a project within the same bucket in S3 and still support workspaces?

This is what I ideally want

my-terraform-bucket
    internal_api
        env:
            default
            some-other-workspace
    public_api
        env:
            default
            some-other-workspace
            yet-another-workspace

However the root workspace directory (env:) is put at the top level of the bucket which means to do what I want I would have to organize distinct projects into separate buckets like...

my-internal-api-terraform-bucket
    env:
        default
        some-other-workspace


my-public-api-terraform-bucket
    env:
        default
        some-other-workspace
        yet-another-workspace

Am I misunderstanding this or perhaps even misusing terraform?

[Thomas PERELLE]

Hello, 

Look à the s3 backent documentation : 

https://www.terraform.io/docs/backends/types/s3.html

And especially the workspace_key_prefix

If you put your service name as workspace_key_fixe it will bring the separation you want no ?

workspace_key_prefixe = service name

workspace_name = env name

Key = tfstate or other name for state file

Cordialement,

Thomas Perelle
DevOps & Containerization Consultant
Docker official instructor

t.pe...@treeptik.fr
+33 442370635
+33 661985726

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/ab6a26d6-62a6-44c9-9c80-f55c7fd812d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carter Bancroft]

Hi Thomas,

Thanks for the fast response! That looks like it might do it, I didn't read the documentation closely enough apparently. Let me try it out.

To unsubscribe from this group and stop receiving emails from it, send an email to terrafo...@googlegroups.com.

[Carter Bancroft]

So this basically worked but it's difficult for me to wrap my mind around in the default workspace case. From the docs and experimentation it seems like workspace_key_prefix is ignored in the case of the default workspace, is that right? 

terraform {
  backend "s3" {
    bucket = "my-bucket"
    region = "us-east-1"
    key = "terraform.tfstate"
    workspace_key_prefix = "prefix"
  }
}

With a configuration like this default workspace state would just go right into the root of my-bucket correct? I want it to be in the workspace_key_prefix directory along side the other workspaces. Is the idea that if you're working with workspaces you should just not use the default workspace?

This would be ideal...

my-bucket
    prefix
        default
            terraform.tfstate
        some-workspace
            terraform.tfstate

But I think it does...

my-bucket

    terraform.tfstate
    prefix
        some-workspace
            terraform.tfstate

The goal here is to allow developers to branch state and not work against the default one when working on PRs that change terraform config. Maybe I should create a master state and treat that as default and just never use default.

On Tuesday, April 9, 2019 at 11:31:00 AM UTC-8, Thomas PERELLE wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to terrafo...@googlegroups.com.

[Thomas PERELLE]

Yes the state file for the default workspace ignores all workspace configuration including workspace_key_prefix.

I don’t know what you want to do with the default workspace related to the other.

Personally I don’t use it when I use workspaces, especially for having an homogeneous organization.

Look at this documentation about Terraform good practices, there is some interesting things about workspaces :

https://www.terraform.io/docs/enterprise/guides/recommended-practices/part1.html#one-workspace-per-environment-per-terraform-configuration

Cordialement,

Thomas Perelle
DevOps & Containerization Consultant
Docker official instructor

t.pe...@treeptik.fr
+33 442370635
+33 661985726

To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/5b900f70-95bb-496f-b408-7dcdce9a14bf%40googlegroups.com.

[Carter Bancroft]

Thanks. My understanding of similar concepts revolves around Git a lot. It made sense to me to think of workspaces like branches (which is sort of how we'd like to use them) and the documentation even says that if you haven't intentionally used workspaces before you are still using the default workspace. In my mind if made sense that the default workspace wouldn't be a special case (other than in the minds of the engineers) much like master branches aren't a special case technically in git. I was planning to use default as master but I don't think that will work.

I'm checking out the documentation. We aren't using Terraform Enterprise so I've mostly ignored TE documentation... I suppose I should have looked at it.

Anyway, thanks again for your help on this, the learning curve has been steeper than I was expecting.

[Carter Bancroft]

Maybe I'm misreading but from that documentation it seems like even Terraform Enterprise doesn't yet have a model for branching state, working on it and then merging it back to a master branch of production (or whatever environment).

Our goal has been to be able to make running terraform plan a part of the build process so that plans can be reviewed by other engineers without have to run the code locally and manually. We wanted the Terraform state to exist in a branch separate from the main state and I thought I could accomplish this via terraform workspaces on terraform open source. It's starting to feel like it might be best to role our own solution to this... creating some sort of checkout script that will copy the state in the backend to a new branch folder and making our build process and the local process work against that. 

I'm still trying to figure out if I'm just missing something though.