Road to Google Associate Cloud Engineer 2020 Certification — GCloud SDK and the command line
It is possible to control the Google Cloud Platform in several ways:
- Through the web console (https://cloud.google.com/)
- Through the Command Line installing the GCloud SDK
- Through the REST API
At the beginning you will use more the web console. But then, you will realize that the certification exam requires a good knowledge of the GCloud SDK command line (CLI).
When I started to do the first exam dumps I was quite worried by the presence of this kind of questions thinking I had to memorize the exact syntax of the commands.
Have the Cheat Sheet with a list of the commands and other information is very useful while practicing with the GCloud SDK
Reading some blog posts I then realized that you’re not supposed to do learn exactly all the commands but rather understand the logic and the patterns behind the GCloud SDK.
Let’s consider the SDK already installed on the computer and let’s see what’s the logic behind the syntax of the commands.
Initialization
The initialization of the Gcloud SDK can be launched with:
gcloud init
This launches an interactive Getting Started workflow for the command-line tool:
- Authorizes gcloud and other SDK tools to access Google Cloud Platform using your user account credentials, or from an account of your choosing whose credentials are already available.
- Sets up a new or existing configuration.
- Sets properties in that configuration, including the current project and optionally, the default Google Compute Engine region and zone you’d like to use.
gcloud init can be used for initial setup of gcloud and to create new or reinitialize gcloud configurations.
The initialization command can be present in some questions asking, for example, what’s the first action you should do after having installed the SDK.
Configuration
Another important concept to understand is the configuration. There are questions with the following scenario :
“You have succesfully deployed a new App Engine application with the command gcloud app deploy but you can’t see it in your project. You realize that it has been deployed in the wrong project. How can you see check in which project it has been deployed?”
In this case, you should just see the current configuration and see which project is active with the command:
gcloud config list
and see in the the value for the project in the core section (mycurrentproject in this case):
[app]
cloud_build_timeout = 1000
[core]
account = myemail@myemail.com
disable_usage_reporting = True
project = mycurrentproject
[gcloudignore]
enabled = true
So, gcloud config list will be the right answers.
When you have to manage several projects, it’s a good idea creating different configurations and activate the right one when needed. The command to do it is:
gcloud config configurations create my-config
The concept of default configuration can be found in some questions with a scenario similar to this:
“You created a compute instance by running gcloud compute instances create instance1. You intended to create the instance in project gcp-ace-proj-266520 but the instance got created in a different project. Your cloud shell gcloud configuration is as shown.”
$ gcloud config list[component_manager]
disable_update_check = True
[compute]
gce_metadata_read_timeout_sec = 5
zone = europe-west2-a
[core]
account = gcp-ace-lab-user@gmail.com
disable_usage_reporting = False
project = gcp-ace-lab-266520
[metrics]
environment = devshell
What should you do to delete the instance that was created in the wrong project and recreate it in gcp-ace-proj-266520 project?
In this case the right answers is (among the 4 that normally are proposed):
gcloud compute instances delete instance1
gcloud config set project gcp-ace-proj-266520
gcloud compute instances create instance1.
So globally, you first delete the wrong instance, you change the project of your default configuration and you create the instance that will be placed in the right project this time.
It’s a good idea to create different configurations with:
gcloud config configurations create my-config1
populate them with the correct values for each one and than switch between them with the command:
gcloud config configurations activate my_config1
You can list all the configurations you have created with:
gcloud config configurations list
Another important concept that help to spot correct answer for questions involving the configuration is the sections. Looking at the response to gcloud config list above, we find a [core] section and for example a [compute] one.
Remember that to change a value for a section different than [core] you will have to explicitly specify it in the command. For example, to change the default zone of the compute engine you will write
gcloud config set compute/zone europe-west1-b
using the pattern <section>/<argument> in compute/zone.
If you need to change the project for the default configuration you will write
gcloud config set project my-second-project
Since project is an argument of the core section, no need to use the notation <section>/<argument>
Structure of CLI commands
Let’s see an command example:
gcloud compute instances create myinstance –-zone=us-central1-a
This command crate a compute engine instance with name myinstance in the us-central1-a zone.
The structure of the commands for GCloud SDK follows the pattern below:
gcloud + release level (optional)+ component + entity + operation + positional args + flags
Looking at the example we’ll have:
- Release level: not present in our example. It can be alpha or beta. For General Availability (GA) there is no need of release level in the command
- Component: it’s the Gcloud service. In our example ‘compute’ for the Compute Engine service
- Entity: it’s the component of the service for which we execute the command. It’s in the plural form. In this case ‘instances’
- Operation, It’s a verb that says which action will be performed. ‘Create’ in our example
- Positional args, It’s the argument needed to perform the command. In our example it’s the instance name ‘myinstance’
- Flags, Any additional arguments that complete the command normally specifying more detailed configuration. It can be in the format — flag-only or — flag=<flag_value>. In our case it’s the –zone flag specifying the zone where we want create the instance ‘us-central1-a’
Learning the sequence of the parts composing a command makes possible to answer the questions about CLI command with a 100% accuracy.
Of course, learning also the operations and some positional args will make easier to spot the right answer but the command pattern is already enough to put you in the right direction.
A list of useful commands
A summary of important commands:
Commands for gcould config
gcloud config [configurations|get-value|list|set|unset]
List of all configurations
gcloud config configurations list
Create a new configuration for the Command Line:
gcloud config configurations create [NAME]
Switch/activate to a new configuration
gcloud config configurations activate [NAME]
List of active accounts
gcloud auth list
Check for beta commands
gcloud components install beta
Command to disable ssl validation
gcloud config set auth/disable_ssl_validation True
Help
gcloud help
Conclusions
We have seen some concepts around the initialization and configuration of the cloud SDK as well as some hints to spot and understand the right answers to some exam questions using the structure of the commands.
For every arguments we’ll explore, we’ll see some of the important CLI commands specific for each Google Cloud service. That will help to complete the notions and concepts to remember to find the right answer for questions involving the command line SDK.