VM Image Lifecycle Management & Patching.
Must know workflow for DevOps Engineers
When you start learning a cloud, You will probably learn about deploying standalone VM instances or autoscaling groups when you start working in cloud environments.
You would choose a base image of your choice and start playing around with it manually or through automation.
In actual project environments, it is not that straightforward. I want to shed some light on how it happens in a real project environment.
So, here is a list of generic VM life cycle management steps followed in secured project environments.
Note: The list is to give you an overall picture of VM lifecycle management. It differs in each organization.
In a secured, compliant environment, you are not allowed to use the base images provided by the cloud provider.- Every organization creates a base image with standard security tools (agents), LDAP configurations, etc. (It changes as per each organization’s security policy).
Usually, this image is created and maintained by a central platform or security team.- The approved and certified base image will be shared with all the teams in the organizations.
It could be a single cloud account or shared with multiple child accounts within the organizations.-
Then each team can create their own images with applications on top of the approved base image. (Tools like packer is used here)-
The new image created by the teams will be deployed in production.- Now, the base images get new updates and patches. So a new version of the base image is released and notified to all project teams by the platform or the enterprise security team.-
Every organization has a patching lifecycle. Meaning security teams set guidelines on applying the updates and patcher to VMS. For example, it could be one month or once in three months.-
Patching could be “in-place,” meaning patching the existing instance, or it could be immutable — meaning replacing the existing one with a new image.-
Based on the patching lifecycle, every team will update the existing application images with the new base image and deploy it to production irrespective of whether the application code has changed.