.svg)
As you’re getting started with env0, you might start asking, how should I organize and configure my account? Especially if you’re coming from Terraform Cloud/Enterprise, and were confined and limited to simply just Workspaces; now, you have so much flexibility, it’s almost like a kid at a candy store! The purpose of this blog post is to help give you some ways to think about how to structure your env0 environment while giving you the most flexibility, reusability, and security.
Definitions
Organization — this is the top level domain, where we can set “global” variables, configure users vs admins, and it wraps all the Projects.
Template — this is a set of IaC resources that can be deployed, and typically references a Terraform module or a set of .tf files defined in a directory within your git repository.
Project — this is a logical grouping of environments and templates. A template can be assigned to one or more projects.
Environment — this is an actual run of a template. In the case of Terraform based templates, an environment is equivalent to a Terraform workspace. users can create new environments or import existing workspaces.
Org Admin — this role manages all the projects and users
Org User — a user that can be assigned a specific project role, in one or more projects
Project Admin — this is the admin of the project
Project Deployer — can import, create, apply, and destroy environments
Project Planner — can initiate runs, but cannot apply or destroy
Project Viewer — can see the history of runs
Different Use Cases Calls for Different Setups
Are you giving your developers the ability to manage their own infrastructure? Or, are you seeking to manage long-running infrastructure? Each use case requires a slightly different configuration, and we will provide our best-practice methods for configuring your env0 environment.
Self-Service Environments
We describe self-service when your devs want to be able to deploy their own ephemeral environments. Let’s start by assuming we have a central devops team and some engineering teams. The devops team has an internal mandate to improve and increase developer efficiency and productivity.
Here, the engineering team requires infrastructure for development and testing. However, due to corporate policies as well as security controls, the engineers are not given access to the cloud credentials. In this case, the central devops team would define a certain set of Terraform modules as templates that would be made available to each engineering team. Each engineering team would also be assigned as a deployer to a project.
Using env0’s policies and cost-monitoring features, you can also set TTLs and associate cloud spend per team.
Ephemeral Environments by Feature Branch
An ephemeral environment, by definition, is meant to be short-lived. With access to cloud resources, we now have the capability to create ad-hoc environments on-demand. The problem is IT organizations have created red-tape to slow down a developer’s access to said resources. In this use case, we seek to automate the process of creating the environment, by integrating with your source control.
We can take advantage of env0’s Terraform provider, or env0’s API to dynamically create an environment based on a new feature branch in your source control. Whether you’re using GitHub, or BitBucket server, developers can immediately access and test their changes before pushing to main. Who doesn’t love a developer that tests their own code?
Check out these previous blog posts (here and here) for an example of using GitHub actions to create an ephemeral environment. And we also use this workflow at env0!
On a high level, you would follow a similar approach to the self-serve model, but now instead of manually creating the environment, you trigger the workflow through a CI tool like Jenkins, or GitHub Actions.
Static Environments — Production Deployments
Traditionally, IaC refers to long standing infrastructure, so there is no doubt that your company’s flagship service needs to be up and running 24/7. What happens though when the IT team member that created the infrastructure takes time off? How do you track what variables were used to create said infrastructure? No kidding, I was just talking to a customer who said, I need to make a hotfix now but I have no idea how he (the devops guy) ran the terraform script, and he’s on vacation!
env0’s solves this with a simple UI/UX, allowing you to track the variables used. Along with templates and variable scoping, we can implement DRY (don’t repeat yourself) methodologies.
Simply define your production templates, add the appropriate variables at each level and configure them for continuous deployment (i.e. trigger when a merge to main occurs).
If you want a demonstration on how we use env0, simply reach us at contact@env0.com or schedule a demo.
As you’re getting started with env0, you might start asking, how should I organize and configure my account? Especially if you’re coming from Terraform Cloud/Enterprise, and were confined and limited to simply just Workspaces; now, you have so much flexibility, it’s almost like a kid at a candy store! The purpose of this blog post is to help give you some ways to think about how to structure your env0 environment while giving you the most flexibility, reusability, and security.
Definitions
Organization — this is the top level domain, where we can set “global” variables, configure users vs admins, and it wraps all the Projects.
Template — this is a set of IaC resources that can be deployed, and typically references a Terraform module or a set of .tf files defined in a directory within your git repository.
Project — this is a logical grouping of environments and templates. A template can be assigned to one or more projects.
Environment — this is an actual run of a template. In the case of Terraform based templates, an environment is equivalent to a Terraform workspace. users can create new environments or import existing workspaces.
Org Admin — this role manages all the projects and users
Org User — a user that can be assigned a specific project role, in one or more projects
Project Admin — this is the admin of the project
Project Deployer — can import, create, apply, and destroy environments
Project Planner — can initiate runs, but cannot apply or destroy
Project Viewer — can see the history of runs
Different Use Cases Calls for Different Setups
Are you giving your developers the ability to manage their own infrastructure? Or, are you seeking to manage long-running infrastructure? Each use case requires a slightly different configuration, and we will provide our best-practice methods for configuring your env0 environment.
Self-Service Environments
We describe self-service when your devs want to be able to deploy their own ephemeral environments. Let’s start by assuming we have a central devops team and some engineering teams. The devops team has an internal mandate to improve and increase developer efficiency and productivity.
Here, the engineering team requires infrastructure for development and testing. However, due to corporate policies as well as security controls, the engineers are not given access to the cloud credentials. In this case, the central devops team would define a certain set of Terraform modules as templates that would be made available to each engineering team. Each engineering team would also be assigned as a deployer to a project.
Using env0’s policies and cost-monitoring features, you can also set TTLs and associate cloud spend per team.
Ephemeral Environments by Feature Branch
An ephemeral environment, by definition, is meant to be short-lived. With access to cloud resources, we now have the capability to create ad-hoc environments on-demand. The problem is IT organizations have created red-tape to slow down a developer’s access to said resources. In this use case, we seek to automate the process of creating the environment, by integrating with your source control.
We can take advantage of env0’s Terraform provider, or env0’s API to dynamically create an environment based on a new feature branch in your source control. Whether you’re using GitHub, or BitBucket server, developers can immediately access and test their changes before pushing to main. Who doesn’t love a developer that tests their own code?
Check out these previous blog posts (here and here) for an example of using GitHub actions to create an ephemeral environment. And we also use this workflow at env0!
On a high level, you would follow a similar approach to the self-serve model, but now instead of manually creating the environment, you trigger the workflow through a CI tool like Jenkins, or GitHub Actions.
Static Environments — Production Deployments
Traditionally, IaC refers to long standing infrastructure, so there is no doubt that your company’s flagship service needs to be up and running 24/7. What happens though when the IT team member that created the infrastructure takes time off? How do you track what variables were used to create said infrastructure? No kidding, I was just talking to a customer who said, I need to make a hotfix now but I have no idea how he (the devops guy) ran the terraform script, and he’s on vacation!
env0’s solves this with a simple UI/UX, allowing you to track the variables used. Along with templates and variable scoping, we can implement DRY (don’t repeat yourself) methodologies.
Simply define your production templates, add the appropriate variables at each level and configure them for continuous deployment (i.e. trigger when a merge to main occurs).
If you want a demonstration on how we use env0, simply reach us at contact@env0.com or schedule a demo.
.png)
.png)
