The Google Cloud Console, which is the actual web UI where you click around in GCP, is really convenient and easy to use, but sometimes it is faster to use the gcloud command line tool.
You can do anything with GCP from the gcloud command line tool. You can create a VM, deploy a Cloud Function, check which APIs are enabled, etc, switch between projects, etc.
A lot of GCP practitioners prefer that kind of convenience - using and managing their GCP resources all from one place and using one tool.
However, using the gcloud CLI (command line interface) requires getting familiar with its patterns. Once you see the pattern behind it, you can figure out the commands for services you haven't used yet pretty easily, but until then, it can be a little frustrating.
So let's discuss some of the patterns that are worth knowing.
gcloud auth list
This command shows which Google accounts are authenticated on the machine/terminal that you're using. The asterisk marks the active one - the identity that gcloud is currently using for its command. If you ever see a permissions error and you can't figure out why, you might be authenticating as the wrong account so it's worth taking a look at the list through this command.
gcloud config list
This command gives you the current configuration that gcloud is set up with. It will show you the project, the account, and any default region or zone values that have been set. The project is usually the most important. Every command you run has to go against a given project, and will go against the project specified in this configuration, unless you pass a --project flag to override it. And if there's no region or zone set, gcloud will ask you for the location every time you create a regional resource.
So how do you set a project in the configuration?
gcloud config set project [PROJECT_ID]
This is how you set the project. If you have multiple projects, or if you open up gcloud and it hasn't been set yet, this is what you would use to specify the project you want to work in. And remember, project ID is the immutable id that is assigned to the project upon creation, even though it can be set by you at that moment. This is different from the project name, which is a human readable reference to the project that can be changed at any time and does not have to be unique, and the project number, which is numerical and entirely set by Google and is used for their internal systems.
gcloud config set compute/region us-central1
This command would set the region to us-central1. Of course, you can set it to other regions as well.
gcloud config set compute/zone us-central1-a
This command, similarly, would set the zone. Here I have it set to us-central1-a, but you can set it to other zones as well. Zones are smaller geographic areas within regions.
So now, if I were to create a new VM or any other regional or zonal resource, gcloud would use us-central1 and zone us-central1-a by default. I wouldn't have to pass the --region flag and --zone on every command.
us-central1 is generally the cheapest US region and has the widest service availability, although that's not always the case, but you could pick any region that makes sense for your use case.
At this point, if you were to run gcloud config list again, you would see the region, zone, and project listed.
Let's create a VM and a bucket from the terminal.
gcloud compute instances create cli-demo-vm --machine-type=e2-micro --image-family=debian-12 --image-project=debian-cloud
Let's break this down.
gcloud compute instances create specifies the service, resource type, and action. The name of the vm is cli-demo-vm, which hasn't been created yet, it's something I specify upon creation here.
The flags machine-type gives the size/configuration of the VM in terms of virtual CPUs and RAM. We've chosen the smallest, cheapest option here.
--image-family and --image-project tell it which operating system to use.
Notice that I didn't pass --zone, because it's using the default.
Now let's create a Cloud Storage bucket.
gcloud storage buckets create gs://$(gcloud config get-value project)-cli-demo --location=us-central1
We could even put a file in the bucket so it's not empty.
echo "Hello from the CLI lesson" > hello.txt
gcloud storage cp hello.txt gs://$(gcloud config get-value project)-cli-demo/
Notice how I can just inject the value of the project my gcloud configuration is currently set to, in the name of the bucket that I just created.
Let's work with projects a bit more.
gcloud projects list
This gives you a list of all the projects that you can access. The Project IDs listed are really the most important. That's what you will pass to --project or to gcloud config set project. This is the CLI equivalent of the project selector dropdown or window that you can use in the Console.
If you want to switch to a different project, again we could use the gcloud config set project [PROJECT_ID] command.
To see specifically which project is active at any time, you can use:
gcloud config get-value project
Now let's talk about enabling and listing APIs!
Before I can use any GCP service, its API has to be enabled in my project. Some are enabled by default, but most aren't.
You can check which APIs are enabled in the current project you're using with this command:
gcloud services list --enabled
If you run this, you'll notice a common pattern in the names of APIs. bigquery.googleapis.com, compute.googleapis.com, etc.
That's helpful to know because then you can potentially guess the name of another API without having to look it up. Like run.googleapis.com, which would be for Cloud Run.
Let's enable the Cloud Run API.
gcloud services enable run.googleapis.com
If we run this, Cloud Run will be enabled in our current project.
I could do the same thing from the console. There's an "Enable API" button for every service that isn't enabled yet. But from the gcloud CLI it's one command and I don't have to navigate anywhere.
You can also enable multiple APIs at once:
gcloud services enable run.googleapis.com cloudbuild.googleapis.com storage.googleapis.com
Now let's talk about useful patterns to know instead of literally memorizing every command.
The pattern is this:
gcloud [service] [resource] [action] --[flags]
For example:
gcloud compute instances list
gcloud = the tool we're using for the command
compute = the service, which in this case is Compute Engine
instances = the specific resource within the service, which in this case is Compute Engine instances.
list = the specific action
We didn't include any flags here, and you don't always have to. But let's do that so we can see what it looks like.
gcloud compute instances list --filter="zone:us-central1-a"
This is the same command, but --filter allows us to include a flag that narrows the results to ONLY instances in the zone we specified. Flags are how you modify any command. You filter the output, change the format, override the default configuration (like project or region). The base command stays the same. And again, this is something we could do in GCP console but it can be super convenient to just specify this through the terminal/command line.
gcloud run services list --region=us-central1
run = the service (Cloud Run)
services = the resource type (services deployed to Cloud Run)
list = the action
--region = a flag that scopes it to one region.
Again, the same pattern!
gcloud storage buckets list --format="table(name, location, storageClass)"
storage = the service (Cloud Storage)
buckets = the resource (Cloud Storage buckets)
list = the action
format = a flag that controls which columns I see.
So you can start to see that there are common patterns here.
gcloud sql instances list would show you the Cloud SQL instances you have. gcloud functions list would show you the Cloud Functions you have. You don't have to memorize everything if you internalize these patterns.
And we've been using list a lot, but there are other common actions.
list = show the resources that exist
describe = show the metadata about the resource
create = create the resource
delete = get rid of the resource
update = modify the resource
So for example, if gcloud compute instances list would show all VMs, then gcloud compute instances describe my-vm --zone=us-central1-a would show the details of one specific VM in a specific zone.
If you need a reminder of what's available in gcloud, you can use:
gcloud --help
This shows the service groups that gcloud knows about and which you can go further into.
If you want to go deeper inside a specific service group, you can use a command like this:
gcloud compute --help
That would give me every resource type under Compute Engine.
And I can keep going:
gcloud compute instances --help
This would show me every action I can take on VM instances. Basically, you can use the --help flag at any level and it will tell you what's available.
Another thing worth knowing about is autocompletion!
If you just type
gcloud comp
And then you press TAB, it will autocomplete gcloud compute. Similarly, if you start typing your project ID, and you hit tab, it will complete the project ID as long as what you've typed thus far is unique to one project ID.
So essentially, between --help and TAB autocomplete, you can discover a lot of commands without ever having to leave the terminal and look at Google Cloud documentation.
Getting comfortable with gcloud can really pay off in the long run. It's a convenient way to manage your resources in an ad-hoc way, and it's also useful in certain production workflows or CI/CD pipelines. For example, Cloud Build can run gcloud commands to deploy services.
Hope that was helpful! Thanks for reading.
