README.md

Infrastructure

• 1.1. Dependencies
• 1.2. Deploying new environments
  • 1.2.1. The "environments" variables
  • 1.2.2. Handling production and staging

---

1.1. Dependencies

• AWS
• Terraform + Terragrunt
• Kubectl

1.2. Deploying new environments

The infrastructure is deployed using Terraform, and set up in a way that makes it very easy to deploy new, independent copies of the app - environments. To do this, do the following:

• Modify infrastructure/kubernetes/vars/terraform.tfvars (or whichever file you're using) to add the key/value to the environments variable. The kubernetes deployments may fail to deploy at this stage.
• Run terragrunt apply
• Edit both the deploy-to-kubernetes.yml and publish-docker-images.yml Github actions files and add the name of the new branch that will match your deployment. Try to keep it simple (one word, no spaces, no special characters). Push it and wait for Github Action to finish processing.
• Apply the kubernetes project above once more. The deployments should succeed.

1.2.1. The "environments" variables

The environments variables can hold complex values that control many aspects of the deployment, so it's worth analyzing in detail. There are two variables of this type: aws_environments and gcp_environments. They both work in the same way, with the first one controlling deployments to AWS, while the second one controls GCP deployments

aws_environments = {
	sample : {
		api_env_vars : [
			{
				name : "ENV_VAR_NAME"
				value : "some-value"
			}
		],
		load_fresh_data : true,
		data_import_arguments : ["seed-data"],
		image_tag : "sample"
	}
}

environments is a key-value structure. The key (sample in the above example) represents the name of the deployment and will be used for many aspects of the deployment, like subdomain generation, docker image tagging, git branching, etc.

The value in the key-value pair is an object with a set of properties, all of them optional

• api_env_vars: a list of objects, each of which with name and value. Used to inject non-sensitive environment variables to the api application. Internally, other environment variables are merged with this list, the result of which is applied to the kubernetes deployment. Environment variables defined here will overlap default env vars defined for the api pods. Defaults to an empty list.
• tiler_env_vars: a list of objects, each of which with name and value. Used to inject non-sensitive environment variables to the tiler application. Internally, other environment variables are merged with this list, the result of which is applied to the kubernetes deployment. There is no handling yet for overlapping environment variables name. TODO Defaults to an empty list.
• load_fresh_data: if "true", it will create a new node group, and start the data importer process in that group. Said node group is NOT automatically destroyed upon data import completion, so be sure to set it to "false" and apply terraform again once the import process is over, to save costs. Defaults to "false"
• data_import_arguments: array of string arguments passed to the data import docker container on startup, when called as part of the initial data import process. Defaults to ["seed-data"]
• image_tag: tag of the different docker images to pull from the container registry. Does not apply to the Redis image. Defaults to the same value as key.

1.2.2. Handling production and staging

The AWS production and staging environments deploy on a different manner. Please refer to infrastructure/kubernetes/main.tf on the aws_environments module for more details. However, you can still customize their behavior (for example, reload fresh data), you can explicitly add them to the environments variable, and specify your custom values for each configuration, as you would for any other env.

---

↩️ GO TO ROOT DOC