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.
env0 supports any repo structure your org currently uses. These are the following considerations to take into account when using env0.
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?
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.
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).
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).
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.
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.
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?
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.
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.
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.
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.
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.
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.
Updated about 2 months ago