Answers: <p>Workspaces are an unnecessary complexity which causes the possibility that you destroy your prod environment (or leak secrets). It is a much better practice to switch backends, and that is noted in the docs:<br />
  <a href="https://www.terraform.io/language/state/workspaces" rel="nofollow noreferrer">https://www.terraform.io/language/state/workspaces</a></p>
  <blockquote>
  <p>In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.</p>
  <p><strong>Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend.</strong> In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.</p>
  </blockquote>
  <p>The new hotness is a backend file, which you can choose at init:<br />
  <a href="https://www.terraform.io/language/settings/backends/configuration#file" rel="nofollow noreferrer">https://www.terraform.io/language/settings/backends/configuration#file</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-24T05:41:32.627Z
Answers: The question specifically mentions backends, but I feel that doc quote (and edit) answers this question because it at least shows that _not_ using workspaces and instead using modules is the suggested method to get this done and not just something the author is doing. Kind of makes workspaces feel hacky to have all that functionality and suggest people just not use them for a very a common use case.
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-01-25T01:29:00.120Z
Answers: Would you be able to share more details on how https://www.terraform.io/language/settings/backends/configuration#file can be used to replace workspaces? Also, I have been using terraform workspaces to manage provisioning of same resources across multiple environments and I find it quite effective.
Answers: Biju
Answers: CC BY-SA 4.0
Answers: 2022-01-26T04:18:39.670Z
Answers: He actually picks this back up at 304 and explains it a bit https://devops.stackexchange.com/a/15335/18965
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-01-24T05:28:17.490Z
Answers: 2022-01-24T21:19:04.300Z
Answers: 2022-01-24T21:19:04.300Z
Answers: matttrach
Answers: <p>Digging down further into the book, the author picks this back up on page 304.</p>
  <blockquote>
  <p><strong>...a 1:1 representation...</strong> If I browse your <em>live</em> repository, I should be able to see, from a quick scan, what resources have been deployed in what environments. That is, <strong>every resource should have a 1:1 match with some line of code checked into the live repo.</strong> This sems obvious at first glance, but it's surprisingly easy to get wrong. [...] A more subtle way to get it wrong is to use Terraform workspaces to manage environments, so that the live infrastructure is there, but the code isn't. <strong>That is, if you use workspaces your live repo will have only one copy of the code, even though you may have 3 or 30 environments deployed with it. From merely looking at the code, there will be no way to know what is actually deployed</strong>, which will lead to mistakes and make maintenance complicated. Therefore, as described in &quot;Isolation via Workspaces&quot; on page 88, instead of using workspaces to manage environments, <strong>you want each environment defined in a seperate folder, using separate files, so that you can see exactly what environments have been deployed just by browsing the <em>live</em> repository.</strong></p>
  </blockquote>
  <p>So it seems one of the author's scruples though described as <em>&quot;not visible in the code or on the terminal&quot;</em> is more general and extends to tooling (like web svc browsers, ex., GitHub) which do not support Terraform workspaces. The author wants to know where the code deployed without pulling it down. Such that he can see what is on development and production without using a &quot;workspace&quot;.</p>
  <p>He later extends this to the entirety of Git branching which is slightly more bizarre, because his problem there is even smaller (pg 304),</p>
  <blockquote>
  <p>Unfortunately, [branching] only solves part of the problem. Even though the Terraform backends provide locking for Terraform state, they cannot help you with locking at the level of the Terraform code itself. <strong>In particular if two team members are deploying the same code to the same environment but from different branches, you'll run into conflicts that locking can't prevent.</strong></p>
  </blockquote>
  <p>But sure, certainly <em>&quot;deploying the same code to the same environment but from different branches&quot;</em> sounds lke a real bad idea.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-26T04:14:28.413Z
Answers: 2022-01-26T04:14:28.413Z
Answers: Evan Carroll
Body: <p>I'm reading the <a href="https://www.oreilly.com/library/view/terraform-up/9781492046899/" rel="nofollow noreferrer"><em>&quot;Terraform: Up &amp; Running, 2nd Edition&quot;</em> book by Yevgeniy Brikman</a>, the author is going through a lot of work to <em>NOT</em> use workspaces? Is this sound? It seems like really esoteric. His reasoning is as follows:</p>
  <blockquote>
  <p><em>&quot;The state files for all of your workspaces are stored in the same backend [...] Workspaces are not visible in the code or on the terminal unless you run <code>terraform workspace</code> [...] Putting the two previous items together, the result is that workspaces can be fairly error prone.&quot;</em></p>
  </blockquote>
  <p>As to the second point, why not just add the workspace to your your PS1 if that's an issue? Using something like ZSH/PowerLevel10k, my prompt shows Terraform workspace information.</p>
  <p>As far as the first point, I broke that off into <a href="https://devops.stackexchange.com/q/15301/18965">separate question</a>.</p>
  <p>Is there anything else that I'm missing in this workspace vs directories for isolation.</p>
  
Tags: <terraform><deployment><terraform-workspace>
Title: Terraform workspaces vs isolated directories?
UserDisplayName: Evan Carroll
ThreadText: # Terraform workspaces vs isolated directories?
  
  (Asked by: username_0 on 2022-01-23)
  
  I'm reading the [*"Terraform: Up & Running, 2nd Edition"* book by Yevgeniy Brikman](https://www.oreilly.com/library/view/terraform-up/9781492046899/), the author is going through a lot of work to *NOT* use workspaces? Is this sound? It seems like really esoteric. His reasoning is as follows:
  
  > *"The state files for all of your workspaces are stored in the same backend [...] Workspaces are not visible in the code or on the terminal unless you run `terraform workspace` [...] Putting the two previous items together, the result is that workspaces can be fairly error prone."*
  
  As to the second point, why not just add the workspace to your your PS1 if that's an issue? Using something like ZSH/PowerLevel10k, my prompt shows Terraform workspace information.
  
  As far as the first point, I broke that off into [separate question](https://devops.stackexchange.com/q/15301/18965).
  
  Is there anything else that I'm missing in this workspace vs directories for isolation.
  
  **Tags:** terraform, deployment, terraform-workspace
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-01-24. Score: 1 | Accepted answer
  
  Workspaces are an unnecessary complexity which causes the possibility that you destroy your prod environment (or leak secrets). It is a much better practice to switch backends, and that is noted in the docs:  
  <https://www.terraform.io/language/state/workspaces>
  
  > In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.
  >
  > **Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend.** In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.
  
  The new hotness is a backend file, which you can choose at init:  
  <https://www.terraform.io/language/settings/backends/configuration#file>
  
  > **Comments:**
  > **username_0**: The question specifically mentions backends, but I feel that doc quote (and edit) answers this question because it at least shows that _not_ using workspaces and instead using modules is the suggested method to get this done and not just something the author is doing. Kind of makes workspaces feel hacky to have all that functionality and suggest people just not use them for a very a common use case.  
  > **username_2**: Would you be able to share more details on how https://www.terraform.io/language/settings/backends/configuration#file can be used to replace workspaces? Also, I have been using terraform workspaces to manage provisioning of same resources across multiple environments and I find it quite effective.  
  > **username_0**: He actually picks this back up at 304 and explains it a bit https://devops.stackexchange.com/a/15335/18965  
  
  ---
  
  ### Answer by username_0 on 2022-01-26. Score: 0
  
  Digging down further into the book, the author picks this back up on page 304.
  
  > **...a 1:1 representation...** If I browse your *live* repository, I should be able to see, from a quick scan, what resources have been deployed in what environments. That is, **every resource should have a 1:1 match with some line of code checked into the live repo.** This sems obvious at first glance, but it's surprisingly easy to get wrong. [...] A more subtle way to get it wrong is to use Terraform workspaces to manage environments, so that the live infrastructure is there, but the code isn't. **That is, if you use workspaces your live repo will have only one copy of the code, even though you may have 3 or 30 environments deployed with it. From merely looking at the code, there will be no way to know what is actually deployed**, which will lead to mistakes and make maintenance complicated. Therefore, as described in "Isolation via Workspaces" on page 88, instead of using workspaces to manage environments, **you want each environment defined in a seperate folder, using separate files, so that you can see exactly what environments have been deployed just by browsing the *live* repository.**
  
  So it seems one of the author's scruples though described as *"not visible in the code or on the terminal"* is more general and extends to tooling (like web svc browsers, ex., GitHub) which do not support Terraform workspaces. The author wants to know where the code deployed without pulling it down. Such that he can see what is on development and production without using a "workspace".
  
  He later extends this to the entirety of Git branching which is slightly more bizarre, because his problem there is even smaller (pg 304),
  
  > Unfortunately, [branching] only solves part of the problem. Even though the Terraform backends provide locking for Terraform state, they cannot help you with locking at the level of the Terraform code itself. **In particular if two team members are deploying the same code to the same environment but from different branches, you'll run into conflicts that locking can't prevent.**
  
  But sure, certainly *"deploying the same code to the same environment but from different branches"* sounds lke a real bad idea.
  
  
  ---
  
  