Manage Google cloud instances with images, templates
Recent additions to Google Compute Engine, particularly around images and templates, streamline how admins can create and manage VMs.
Often pegged as the third biggest public cloud provider behind AWS and Azure, Google continues to grow far beyond its initial IaaS feature set. And recently, these efforts resulted in expanded options to create, clone and manage VM instances in Google Compute Engine.
But while these new management options for Google cloud instances can improve consistency, eliminate errors and reduce admin overhead, there are some limitations.
Overview of Google cloud instances
Like Amazon EC2, Google Compute Engine (GCE) offers VMs that admins can provision on a multitude of predefined machine types, defined by virtual CPU size and count, memory size and local persistent storage capacity. Unlike AWS, GCE users can also create custom machine types for workloads that require more processing power or memory.
In either case, the instance creation process is similar, but the step-by-step details will differ, depending on how you access the GCE management interface: via the web console, the command-line interface through the gcloud tool or via APIs and a scripting language, like Node.js, Python or Ruby. In each scenario, you must specify these four components:
- machine type
- boot image
- instance name
- zone
The role of images
Admins can install images from a Google-managed public repository or a custom configuration that is stored in a Google Cloud Platform project. With one of the new management features, enterprises can also clone an image from the disk attached to a running VM instance through the "keep instance running" option on the parent VM. Since this technique might cause a corrupt image or configuration inconsistencies when the image is in use, another option is to create a snapshot of an existing VM to use as the base image for new instances.
Although Google cloud image files contain the necessary OS files, libraries and applications for a new cloud instance, sometimes, it's necessary to run configuration scripts to define particular settings. Another new GCE feature lets admins run startup scripts every time a VM boots to perform tasks, such install or update software, enable OS services or set OS and application parameters. To create a script library, admins can also store startup scripts on Google cloud storage and use the files' URLs as the location when they configure the script.
It's often necessary to copy data to a remote location or sync it to another VM; gracefully shut down applications; or copy log files to an archive before shutting down an instance. This is possible via recent support for shutdown scripts that are executed on a best-effort basis -- meaning they are not guaranteed to run or complete before an instance terminates. Scripts should execute within 90 seconds -- or 30 seconds for pre-emptible instances -- to have the best chance of completion.
Templates for Google cloud instances
GCE users can define standard instance configurations as templates, which specify the machine type, boot disk or container image and network configuration. Templates are a global resource for an account and not bound to a particular zone or region. When you need to deploy the same configuration multiple times, templates ensure that the process is quick and the configurations are consistent.
To create a group of identical instances, such as for a front-end web farm, templates are the basis for managed instance groups that can be distributed across multiple regions for high availability and to auto scale on demand. A recent feature enables automatic software updates on all instances in a group via an instance template. Users can configure the feature to:
- incrementally update instances by controlling the rate of updates;
- temporarily deploy additional instances to maintain capacity while other members of the group update; and
- update a subset of the group -- a feature that's helpful for canary testing.
Admins can also automatically expand and shrink instance groups via an autoscaling policy, which specifies a target level for resource use that determines when to scale the group. The scaling measure can be one of:
- average CPU utilization;
- HTTP load balancer capacity based on CPU utilization or requests per second; or
- custom metrics as measured by Google Stackdriver.
The simplest example would be setting a web server farm to scale when average CPU usage hits 80% or the load balancer hits 100 requests per second. Once that threshold is exceeded, the autoscaler adds and removes instances to maintain the target threshold.
Templates are immutable, so they can't be edited. To change a template, you need to create a new one, but a recent feature that enables admins to create a template from an existing instance makes this process less cumbersome. This feature is particularly useful when you migrate applications from development to production, as it lets you save the development configuration as a master image that can be used for all future deployments. Similarly, if you are unsure how an application might perform on different machine types, you can use several different sizes. Then, once you determine the optimal type, you can freeze the configuration as a template for later production deployments.
Other features
Two more recently added management features for Google cloud instances include the ability to:
- create one or more persistent disks when an instance starts and
- protect VMs from accidental deletion via a configuration flag.
These features provide significant flexibility and automation for instance management. They enable the deployment of consistent configurations across server farms and applications and provide greater flexibility in disk configuration. Additionally, they increase reliability through automated scaling to maintain performance and protection against the accidental removal of resources.
