Updating Author and Live Environments

Overview

Elastic Path provides an automated process with Jenkins jobs to deploy new versions of Elastic Path Containers, because manual deployment to a live system are tedious when you run them concurrently with database updates. With Jenkins jobs, the process is repeatable and less prone to errors.

Note: This update process is to update a deployment that is not under active load. Contact Elastic Path Support for more information about updating a deployment that is under active load.

Redeployment Workflow

You must redeploy the Author and Live environment in steps. For an Author and Live environment, you must run the redeployment jobs once for the Author environment, and then again for the Live environment.

1. Build a new deployment package from your Elastic Path Commerce source code using the BuildCommerce job in the CloudOps Jenkins console.

2. Build and tag a new set of Elastic Path Docker images using the BuildEPImage job.

3. Create a redeployment staging script by running the UpdateAuthorAndLive_1_StageUpdates job.

   For the Jenkins job parameter APPLICATIONS_STACK_NAME, use either the Author or Live Application CloudFormation stack name from your original Author and Live deployment. For Example:

   • EP-Author-And-Live-Environment-1-AuthorEpServicesInstance-xyz
   • EP-Author-And-Live-Environment-1-LiveEpServicesInstance-xyz

   Warning: Do Not use the root CloudFormation stack name for the Jenkins parameter APPLICATIONS_STACK_NAME. This can lead to an unintended reset of your database.

   When running with database updates, set the Jenkins job parameter RDS_STACK_NAME to either the Author or Live RDS (Relational Database Service) CloudFormation stack name from your original Author and Live deployment. For Example:

   • EP-Author-And-Live-Environment-2-AuthorRdsInstance-xyz
   • EP-Author-And-Live-Environment-2-LiveRdsInstance-xyz

4. Go to the staging directory in your Amazon S3 bucket for CloudOps. Find the script that is automatically generated by the UpdateAuthorAndLive_1_StageUpdates job.

   The script is named staging.sh and is stored under the folder name provided by the STAGING_DIRECTORY_S3_URI job parameter.

5. Review the AWS (Amazon Web Services) CLI commands that will be run.

6. Run the script using the UpdateAuthorAndLive_2_ApplyUpdates job, pointing at the staging script in Amazon S3.

7. Go to the UpdateAuthorAndLive_2_ApplyUpdates job console log and the event log in the CloudFormation console for your stack and confirm the changes are made

Redeployment Methods

Elastic Path recommends the cfUpdateNoDownTime redeployment method. UpdateAuthorAndLive_1_StageUpdates job calls the Update-Stack-Services.sh script using the cfUpdateNoDownTime redeployment method. You can also change the redeployment method to taskDefUpdate or taskDefUpdateNoDownTime.

cfUpdateNoDownTime

The cfUpdateNoDownTime redeployment method implements zero-downtime redeployments using the update-stack AWS CLI command to update the version of the Docker containers that are used in that stack. The update-stack command runs a redeployment with a minimum healthy percent of 100 and maximum of 200. This command starts the new containers before tearing down the old ones. For this, the ECS (Elastic Container Service) cluster for any container service in the stack must have enough additional EC2 instances to host the new containers during the redeployment.

During normal operations, most of the ECS clusters do not contain the additional container hosts required for a zero downtime redeployment, so before the update-stack command is run, the size of any autoscaling groups in the stack is doubled.

After the stack update is complete, the autoscaling groups are scaled back down. Scaling up the ECS cluster triggers a scale down policy in some stacks. To avoid this, the staging script suspends autoscaling events from alarm notifications before doubling the cluster size, and turns them back on after the cluster size is scaled down.

If this redeployment is run with database changes, the changes are applied before the Docker containers are updated. New and old applications make calls to the database at the same time, so the database changes must be backwards compatible.

taskDefUpdate

The taskDefUpdate redeployment method updates the task definition for each service in the stack instead of updating the stack itself, and uses a minimum healthy percent of 0 and maximum of 100. All existing containers come down before the new ones start, resulting in a functional outage or downtime. However, this redeployment method is simpler with no scaling up and down of the cluster. Elastic Path recommends this methods for non-production systems, when database changes are not backwards compatible, or when trying to maintain consistent performance for testing.

Database changes for this redeployment method are run while the applications are down, so that it works for database changes that are not backwards compatible.

Data Changes (Amazon RDS)

You can run redeployments with database changes by ticking the WITH_DB_UPDATES box in the UpdateAuthorAndLive_1_StageUpdates job. When running with DB updates, the first step in the staged redeployment script is always to take a snapshot of your database. This ensures that the original state of your database can be recovered if there is an issue during the redeployment process.