Deployments

All CloudFlow Commerce M deployments are blue-green deployments.

The new CloudFlow resources will not begin serving traffic until the deployment has completed and the php-fpm containers have passed verification. This potentially enables zero-downtime deployments, but an application may share resources (such as a database) outside of the management scope of a deployment that require an outage during deployment. Therefore changes to production environments should always be tested in a staging environment before deploying to the production cluster.

Manual Deployments

In the Webscale Control Panel, users can trigger a new deployment to their CloudFlow environment by making changes to attributes of the managed cluster or cluster blueprint.

There is also the option to “Redeploy” an existing cluster configuration, which will result in a new deployment that will pick up any changes made to the persistent disk.

Note: Modifying verify timeout, destroy delay, or retained configuration count will not trigger a new deployment.

Automated Deployments

To automate your deployments, simply add a Webscale API request the end of your build process that updates the Webscale Cluster Blueprint for your managed cluster. This will trigger a new deployment.

Here is an example bash script that demonstrates how to use the Webscale API to accomplish this (Note: this script utilizes yq and jq for parsing, the package versions in your build environment may vary and therefore your script may require some modifications):

ACCESS_KEY=AAA...xyz # Webscale API Key
CLUSTER_ID=suqavr9za686 # Managed cluster id can be retrieved from the Webscale Control Panel
NEW_DOCKER_IMAGE_URI=092352402511.dkr.ecr.us-east-1.amazonaws.com/magentodemo-dockerbuild:commit-101 # New code image to deploy

# Fetch existing cluster blueprint and update the docker_image_uri.
EXISTING_BLUEPRINT=$(
  {
    curl -s https://api.webscale.com/v2/clusters/$CLUSTER_ID \
      -H "Authorization: Bearer $ACCESS_KEY"
  }
)
NEW_VALUES_YAML=$(echo $EXISTING_BLUEPRINT | jq '.server_blueprints[] | select(.name == "helm").helm_chart_values' | tr -d "\"" | base64 -d | yq ".magento.dockerimage = \"$NEW_DOCKER_IMAGE_URI\"" | base64 -b 0)
NEW_BLUEPRINTS=$(echo $EXISTING_BLUEPRINT | jq "(.server_blueprints[] | select(.name == \"helm\").helm_chart_values) |= \"$NEW_VALUES_YAML\"")
NEW_BLUEPRINTS=$(echo $NEW_BLUEPRINTS | jq .server_blueprints)

# Patch the Webscale Cluster with the updated blueprint.
curl -X PATCH "https://api.webscale.com/v2/clusters/$CLUSTER_ID" \
  -H "Authorization: Bearer $ACCESS_KEY" -H "Content-Type: application/json" \
  --data "{ \"server_blueprints\": $NEW_BLUEPRINTS }"

The above script will only change the magento.dockerimage value in the cluster’s server_blueprint while keeping all other cluster configuration values the same. The managed cluster deployment process will trigger on the PATCH with the new magento.dockerimage. (If not using a unique docker image URI, any other blueprint property can be updated instead.)

Once the new deployment is verified (serving 200 status codes), routing will switch to the new resources. If verification does not succeed before the configured verify timeout, the new resources will be destroyed, routing will remain directed to the existing cluster, and the new cluster configuration will be marked as failed. Deployment logs can be viewed in the Task monitor.


Last modified February 23, 2024