gcloud compute command-line tool enables you to easily manage your
Google Compute Engine resources in a friendlier format than using the
Compute Engine API.
gcloud tool is part of the Cloud SDK and is a unified command-line
tool that includes features like statement autocompletion, in-place updating,
extensive man page style help, human-readable and machine-parsable output
formats, and integration with Google Cloud SDK.
Install gcloud compute
gcloud compute, install the
Google Cloud SDK.
Set up gcloud compute
Google Compute Engine uses OAuth2 to
authenticate and authorize access. Before you can use
gcloud compute, you
must first authorize the Cloud SDK on your behalf to access your project and
acquire an auth token.
If you are using
gcloud for the first time,
gcloud automatically uses
default configuration. For most cases, you only need
gcloud initto start the authentication process. Hit enter when prompted.
The command prints a URL and tries to open a browser window to request access to your project. If a browser window can be opened, you will see the following output:
Welcome! This command will take you through the configuration of gcloud.
Your current configuration has been set to: [default]
To continue, you must login. Would you like to login (Y/n)? y
Your browser has been opened to visit:
If the Cloud SDK detects that a browser can not be opened (e.g., you are working on a remote machine) you will see the output below. Or, if you are working on a local machine and your browser doesn't automatically load the URL, then retry the
gcloud initcommand with the
gcloud init --console-only
Copy the authentication URL and paste it into a browser. Then paste the verification code back into the terminal.
Go to the following link in your browser:
Enter verification code:
In the browser window, review the application permissions and click Accept when you are ready. If you are working on a remote machine or used the
--console-onlyflag, copy and paste the returned code on the command line after Enter verification code:. Otherwise, the code is automatically sent to the command line tool.
Choose the credentials for this configuration.
After setting up your credentials,
gcloudprompts for a default project for this configuration. Select a project ID from the list.
After you set this property, all of your
gcloud computecommands use the default project ID unless you override it with the
--projectflag or set the
CLOUDSDK_CORE_PROJECTenvironment variable. If you do not set a default project or environment variable, you must include a
--projectflag in each
gcloud computecommand that you run.
When you run
gcloud for the first time, it also sets a default zone and
default region for you, based on the default zone and region keys in your
project metadata. A zone or a region is required for working with resources
that belong to a zone or a region (for example, any time you manipulate a
virtual machine instance, you must specify a zone). By setting a default zone
gcloud can infer this information without requiring you to
provide it with each request. You can always manually override or
change these default settings.
For more information, read Set default properties.
gcloud uses the concept of
configurations to help you manage your credentials
for different accounts. Each configuration contains the email account to authenticate
with, and specific settings like the default project ID, default
zone setting, and so on.
gcloud automatically comes installed with a
configuration. This is the configuration whose credentials will be used to
authenticate to Google Cloud Platform services.
For most users, just using the
default configuration is enough. If you
have use cases that require that you switch between accounts,
you can create more configurations
that you can alternate between.
gcloud topic configurations for
detailed information about using configurations.
Set default properties
Currently, when you create a project and use
gcloud for the first time,
Compute Engine picks a default zone and region based on information
from your project metadata and sets this property for your
configuration. You can view these default properties by getting metadata
information about the project:
gcloud compute project-info describe
Look for the following metadata keys:
- key: google-compute-default-region value: ... - key: google-compute-default-zone value: ..
If you don't change or override these properties,
gcloud provides them
automatically for all of the
gcloud requests you make. To change or
override these properties, use the methods below.
Change your default zone and region in the metadata server
You can change the default zone and region in your metadata server by making a request to the metadata server. For example:
gcloud compute project-info add-metadata \ --metadata google-compute-default-region=europe-west1,google-compute-default-zone=europe-west1-b
gcloud only picks up on new default zone and region changes after you rerun
gcloud init. After updating your default metadata, run
gcloud init to
Set default zone and region in your local client
You can manually choose a different zone or region without updating the
metadata server by setting these properties locally on your
First, make sure you are using the configuration for which you want this set these properties. Each configuration has its own settings; to switch between configurations, run:
gcloud config configurations activate CONFIGURATION_NAME
Next, to set a zone or region property in the client, run:
gcloud config set compute/zone ZONE
gcloud config set compute/region REGION
To remove a default property altogether, use the
gcloud config unset compute/zone
gcloud config unset compute/region
Note that removing the default property altogether will result in
prompting for a zone or region for every command you run.
Set default values in environment variables
You can set environment variables that supply values to
commands. Environment variables override
default properties that you set with the
commands, but do not override explicit flags like
exportcommand to set the zone and region variables.
$ export CLOUDSDK_COMPUTE_ZONE=ZONE
$ export CLOUDSDK_COMPUTE_REGION=REGIONTo make these environment variables permanent, include these commands in your
~/.bashrcfile and restart your terminal.
setcommand to set the zone and region variables.
C:\> set CLOUDSDK_COMPUTE_ZONE=ZONE
C:\> set CLOUDSDK_COMPUTE_REGION=REGION
You can override environment variables by including specific
--region flags with your commands.
Set values on each request
You can override default properties by including specific
flags with each of your commands. For example:
gcloud compute instances create example-instance --zone us-central1-f
These flags only work for the single command you use it with. The flags do not change any default settings you have, but simply overrides it for that request.
Order of precedence for default properties
gcloud evaluates default properties in the following order for each
- If you provide an explicit
--projectflag, it overrides all other settings for that single request.
- If the default zone and region properties are defined only in the metadata
gcloudsets your local
gcloudclient to these properties when you run
gcloud init. For subsequent requests,
gcloudprompts you for the zone.
- If the default zone and region properties are defined in both the metadata server
and on the local client for that configuration,
gclouduses the default properties on the local client.
- If the default zone and region properties are defined in the metadata server,
the local client, and in environment variables,
gclouduses the default properties in the environment variables, regardless of which configuration you are using.
Common gcloud compute commands
Below are examples of common tasks when working with instances. For more details about working with instances in general, see Instances.
instances create command to
create a new instance. For example, the following command creates an instance
named "my-instance" in the "us-central1-a" zone.
gcloud compute instances create my-instance
If you omit the
gcloud can infer your desired zone based on your
Other required instance settings, like
machine type and image, if
not specified in the create command, are set to default values.
You can see the default values by displaying help for the
gcloud compute instances create --help
There are a number of ways to list your instances using the
instances list command.
You can create a human-readable, tabular output with the following command:
gcloud compute instances list
You can use regular expressions to narrow the list of instances returned by name. For example, the following command returns all instances whose names start with "my-".
gcloud compute instances list --regexp my-.*
Fore more information about working with the
--regexp flag and using
regular expressions, see
To return details about one instance, use the
command. For example, the following command returns information
gcloud compute instances describe my-instance --zone us-central1-a
The previous command returns results in YAML format. You can use the
--format flag to change how the results are displayed. For more examples of
getting and listing resources, including instances, see Fetching
Connect to instances
gcloud compute makes connecting to your instances easy. The
gcloud compute ssh
gcloud compute copy-files
commands provide wrappers around around SSH and SCP, which takes care of
authentication and the mapping of instance name to IP address.
For example, to ssh in to "my-instance" in the "us-central1-a" zone, you can use:
gcloud compute ssh my-instance --zone us-central1-a
To copy the local file "file-1" to "my-instance" in the "us-central1-a" zone, you can use:
gcloud compute copy-files ~/file-1 my-instance:~/remote-destination --zone us-central1-a
copy-files command can also be used to copy files from an instance to
your local machine. For example, to create a local copy of "file-1", which is on
the instance "my-instance" in the "us-central1-a" zone, you can use:
gcloud compute copy-files my-instance:~/file-1 ~/local-destination --zone us-central1-a
gcloud compute ssh and
gcloud compute copy-files commands, by
default, use the private key
file located at "~/.ssh/google_compute_engine". If you don't want to use this
key file, you can specify a different key file by specifying a different
location with the
--ssh-key-file flag. For example, you might already have a
private key you want to use, or you might want to use different private keys
with different projects.
Using SSH-based programs directly
If you prefer to use
gcloud compute can generate
an SSH configuration file that contains host aliases for your instances with
authentication configuration. To do this, run:
gcloud compute config-ssh
Here's an example of one alias added to the SSH configuration file
Host my-instance.us-central1-a.myproject HostName 18.104.22.168 IdentityFile ~/.ssh/google_compute_engine UserKnownHostsFile=/dev/null CheckHostIP=no StrictHostKeyChecking=no
You can specify an alternative, per-user SSH config file by
Every time you add or remove an instance, you should rerun the
After updating your SSH config files with the
config-ssh command, you can
use any SSH-based program to access your instances. For example, for the
instance named "my-instance", in the "us-central1-a" zone, in the project named
"myproject", you can use the OpenSSH ssh client as follows:
$ ssh my-instance.us-central1-a.myproject
To make a local copy of the file "file-1" on the instance, you can use the OpenBSD scp client as follows:
$ scp my-instance.us-central1-a.myproject:~/file-1 .
Working with metadata
You can set custom metadata for an instance or project outside of the server-defined metadata. This is useful for passing in arbitrary values to your project or instance that can be queried by your code on the instance. This section shows a few common metadata operations. For more detailed information about working with metadata, see Storing and Retrieving Metadata.
Adding and removing instance metadata
You can configure instance metadata with
gcloud compute when you create an
instance using the
command, or with an existing instance using the
commands. Metadata are specified as
key/value pairs separated with an equals sign ("=") using the
flag. Or, metadata can be read from a local file using the
For example, to add the custom metadata keys "role", "unique-id", and "build-num" to an existing instance named "my-instance" in the "us-central1-a" zone, you can use:
gcloud compute instances add-metadata my-instance \ --zone us-central1-a \ --metadata role=worker unique-id=1234 build-num=4.32
To remove the custom metadata keys "role" and "unique-id", you can use:
gcloud compute instances remove-metadata my-instance \ --zone us-central1-a \ --keys role unique-id
After adding and removing metadata from an existing instance, you can see your changes by running:
gcloud compute instances describe my-instance --zone us-central1-a
... metadata: fingerprint: eU448B6JGQw= items: - key: build-num value: '4.32' kind: compute#metadata ...
To change existing metadata or add new metadata, use
metadata updates are additive. This means that you need to only specify the
metadata keys that you want to add or change. If you specify an existing key,
then the key's value will be updated with the new value.
For images that have Google Compute Engine tools installed on them, there are two metadata keys that are reserved for startup scripting functionality:
startup-script: Indicates script content that is executed when the instance starts. For longer script content, you can use the
--metadata-from-fileflag to pass in a path to a file that contains the script content.
startup-script-url: Indicates that a script at the specified publicly-accessible location is executed when the instance starts.
For example, to create an instance named "my-instance" in the "us-central1-a"
zone, with startup script content specified with the
--metadata flag, you can
gcloud compute instances create my-instance --zone us-central1-a \ --metadata startup-script="echo 'hello world'"
If you SSH in to "my-instance" and check the system log (/var/log/syslog) you will see the result of the startup script.
With an existing instance named "my-instance" you can add the following startup script
from a local file using the
gcloud compute instances add-metadata my-instance \ --metadata-from-file startup-script=/local/path/to/script/startup
In this example, the startup script is run when the instance reboots, for
example, when you use
Adding and removing project-level metadata
Project-level metadata is accessible by all instances in a project. By default, a project has reserved project-level metadata. You can also add and remove custom project-level metadata. Like instance metadata, project metadata updates are additive. This means that you need to only specify the metadata keys that you want to add or change. If you specify an existing key, then the key's value will be updated with the new value.
To see the existing project-level metadata, use the
gcloud compute project-info describe
The following command adds two pieces of project-wide metadata.
gcloud compute project-info add-metadata \ --metadata-from-file startup-script=/local/path/to/script --metadata startup-id=1234
Note that the
startup-script key is reserved and means that
the content from the specified local file is to be run when instances start.
To remove the two pieces of metadata you just added, use:
gcloud compute project-info remove-metadata --keys startup-script startup-id
To delete the instance named "my-instance" in the "us-central1-a" zone, you can
instances delete command:
gcloud compute instances delete my-instance --zone us-central1-a
When you create an instance, a persistent disk is also created. This disk
counts towards your persistent disk quota and incurs monthly persistent disk
instances delete command to delete an instance, by
default, removes the persistent disk associated with the instance. To
override this behavior, you can:
- Use the
--keep-disksflag of the
- Configure the disk to not be auto-deleted. After you create an instance, and
anytime before you delete the instances, you can use the
instances set-disk-auto-deletecommand to preserve the persistent disk. Note that the
--delete-disksflag of the
instances deletecommmand will delete disks regardless of the auto-delete configuration.
For more information, see Setting the auto-delete state of a persistent disk.
Operations are a record of changes to your Google Compute Engine resources. To get
a list of all operations in a project, you can use the
gcloud compute operations list
Operations have scopes that can be used to narrow the operations returned in a
list request. For example, you can use the
--regions flags to refine your results. The following command
returns only the operations in the "us-central1-a" and "us-central1-b" zones:
gcloud compute operations list --zones us-central1-a,us-central1-b
For more examples of getting and listing resources, including operations, see Fetching Resources.
Getting help pages
The following commands show you how to access different types of help, from
general help about
gcloud compute, to specific help about a resource group
instances) or a command (
create). Comprehensive help for all
resources and commands follows this pattern:
gcloud compute --help
gcloud compute instances --help
gcloud compute instances create --help
Quick help can be obtained by using the
-h flag instead of the
You can also review all of the comprehensive help at
Cloud SDK Reference.
For comprehensive help with commands specifically for configuring the
gcloud topic TOPIC
TOPIC is the applicable topic for which you want to get help. For a list
of topics you can get help for, see
gcloud topic reference documentation.
That's it, you can now start using
gcloud compute on your own!
Here are some ideas to get you started: