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. Your connection will be proxied via a secure bastion server, so its important to include the ProxyCommand portion of the configuration.

Execute SSH with a command like ssh <hostname>.

Adding new SSH public keys

To add a new SSH user and public key, please open a ticket with Webscale support and we will get the key onto your bastion, and into the environment with a redeploy.

Connecting SFTP

If your SFTP client supports SSH ProxyCommand, you can use the ssh configuration you were provided with. Otherwise, in order to connect an SFTP client to your application, first you must open an SSH Port Forward with the following command

ssh -L 3111:localhost:22 <SSH username>@<SSH host, usually staging or production>

This will set up a port on your computer, 3111 in this case, which you can then connect your SFTP client to with the SFTP protocol. For example, sftp://user@localhost:3111

If your Magento application needs to read these files, make sure they are readable/writable by the xfs group after transfer. This allows the Magento application to properly read the files. All the ssh users will have xfs as their primary group which should handle this in most cases.

About this deployment environment

Your application is running as a part of a Kubernetes cluster, and when you connect over SSH you are connecting to the first active pod running the php-fpm process. You could think of a ‘pod’ like a server that runs docker containers. This pod shares a disk, /var/magento-persistent, with the other pods. The persistent disk contains the env.php file, the nginx configuration, shared media, and if your application is not dockerized then it will also contain your PHP code. Many files are shared via symlinking from this persistent disk to the container disk.

The pod count will scale out automatically based on resource demand.

Your cron jobs run as part of a separate single deployment, which will only ever run one pod.


Last modified October 10, 2023