I had a question about general practices around updating container with security patches, etc.
In my head this would be done simply by updating the base container and triggering a rebuild/redeployment. The current plan is to stick with a specific tag and have automated deployments every X days to catch those updates. I was wondering what other patterns people are using to do this?
For example (hypothetical) we have N deployments running the latest version of NGINX and a security patch comes out, what would the pattern be for applying the updates to all N deployments without manually having to update each deployment spec or Helm chart.
In my previous job what we did is some maintain those base images and each project that uses them is responsible for keeping themselves up to date.
So, when a security issue is fixed, the base image is updated and notified all the teams.
What we did with more bigger updates to base images was, the team maintaining the base image that had a big change only announced it (or manually updated it) to a handful of projects. If those worked fine, then the gate was open for the rest and aware that there was a big change, so if any problem they can revert the change in the yaml.
Thanks Rata. That’s more how I was originally envisioning things, but I think I got lost in the weeds recently
Essentially Core team maintains the base containers and updates them when patches come out and then notifies the dev teams who then update their deployments with the new image tag, and fingers crossed nothing explodes.
