Zwing Docs

Setting Environment Variables

Backend

We use environment variables to make sure that none of the secret variables are not exposed to unauthorized party through codebase. We primarily follow two practices to manage environment variables, depending on the environment.

EnvironmentApproach
local.env file
staging,uat, prodAzure Key Vault

Local Env

For local environment, you only need to set the variables inside the .env file.

After adding in .env, you can read the env variable by using the following approach.

port: process.env.APP_PORT;

Other Env

For staging, production, uat environment, we make use of the Azure Key Vault service to secure our sensitive env variables.

If you want to add a new env variable, or modify an existing one. You will need to make changes in the two places.

1. Add a new secret in Key Vault

To add a new secret in the Key Vault, you will need to add it's terraform code inside the infrastructure repository. The infrastructure repository is a single repository for all of our in-house services. You will need to make a change in the corresponding service terraform.

Infrastructure Repo on Github

This repo is shared by multiple teams, so be aware.

  • staging - you can add the secret declaration inside the staging directory.
  • production - you will need to add the secret declaration inside the production directory.
  • uat - add them inside the uat directory.

You will need to add a similar azurerm_key_vault_secret resource block to the respective file, something like below.

resource "azurerm_key_vault_secret" "jwt_secret" {
  name         = "jwt-secret"
  value        = var.JWT_SECRET
  key_vault_id = module.crm_key_vault.key_vault_id
  tags         = module.default_tags.tags
}

Now, add the var.JWT_SECRET inside the corresponding variables.tf file.

variable "JWT_SECRET" {
  description = "JWT Secret"
  type        = string
  sensitive   = true
}

Noice 🔥 Once done, you are good to raise a PR, and get a quick review.

2. Update the helm chart

After creating/updating a secret in the Key Vault, we will now link to map the secret from Key Vault to our corresponding service in Kubernetes.

Since, we are multi-service team, we have multiple repositories which use helms in their own approach. For more information, you can refer to their corresponding docs.

RepositoryDocument
g1-notification-service
crm-servicesDoc Link
zwing-services
zwing-connect
g1-sso-services

Frontend

Edit on GitHub