Before you begin

Creating a new instance template

Most of the instance properties that you can define in a regular API request to
create an individual VM instance can be defined in the instance template,
including any instance metadata, startup scripts, persistent disks, service
accounts, and so on.

At a minimum, the same required properties for creating an instance are
also required to create an instance template. See a list of the required fields
on the
instanceTemplates().insert
reference.

API

In the instance template API, you must explicitly define all of the required
configuration fields as described in the
instanceTemplates().insert
documentation. For example, an instance template with the minimal required fields
looks like the following:

For the disks property, you must either provide the initializeParams property
to create new persistent boot disks for each instance, or you can provide
the source property to attach an existing persistent boot disk. If you
attach an existing boot disk, you can only create one instance from your
template.

Creating an instance template based on an existing instance

Beta

This is a Beta release of
Creating an instance template based on an
existing instance
. This feature
is not covered by any SLA or deprecation policy and may be subject to backward-incompatible
changes.

You can use the --source-instance flag to save the configuration of an
existing virtual machine instance into an instance template. Optionally, you
can override how the source disks for the instance are defined in the template.

The table below shows the options for overriding how disks are defined in the
template.

Disk type

Options

Boot disk

[Default] Use the same source image or image family
that was used to create the boot disk in the source instance.

Use the URL of any (custom or public) image.

Other read-write persistent disk(s)

[Default] Use the same source image/source image family
that was used to create the disk in the source instance. Note: If
the source instance's disk does not have a source image/source
image family property, then it will not be included.

Use the URL of any (custom or public) image.

Do not include the disk.

Read-only disk(s)

[Default] Include the disk in read-only mode.

Do not include the disk.

Local SSD(s)

[Default] Include a blank local SSD

For each disk, you can also override the auto-delete attribute to specify
whether or not the disk should be deleted when its associated instance is
deleted.

By default, if no override options are specified, the disk configuration in
the template matches the source instance.

[SOURCE_INSTANCE] is the name of the instance to use as a model for the
new template.

[SOURCE_INSTANCE_ZONE] is the zone that contains the source instance.

[SOURCE_DISK] is the name of a source-instance disk that you want to
override within the template.

[INSTANTIATE_FROM] specifies whether to include the disk and which image
to use. Valid values depend on the type of disk:

source-image or source-image-family (valid only for boot and
other persistent read-write disks).

custom-image (valid only for boot and other persistent read-write
disks). If specified then the path or URL for the custom image must also
be specified; see example below.

attach-read-only (valid only for read-only disks).

do-not-include (valid only for non-boot persistent disks and
read-only disks).

[AUTO_DELETE] specifies whether the disk will be auto-deleted when the
instance is deleted. Valid values are: false, no, true, and yes.

For example, the following command creates an instance template based on
my-source-instance, with the option to use the original image from
data-disk-a but set auto-delete to true, and to replace data-disk-b
with a custom image.

[INSTANCE_TEMPLATE_NAME] with the desired name of the instance template.

[REGION] with the region of the subnet.

[SUBNET_NAME_OR_URL] with either the name of the subnet or its URL. Note: if
you use the subnet name, Google will find that subnet in the target region
(provided that it exists there); however, if you use the subnet URL, then the
instance template can only be used to create instances in the specific region
that is associated with the subnet URL.

This example creates a template called template-qa that only creates instances
in the subnet-us-qa subnet.

Using this template to create instances for a
Managed Instance Group (with or
without autoscaling) automatically creates the
instance in the specified region
and subnet. This lets you control the subnet of new instances created
for load balancing.

Using custom or public images in your instance templates

Because managed instance groups are designed to add and remove instances
frequently, it is useful to
create a custom image
and specify it in the instance template. Prepare your image with the
applications and settings that your instances need so you don't have to
manually configure those items on individual instances in the managed instance
group.

Alternatively, you can create an instance template that uses a
public image and a
startup script to prepare the instance after
it starts running. Custom images are more
deterministic
and start more quickly than instances with startup scripts. However, startup
scripts are more flexible and allow you to update the applications and settings
in your instances more easily.

Note: If the image you want to use belongs to a different project, you can
still use that image in your instance template, provided that the owner of that
project grants the managed instance group access to the images. For more
information, read
Granting a managed instance group access to images.

Updating an instance template

It is not possible to update an existing instance template or change an instance
template after it has been created. If an instance template goes out of date, or
you need to make changes to the configuration, create a new instance template.