🎬

Google Cloud CLI: Getting Started

🎬

Watch it on YouTube.

In this article I'll show you how to really get started with Google Cloud, because CLI is the way to go. Only CLI let you deploy stuff with a single command, create automated pipelines, and even configure things that are not really configurable in Google Cloud UI!

Create a Project

If you don’t have a Google Cloud Project yet, head to https://cloud.google.com, log in with your personal Gmail account, accept the $300 free credit. Create a new project, name it distinctively and make sure the project id is available!

image

No problem, you can thank me later, after writing your project id for the ten thousandth time.

How to interact with Google Cloud

You can do it using Google Cloud UI or Cloud Shell as most tutorials suggest, but these are suboptimal ways, and you are here to learn things that are actually useful, right? So, don’t bother learning how to do something in UI unless you have to. It lacks some features, and it is painfully slow.

As for the Cloud Shell - it’s just a web interface replicating the capabilities of the Terminal on your machine. It might be helpful, though, if you are away from your computer and need to do something urgently using your phone. So, Terminal it is.

Install gcloud CLI

To control Google Cloud resources from a Terminal, you’ll need to install the gcloud CLI. Head to https://cloud.google.com/sdk/docs/install, download it, and run the installation script. If you are on mac, then just use Homebrew: brew install --cask google-cloud-sdk.

gcloud auth login

Now I can control all the Google Cloud resources using just a terminal window.

Create a service Account

It’s like a regular user on google cloud, but it doesn’t need a Gmail account. Also, machines can easily use it to control your Google Cloud Project.

I set the PROJECT_ID variable in this terminal window for the sake of reusability.

The first rule of gcloud - always set the project id. Remember this command. You’ll need this a lot.

gcloud config set project $PROJECT_ID

The second rule of gcloud - always set the compute zone.

gcloud config set compute/zone us-central1-a

Always set project and zone before doing anything else to make sure you are changing resources in the right zone and project.

The zone is basically google’s data center location. Pick the one closest to your users or just use the default one, which is us-central1-a. Keep in mind, though, that some zones have limited capabilities.

And the third rule is - verify it.

gcloud config list

Next, I create a service account and name it distinctively because I’ll need to refer to it for as long as I’m working with this Google Cloud Project.

gcloud iam service-accounts create all-mighty-dev

I store this account as a variable for ease use

ACCOUNT_ID="all-mighty-dev@$PROJECT_ID.iam.gserviceaccount.com"

Service Account Permissions

Give this account permissions to edit my project resources. This is a tricky one. Pay close attention.

Naturally, you may want to do something like that

gcloud iam service-accounts

then lookup available methods using --help flag and end up writing this command:

gcloud iam service-accounts add-iam-policy-binding $ACCOUNT_ID \
  --member="serviceAccount:$ACCOUNT_ID" \
  --role="roles/editor"

This will work, and you’ll spend hours trying to understand why on earth doesn’t the “editor” role give your account fucking editor permission.

Well, turns out this command gives your service account permission to go edit itself.

Here is what is happening. The iam service-accounts is the resource type, and $ACCOUNT_ID is the resource name you are giving the permissions to.

What you really need is this:

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$ACCOUNT_ID" \
  --role="roles/editor"

Anyways, the Editor role is way too loose. It gives your account permission to do pretty much anything on your whole Google Cloud Project. In 90 days Google will start generating permission recommendations, and you can painlessly accept them instead of manually picking the right ones. This approach is not suitable for production-ready projects, but it makes things much easier during the initial development.

Next, I’ll navigate to my project directory and then create and download the json key for this service account:

gcloud iam service-accounts keys create ./dev-key.json \
  --iam-account=all-mighty-dev@$PROJECT_ID.iam.gserviceaccount.com

That’s it. Now I have a JSON key for the service account that can deploy stuff. I can use it here on my laptop or put it in a Continuous Integration pipeline to run the deploy script in a Cloud.

Let's deploy something?

See you later!