Updating Author and Live Environments
important
CloudOps for AWS is a legacy tool and is no longer supported by Elastic Path Software. CloudOps for AWS release 3.5.x reached end-of-support in February 2023. For information about current Elastic Path Commerce deployment options, see Deploying Elastic Path Commerce documentation.
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.
Build a new deployment package from your Elastic Path Commerce source code using the
BuildCommerce
job in the CloudOps Jenkins console.Build and tag a new set of Elastic Path Docker images using the
BuildEPImage
job.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
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 theSTAGING_DIRECTORY_S3_URI
job parameter.Review the AWS (Amazon Web Services) CLI commands that will be run.
Run the script using the
UpdateAuthorAndLive_2_ApplyUpdates
job, pointing at the staging script in Amazon S3.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.