Interacting with Google Cloud: console, Cloud Shell, gcloud and APIs

Owen has spent his first week clicking through the Google Cloud console. It is friendly, and he has learned a lot from it, but on Monday Farah asks him to create the same small set of resources in three projects, exactly the same way, and to write down what he did so that someone else could repeat it. By the second project he understands why she asked. "Clicking is fine for learning and for looking," she says. "For anything we do more than once, we want it written down as commands or code."

Everything in Google Cloud, whether it is created in the console, from a terminal or by a program, goes through the same Google Cloud APIs. The tools differ only in how a person or program talks to those APIs. This lesson tours the four main ways in: the console, Cloud Shell, the Google Cloud CLI and the APIs themselves, with client libraries and infrastructure as code on top.

The Google Cloud console

The Google Cloud console is the web interface at console.cloud.google.com. It shows projects, resources, billing, logs and monitoring in one place, with a project selector at the top that decides which project you are looking at. Most products have their own page, and a search bar finds products, resources and documentation. The console is the easiest way to explore, to see the state of a system at a glance, and to do one-off tasks.

The console has helpful features that Owen relies on. Many creation forms have a button that shows the equivalent command line or REST request for the settings chosen, which is an excellent way to learn gcloud. Dashboards can be customized per project. The Activity view and the logs explorer show recent changes. And recommendations, such as idle resources or oversized VMs, appear beside the resources they concern.

The console's limitation is repeatability. A setting chosen by hand on Tuesday is easy to forget on Thursday, and two people clicking the same form often choose slightly different options. That is why Birchline uses the console mainly for viewing and investigation in production, while changes go through commands, scripts and code that can be reviewed.

Cloud Shell

Cloud Shell is a command-line environment that runs in the browser. Clicking its icon in the console opens a terminal connected to a small temporary virtual machine that Google provides at no charge. It comes with the Google Cloud CLI and common tools already installed, including kubectl, Terraform, Git, Python and Docker, and it is already signed in as the person using the console. There is nothing to install and nothing to configure, which makes it ideal for quick tasks, for following tutorials and for working from a locked-down laptop.

Cloud Shell gives each user a small persistent home directory, 5 GB, that survives between sessions, while the rest of the virtual machine is reset. Files saved in the home directory, such as scripts and configuration, are still there next time; software installed elsewhere on the system is not. Cloud Shell also includes a browser-based code editor for editing files in that home directory. Sessions end after a period of inactivity, so it is not a place to run long jobs.

The Google Cloud CLI

The Google Cloud CLI is the set of command-line tools for Google Cloud. Its main command is gcloud, which manages most Google Cloud resources. Related commands include bq for BigQuery, kubectl for Kubernetes clusters (installed as a component), and gcloud storage for Cloud Storage, which has replaced the older gsutil tool for most tasks. The CLI can be installed on Windows, macOS and Linux, and it is already present in Cloud Shell and on Google's standard VM images.

gcloud commands follow a consistent shape: gcloud, then a product group, then sometimes a subgroup, then a verb, then the resource name and flags. Once Owen saw the pattern, he could often guess commands he had never used, and gcloud's built-in help confirmed them.

gcloud compute instances list
gcloud compute instances create web-test-1 --zone=northamerica-northeast2-a --machine-type=e2-small
gcloud run services describe shop-web --region=northamerica-northeast2
gcloud storage ls gs://bl-photos-prod
gcloud help compute instances create

Configurations and authentication

gcloud keeps settings in configurations, named sets of properties such as the account, the default project, and the default region and zone. A person who works across several projects can create one configuration for each and switch between them, which avoids the classic mistake of running a command against the wrong project. The --project flag on any command overrides the default for that command alone.

gcloud init
gcloud config configurations create shop-dev
gcloud config set project bl-shop-dev
gcloud config set compute/region northamerica-northeast2
gcloud config configurations list
gcloud config configurations activate shop-dev

Before gcloud can act, it must know who is calling. gcloud auth login signs a person in through the browser and stores credentials for the CLI. Separately, application default credentials are used by client libraries and tools such as Terraform: on a developer's laptop, gcloud auth application-default login sets them up for local testing; on Google Cloud, a workload uses its attached service account automatically, as lesson 4 explained. Either way, every request carries an identity, and IAM checks it.

Output you can use

gcloud prints human-readable tables by default, but the --format flag can return JSON, YAML, CSV or just the fields you choose. That makes gcloud output easy to feed into scripts and reports. Owen saves a project's VM list as JSON and processes it with a short Python script; here the JSON is included directly so the example runs anywhere.

import json
output = """[
 {"name": "web-1", "zone": "zone-a", "machineType": "e2-medium", "status": "RUNNING", "labels": {"env": "dev", "team": "ecommerce"}},
 {"name": "web-2", "zone": "zone-b", "machineType": "e2-medium", "status": "TERMINATED", "labels": {"env": "dev", "team": "ecommerce"}},
 {"name": "batch-1", "zone": "zone-a", "machineType": "n2-standard-4", "status": "RUNNING", "labels": {"env": "dev"}}
]"""
vms = json.loads(output)
for vm in vms:
    missing = {"env", "team"} - set(vm.get("labels", {}))
    flag = "missing " + ", ".join(sorted(missing)) if missing else "ok"
    print(f"{vm['name']:8} {vm['status']:10} {flag}")

web-1    RUNNING    ok
web-2    TERMINATED ok
batch-1  RUNNING    missing team

In real use the JSON would come from a command such as gcloud compute instances list --format=json. The script finds the VM with a missing team label, the kind of check that helps keep Ravi's cost report clean.

APIs and client libraries

Underneath every tool are the Google Cloud APIs. Each service exposes an API, usually as REST over HTTPS and often also as gRPC, with documented methods such as instances.insert or buckets.list. Requests are authenticated with OAuth 2.0 access tokens tied to a principal. Programs can call the APIs directly, but most use Cloud Client Libraries, which Google provides for languages including Python, Java, Go, Node.js, C#, Ruby and PHP. Client libraries handle authentication, retries and data formats, so developers write a few lines of code instead of raw HTTP requests.

An API must be enabled in a project before the project can use the service, for example the Compute Engine API or the Cloud SQL Admin API. Enabling an API does not by itself cost anything, but it lets the project create billable resources. Some APIs are enabled by default; others are enabled from the console's API Library or with gcloud services enable. Each enabled API also has quotas, such as requests per minute, which lesson 5 introduced.

gcloud services list --enabled
gcloud services enable sqladmin.googleapis.com run.googleapis.com

Infrastructure as code

Scripts of gcloud commands are a big step up from clicking, but they describe steps, not results. If a script half-fails, it is not always clear what exists. Infrastructure as code (IaC) describes the desired end state of resources in files, and a tool works out what to create, change or delete to reach it. The files live in version control, changes are reviewed like code, and the same files can build identical development, test and production environments.

Terraform is the most widely used IaC tool for Google Cloud, with Google maintaining the Google Cloud provider. Google also offers Infrastructure Manager, a managed service that runs Terraform configurations in Google Cloud and keeps their state. Birchline's platform team builds folders, projects, networks, IAM grants and organization policies with Terraform, and the shop team defines its Cloud Run services the same way. The console is still open to everyone for viewing, but changes to production come through reviewed pull requests.

resource "google_storage_bucket" "photos" {
  name                        = "bl-photos-prod"
  location                    = "NORTHAMERICA-NORTHEAST2"
  uniform_bucket_level_access = true
  labels = { env = "prod", team = "ecommerce", system = "shop", cost-centre = "4120" }
}

Other ways in

A few more tools round out the picture. The Google Cloud mobile app shows incidents, billing and resource status, and can run some actions from a phone, which the on-call engineer appreciates. Cloud Code extensions bring Google Cloud tools into popular code editors. Gemini Cloud Assist and other AI assistance features in the console can explain resources, suggest commands and help investigate problems; Farah encourages Owen to use them, and to check the suggestions as carefully as anything else he runs against production.

Habits for working safely at the command line

Farah gives Owen a short list of habits she learned the hard way. First, read the prompt before pressing Enter: gcloud asks for confirmation before deleting things, and the confirmation names the resource and project, so it is worth reading rather than typing Y by reflex. The --quiet flag skips those prompts, which is useful in scripts that have been tested and dangerous when typed by hand.

Second, make the current context visible. Cloud Shell and many terminals can show the active gcloud configuration and project in the prompt, and Owen sets his production configuration to use a different colour so that he notices when it is active. Third, prefer describe and list commands before update and delete commands: look at the resource first, confirm it is the one you mean, then change it.

Fourth, write scripts so they can run twice without harm. A script that creates a bucket should check whether the bucket already exists, or use a tool that handles that automatically, so that re-running it after a partial failure does not stop with an error halfway through. This property, called idempotence, is one of the main reasons the platform team prefers Terraform for anything permanent.

Finally, keep a record. Commands run in Cloud Shell are not an audit trail, but Cloud Audit Logs are: every change made through gcloud, the console or an API is recorded with the identity that made it. When Owen makes a manual change in an emergency, he writes the exact commands in the incident ticket as well, so that the fix can be turned into code afterwards.