Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

DRAFT

Overview

Voluntarily has various service endpoints Managing Access to open platforms and this page gives a high level overview on how these are set up.

Deployment Design

Our services are deployed on AWS, connected to an externally managed database(mongodb).

Components:

  • ECR to store our images for each environment(aplha, beta, gamma, live).

  • ECS(fargate) to deploy our container service(one each for all environments).

  • Network for our services attached to internet gateway for external access and some security groups and route table for managing traffic access.

  • Load balancer to manage traffic to our service.

  • route53 holding 'A records for all our services.

Infrastructure

Currently we have aws folder in the voluntarily repo containing cloudformation scripts and few other bash scripts that will deploy each environment based on environment specific config file. This is a manual setup for each environment.

Voluntarily Service

Once the infrastructure is setup, it will deploy the service based on task definitions for the ECS cluster. The CI pipeline then builds and pushes new image to ECR and runs a update command for ECS service to pull the latest image to roll out a new version of service. CI only deploys alpha and beta currently, other environments are deployed manually.

Environment Setup

Currently, at docker build time, we pass in a parameter which specifies what kind of image to build- for what environment. Based on certain keyword(alpha, beta, gamma), during docker build time, the. application will use this information and decrypt the appropriate encoded env file and load the environment variables. The image is then built and pushed to ECR.

Proposals/Options to think for future

Docker image

Currently we use build to determine environment type and create image specifically for each environment. This creates an image baked with variables meaning if any of those change, we have to rebuild image.

Proposal is to isolate environment specific variable setup from application, have env vars pushed to container scope so if these are to change, all we need to do is to update environment and restart container. This will mean we can have one image, and have multiple environments using same image but are different setups due. to having different environment variables.

Build

Currently, we have scripts to update deployments and CI build only updates alpha/beta depending on the environment variable in build file.

Proposal is to have build trigger deployments to any environment automatically. We can leverage git tagging and CI pipeline conditionals to deploy to various environments based on tag.

Things missing here:

  • cloudflare setup

  • monitoring and metrics

  • No labels