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.
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
BuildDeploymentPackagejob in the CloudOps Jenkins console.
Build and tag a new set of Elastic Path Docker images using the
Create a redeployment staging script by running the
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:
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_NAMEto either the Author or Live RDS (Relational Database Service) CloudFormation stack name from your original Author and Live deployment. For Example:
Go to the Staging directory in your Amazon S3 bucket for CloudOps, and find the script that is automatically generated by the
The script is named
staging.shand is stored under the folder name provided by the
Review the AWS (Amazon Web Services) CLI commands that will be run.
Run the script using the
UpdateEnvironment_2_ApplyUpdatesjob, pointing at the staging file in Amazon S3.
Confirm that the changes are made successfully by following the
UpdateEnvironment_2_ApplyUpdatesjob console log, and the event log for your stack in the CloudFormation console
Elastic Path recommends the
cfUpdateNoDownTime redeployment method.
UpdateEnvironment_1_StageUpdates job calls the
Update-Stack-Services.sh script using the
cfUpdateNoDownTime redeployment method. You can also change the redeployment method to
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 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
UpdateEnvironment_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.