Earlier this 12 months, we launched VM Manager, a collection of instruments that can be utilized to handle digital machines operating on Google Cloud at scale.
One of many providers accessible with VM Supervisor is OS patch management, which helps to use patches to digital machines on-demand and primarily based on schedules. Each Linux and Home windows working methods are supported and the service makes use of the respective replace infrastructure of the working system (e.g. apt, ZYpp, yum and Home windows Replace Agent) to each establish and apply lacking patches.
A request that comes up typically when speaking to prospects that plan on utilizing this service or are already utilizing it, is how you can create a backup of the state of a digital machine earlier than patches are utilized so as to have the ability to roll again in case one thing goes improper with patching or with the patches themselves. Sadly this function shouldn’t be supported by VM Supervisor out of the field.
One of many capabilities the service helps nonetheless is the flexibility to run pre-patch and post-patch scripts on every VM that’s focused for patching. Scripts operating pre-patching or post-patching run on the occasion and within the context of the service account that’s related to it (both the Compute Engine default service account or the one which was used throughout creation).
On this weblog, I’ll clarify how pre-patch scripts may be leveraged to create a crash constant disk clone of the connected persistent disks of a VM earlier than patches are utilized.
This weblog describes an answer to a standard buyer downside. The perfect answer can be to have a direct integration within the service, that doesn’t depend on executing the snapshot creation on the VM and within the context of the related service account. Assigning the required permission to the service account in the end offers these permissions to any consumer that may login onto the VMs.
By making the patching of a VM depending on taking a disk clone (that is how the pattern script on this article is put collectively), a failure to create the clone in the end ends in not patching the VM.
Establishing VM Supervisor and OS patch administration is out of the scope of this text. Comply with the directions on Setting up VM Manager to allow VM Supervisor to your undertaking.
Creating disk clones requires not less than the next permissions to be assigned to the service account related to the VM:
compute.disks.create # on the undertaking
compute.disks.createSnapshot # on the supply disk
The script that creates the clone in the end runs on the VM that’s being patched. Which means it isn’t solely required to set the proper permission to the service account related to the VM however the API scope must be set as properly.
Set the scope to both Enable full entry to all Cloud APIs