Deployments And SSH with Helm Blueprints

Using manual or managed deployments with helm blueprint based infrastructure, and connecting with ssh

Most users should prefer to do Managed Deployments rather than manual, as there is more chance for mistakes to be made when doing manual application updates.

Managed Deployments

To execute a new deployment, simply change the configuration of your cluster. Update the magento.dockerimage value of your helm blueprint to update to a new version of your code. When you save that configuration, a blue-green deployment will begin.

In a blue-green deployment, first a new cluster will be created with the new configuration. Once those resources have been created and verified, routing for any applications assigned to that managed cluster will automatically change from the old (‘blue’) cluster to the new (‘green’) one.

Automated Deployments

If you want to automate your deployments to have a full CI/CD pipeline you can simply add Webscale API requests at the end of your build process. For example, if you wanted to update the docker image reference in your kubernetes managed cluster you could execute the following GET and PATCH requests after your docker image was successfully pushed to an image repository. The following solution relies on jq and yq being available in your build environment.

#!/bin/bash

ACCESS_KEY=<my-access-key>
CLUSTER_ID=<managed-cluster-id>
NEW_DOCKER_IMAGE_URI=<updated-docker-image-uri>

# Fetch existing cluster blueprint and update 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 w - magento.dockerimage $NEW_DOCKER_IMAGE_URI | base64 -w 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 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 }"

This will only change the magento.dockerimage value in the cluster 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. Once the new deployment is verified the applications using the cluster will be updated to route to the new instance running the magento.dockerimage helm value.

Manual Deployments

Manual deployments will not automatically follow a blue-green release model the way a managed deployment will, but they will wait on new servers to be ready to serve traffic on port 80 before entering them into service.

How to execute a new deployment

  1. use your SSH configuration to copy your code to /var/magento-persistent/code/current for a running server
  2. Go to the webscale control plane and click Redeploy for the cluster. This will trigger the update process

Have questions not answered here? Please Contact Support to get more help.

Connecting with SSH

In order to access your application over SSH, please use the configuration provided to you by Webscale, and reach out if you need a new one. In order to use this configuration you will need to install kubectl (https://kubernetes.io/docs/tasks/tools/), export your provided WEBSCALE_FLOW_APIKEY as an environment variable, and finally place the proxy command script at /opt/webscale_support/proxy-ssh.sh

This configuration is powered by an API key which has been created per-user, so it can also be revoked per-user and should be revoked when you remove that user’s authorized ssh keys.

Execute ssh with a command like ssh <hostname>.

Adding new SSH public keys

To add a new ssh user and public key, go to your cluster blueprint and edit the authorized_keys yaml entry. Each entry has a username and list of keys that will be authorized for that user. Save the blueprint and the keys will be ready with the next deployment.


Last modified October 10, 2023