I'm trying to create my own deployment on a Kubernetes cluster based on a CMS (Prestashop). And I imagine that I will have to update the image regularly.
The CMS comes with 2 ways of update :
- via there module (1 click upgrade) : this method is not suitable for automation and will break the parallel running images
- via upgrade script on the install folder.
the question is how i can achieve a rollig update strategy that can pull the image ready to serve the client and update the schema and the underlying scripts that should alter the database just ONCE, so that new running pods don't break the database
i already created the docker ready to serve image, the issue now is with the updating strategy and the impact on the database.
NB: the database is running on a separate namespace and in a separate statefulSet
Without any knowledge of Prestashop, your question brings up two deployment/upgrade patterns within Kubernetes:
#1. Operators - operators are built and used to perform the complex type of tasks you are describing. A very quick search shows no signs of operators that exist, so this would be a longer path and a lot of custom code to create/maintain.
#2. Helm - Helm is a deployment management solution that can also help with this type of activity by deploying charts. A very quick search shows that the bitnami repo (owned by vmware now I believe) has a prestashop Helm chart here
If it were me, I'd explore the option of looking at the Prestashop helm chart and testing that out to see if it could work for you. It looks to be receiving regular updates (last commit was 3 weeks ago) and might ease your burdens (including image management, etc.)