Overview
The Rolling Update deployment strategy allows you to update your customer-facing application with zero downtime and minimal risk by maintaining at least one active instance while upgrades are completed on other instances, ensuring that your application is always available to your users and that deployments are seamless and have no noticeable user impact.
Rolling Update Deployments with Edge Computing Containers
It's possible to take advantage of Rolling Update deployments on StackPath's Edge Computing Container platform by utilizing the scaling features of your workload.
When a workload configuration is updated only one instance per location is updated at a time and the next update only occurs if the first was successful. We can take advantage of this, along with a Readiness probe if required, to push an updated application to all locations of our workload whilst maintaining uptime without any noticeable customer impact.
Scaling the Workload
First, ensure that you have scaled your workload to at least two instances in all locations. This ensures that we will always have an instance available in each location to respond to users. You can scale the number of instances by editing your workload and increasing the number of instances in each of your deployment targets, similar to below. This change needs to be saved before you attempt to update your image in the next step - This ensures that all locations have enough instances available.
Update the Container Image
Next, update your workload configuration with the new image required by updating the image tag in your workload configuration either via the UI as seen below or via API.
We recommend avoiding the use of the latest tag and using discrete versions instead.
Once you've saved your configuration or sent your API request, the Edge Computing platform will remove one of your instances in each PoP from your Anycast IP routing and proceed with the upgrade to the new image version. If successful the instance will be added back to the Anycast IP routing and the next instance will be upgraded.
Utilizing Readiness Probes
You can also team this strategy with a Readiness probe to ensure that your instance is only returned to the Anycast IP routing when it's ready, which can be useful if a startup task needs to occur, such as syncing a database or pulling data from a third party.
Rolling Update Deployments with Edge Computing Virtual Machines
It's also possible to take advantage of Rolling Update deployments on StackPath's Edge Computing Virtual Machine platform by utilizing the Readiness probe feature of your workload.
As we'll need to manually update the application on our virtual machines it's not necessary to have multiple instances in all of your workload locations, however, for the best end-user performance it is recommended to have at least two instances in all locations to ensure the user is always routed to their nearest instance via Anycast even during an upgrade.
Ensure Readiness Probes are Active
In order to take advantage of the Readiness/Liveness probe automation and automatically remove instances from Anycast, please ensure that a Readiness/Liveness probe is configured on all target workloads. Additional instructions on creating probes can be found here. Failure to do so may cause unexpected rolling update deployments and undesired behaviors that may not be captured by the readiness/liveness probe checks.
This should be checking application logic, so an HTTP Readiness probe is recommended. Once the probe is configured the instance will be taken out of Anycast routing when the probe fails allowing us to update our application on our instance without worrying about user impact.
Verify that SSH is Accessible
If you've not already, allow access to port 22 via Inbound Network policies. In the example below SSH is accessible to any IP address. You may want to limit this access to specific IP addresses or ranges instead.
Update the Application
As our Readiness probe is now active and we have SSH access to the VM's we can continue with the application update.
Multiple Instances per PoP
If you have multiple instances per PoP, you can proceed with the upgrade in all PoPs at the same time as the Readiness probe will remove any instances with failed health endpoints from Anycast routing. This gives the best performance to end users as they will still be routed to their nearest PoP geographically.
- SSH to all
-0instances in your workload - Ensure the health endpoint fails by either forcing it to return a 500 or disabling the webserver
- Run your application updates
- Ensure that your applications are healthy and that it's health endpoint is available and responds with a status code greater than or equal to 200 and less than 400. Once the Readiness probe polls your health endpoint successfully the instance will be added back to Anycast routing.
- Repeat the above for all
-1instances in your workload
Single Instance per PoP
If you have a single instance per PoP, you will need to complete the upgrade separately in each location. The previously configured Readiness probe will remove any instances with failed health endpoints from Anycast routing will you complete the update meaning users will be routed to the next closest PoP geographically.
- SSH to an instance.
- Ensure the health endpoint fails by either forcing it to return a 500 or disabling the webserver
- Run your application updates
- Ensure that your applications are healthy and that it's health endpoint is available and responds with a status code greater than or equal to 200 and less than 400. Once the Readiness probe polls your health endpoint successfully the instance will be added back to Anycast routing.
- Repeat the above for all other instances in your workload, one location at a time.