Overview

AWS Components

Quandis leverages the following AWS components to host QBO3 websites.

• EC2 Instances
• Auto Scaling Groups
• Launch Configurations
• AWS Machine Images (AMIs)
• Elastic Load Balancers (ELBs)

All QBO3 web and application servers in AWS are EC2 Instances.

EC2 Instances are instantiated by AWS Auto Scaling Groups.

Auto Scaling groups are updated by creating a new AWS Launch Configuration.

Launch Configurations are based on an AWS Machine Image (AMI).

When an environment is to be updated, Quandis creates a new AMI of a Release box. A Release box is a single EC2 Instance that receives code deploys, and hosts a bare bones testing web site.

The AMI is then used to create a new Launch Configuration.

The Launch Configuration is then assigned to an existing Auto Scaling Group.

When the Auto Scaling group is updated with a new Launch Configuration, the Auto Scaling Group instantiates new EC2 Instances based on the Launch Configuration, and retires the previous EC2 Instances.

Auto Scaling Groups are assigned to an AWS Elastic Load Balancer (ELB).

Terms

A web server is a server intended to present the front end of a web site to a user.

• Web servers receive traffic from an AWS Elastic Load Balancer.

An application server is a server intended to run the QBO3 Queue Service.

• Application servers are not generally intended to be accessed by website users. This allows all processing power to be dedicated to processing items in the Queue Service.

Azure Devops deployments

The automated deploy process from Azure Devops to AWS consists of two patterns:

1. Deploying source code to a Release box
2. Promoting an Image of the Release box (AMI) to any upstream environments, such as UAT or PROD.

Quandis currently utilizes Azure DevOps Release Pipelines to implement these patterns.

These images demonstrate a sample deploy and promotion process:

Deploy to a Release box

The first stage is 'Deploy To Dev':

This Stage retrieves source code and other artifacts that result from Azure Devops Build Pipelines. The data are stored in Artifacts that can be referenced by Release Pipelines.

These artifacts are then deployed to an existing Release server. A Release server is a single AWS EC2 Instance web server. It is intended to provide the simplest configuration required to run a QBO3 website, and allow for configuration testing prior to promotion to upstream environments.

Additionally, the database attached to the Release server will be updated at this time.

Finally, automated front end regression tests are run against the Release environment.

Promote to UAT and PROD environments

Generally speaking, QBO3 sites are first promoted to a User Acceptance Testing (UAT) environment, and then to a Production (PROD) environment. Any number of environments can be configured, but for the purpose of this explanation we will assume two upstream environments after the Release server.

When the time for promotion comes, the Release server is imaged, and any EC2 Instances for upstream environments are clones of the Release server, based on the image. The imaging operation in AWS results in an AWS Machine Image (AWI).

After an AMI is available, the automated promotion follows this pattern:

• Update the database with any changes.
  • If needed, a database update script can be generated, and then the deployment paused, such that the database update script can be reviewed before updating the database.
• Create a new Launch Configuration based on the AMI, typically multiple Web Servers and App Servers
  • The Instances are automatically named and tagged based on parameters passed into the automated Release process
• Update the existing Auto Scaling Group for the given environment with the new Launch Configuration
  • The automation now directs the Auto Scaling Group to spin up the appropriate number of new EC2 Instances, and waits for them to report a Healthy status before retiring the old EC2 Instances. In this way, website downtime is prevented.
• Run all setup packages assigned to a given environment.
  • Setup packages are XML files that document and update system settings.
  • These packages are running by making an HTTP request against the given environment.
• Run automated front end regression tests against the given environment.
• If necessary, update any monitoring services such as LogicMonitor with information about the new EC2 Instances.