ECS Deity

Creates and destroys on-demand environments through separate ECS services. Works on ECS and Fargate.

How it works

ECS Deity provisions on-demand testing environments based on github branch names by creating separate ECS services on the same testing cluster. On creation, it creates a target group and listner and assigns a random unused port to a shared ALB and creates a branch-specific service based on a currently deployed task definition. On destruction, the proccess is reversed, after stopping all running tasks. Step functins are used for orchestration.

For example, when a branch named feature/test123 is pushed for a repository named my-project, the following is created:

• Target group named my-project-test123-tg
• ALB listner with a random port which routes to the target group
• ECS service named my-project-test123-service

Any necessary app-specific deployments like database migration, data loading, etc. are de-coupled. A lambda arn is configurable for such tasks.

Notifications to the user are sent via SNS.

Pre-requisites

An ECS cluster using dynamic ALB, with a base service deployed by a sample definition. A system which consumes SNS for notifying users (not provided) A lambda function which handles deployment (can be blank)

Install

npm install -g serverless
sls plugin install -n serverless-step-functions
sls plugin install -n serverless-pseudo-parameters
sls plugin install -n serverless-prune-plugin

Deploy

Edit conf.yml

sls deploy -s dev

Configure

YAML file

look at conf.yml.example

GitHub

1. Add API Gateways's endpoint as GitHub's webhook (https://xxxx/github)
2. Configure trigger events (create, delete)

Notification

To receive Slack notifications, create a lambda function which consumes the notification SNS and posts to Slack. Example here: https://github.com/ijin/sns-slack

Notification is de-coupled, since including the function in this project will create unnecessary duplicates for multiple configurations.

Deployment

The deployment lambda fits to your project's needs. If using CircleCI, you can simply call the API with build_parameters[CIRCLE_JOB]=build from lambda. Tasks may include databae migration, data loading, etc. A blank lambda function can be set if deployment is unnecessary.

CircleCI

It's best to only build on pull requests if you use CircleCI for deployments to avoid double runs.

ChatOps

You can also manually create environments through chatops.

Steps.

0. optionally disable github's create trigger
1. create a serverless framework stage environment (this will be your trigger word. ex. dev)
2. configure slack's outgoing webhook to the API gw path (https://xxxx/chat_ops) and set the trigger to the above stage (ex. dev) in a desired channel
3. create an environment by typing [stage] [branch] (ex. dev feature/test) in the configured channel

Happy Chat-Opsing!