Review your Setup

Introduction

Migrating from HashiCorp Terraform Cloud to env0 requires a comprehensive review of your existing setup to ensure a smooth transition. In this blog post, we will delve into key considerations for each aspect of your setup, including the repo structure, modules, secrets, and variables. By thoroughly understanding and evaluating these elements, you can effectively plan and execute a successful migration to env0.

Repo Structure

env0 supports any repo structure your org currently uses. These are the following considerations to take into account when using env0.

Mono Repo

If your infrastructure code is stored in a mono repository, where multiple projects are managed within a single repository, review the structure and organization of your code. Evaluate the impact of migrating to env0 and ensure that the new setup aligns with your team's workflows and preferences. Do/will all developers have access? Do you have module repositories? Will your policy code also be in this repo?

Self-Hosted Git Servers

For teams using self-hosted git servers, like GitLab EE, BitBucket DataCenter, or GitHub Enterprise (on-prem), env0 requires the use of the self-hosted agent in order to communicate with your private, self-hosted git server.

Each instance of your self-hosted git server will require its own self-hosted agent. For example, if you have multiple BitBucket DataCenter instances, and will be provisioning infrastructure code from them, you will need one self-hosted agent per BB DataCenter.

Module Source

There are benefits and considerations for each type of module source. A relative or local source means that the module code is in the same repo as your current terraform code. A git source means you’re currently using https:// or ssh:// git URLs and may or may not be using ref to pin to a specific branch or tag of the module. A Terraform registry, means you’re using either a public or private module registry (that follows the TF module protocol).

Local

For relative or local source modules, you can take advantage of env0’s Continuous Deployment trigger setting - **Changes by file filter pattern.** This setting allows you to configure env0 to trigger on module changes as well as the template or root module changes. For example, if you manage your own ec2 module, and you have a root module that references the ec2 module (source = “../module/ec2”), you can configure env0 to listen to changes in both the module folder (module/ec2) and the root module (/acme-dev-ec2).

Git

When using git source modules with env0, you should be aware that https paths require a token to authenticate with the git server, and ssh paths require an ssh key. In env0, you can easily attach an ssh key to your environment or template. And to configure a token, you will need to use an env0 custom-flow to configure the git configs for the runner.

Registry

If you rely on modules from the Terraform Registry, you can continue to use those with env0. Alternatively, you can consider using env0 module registry. The biggest benefit of using a module registry is the ability to use the right-most version constraint ~>. For example, version = “~>1.0.0”. This means that when the module has been updated to version 1.0.1, your Terraform code will automatically pull the updated version on the next deployment. This also means, combining this behavior with env0 drift detection, you will be able to know if your environment needs to be updated due to a change in your module code.

Secrets

Secrets Manager - Integrated in Code

Do you currently manage your secrets in your terraform code, for example using HashiCorp Vault provider? Is this how you want to manage secrets going forward? Or do you want less dependency in your terraform code? Who has access to manage the code, and create secrets?

env0 UI

Assess the option of managing secrets directly within the env0 user interface. Explore the capabilities of env0's built-in secrets management features and evaluate if this approach aligns with your company's security requirements and best practices. env0 allows you to save secrets at various organizational levels, such as the Organization level, Project level, or Template level.

Self Hosted Agent users must store secrets in your company’s secret manager such as AWS Secrets Manager or HashiCorp Vault. The secret is then referenced from the UI through a specific syntax for env0 to fetch the value. See our docs on Secrets and Variables for more information.

Variables

Do you want to keep your variables in code, a key-value store, or in the UI for ease of visibility and accessibility? Review how variable values are currently managed in your Terraform deployment process. Verify that all the required variables are identified for proper migration to env0. Evaluate the benefits of configuring variables through a tfvar , directly in env0 UI, or through a key-value store, and assess if this approach aligns with your team's preferences and requirements. Plan and configure the necessary variable definitions within env0 to enable seamless migration and ongoing management.

Config as Code (e.g. *.tfvars or data blocks)

Some customers prefer to keep the configuration as code, and thus, with Terraform define their variables through a tfvar file or link parameter values with data blocks. With env0, you can simply continue to use your data blocks or specify which tfvar file to use with ENV0_TERRAFORM_CONFIG_FILE_PATH as described in our docs for custom variable file. Configuration as code with a tfvar is easily auditable and verifiable. However, for self-service users, this could make interaction difficult, as they may not have access to the repo where the configuration code resides, and thus cannot make changes, or see the values.

UI Configuration

Other customers, especially in terms of self-service deployments, prefer the ability to manage their configuration in env0’s UI. Consider the option of managing variables through the env0 user interface. Taking advantage of env0 variable hierarchy, you can you define variables for reusability at the Organization, Project, or Template levels.
UI is easily visible through the UI, but configuration code is now in a 3rd party system (env0) and no longer committed to code.

Run-time

Similar to a local-provisioner in native terraform code, and a generic custom web-hook step in most CI/CD tools, env0 allows you to call scripts prior to terraform init. This allows you to call custom api to fetch and populate required variables during runtime, whether through a secrets engine like HashiCorp vault, or through a key-value configuration management store like AWS parameter store, or HashiCorp Consul. Read more about Custom Flow.
This is dynamic and adaptable, but it is not always easy to see (maybe purposefully) what variables or secrets that were configured at run-time. Also, there’s overhead in maintenance for the custom calls and mapping of variables.

Next Steps

Now that you’ve had a chance to consider the configuration setup of your workspaces, the next step is to review your current and desired IaC provisioning process and learn how env0 can help replicate or augment your process.