Getting started with Google Cloud Platform
Getting started with Google Cloud Platform (GCP) is easy and straightforward. Here are the basic steps to get started:
Signing up for GCP
Before you can start using any of Google’s Cloud services, you first need to sign up for an account. If you already have a Google account (such as a Gmail account), you can use that to log in, but you’ll still need to sign up specifically for a cloud account. If you’ve already signed up for Google Cloud Platform , feel free to skip ahead. First, navigate to https://cloud.google.com, and click the button that reads “Try it free!” This will take you through a typical Google sign-in process. If you don’t have a Google account yet, follow the sign-up process to create one.
If you’re eligible for the free trial, you’ll see a page prompting you to enter your billing information. The free trial, shown in figure 2, gives you $300 to spend on Google Cloud over a period of 12 months, which should be more than enough time to explore all the things in this book. Additionally, some of the products on Google Cloud Platform have a free tier of usage. Either way, all the exercises in this book will remind you to turn off any resources after the exercise is finished.
Exploring the console
After you’ve signed up, you are automatically taken to the Cloud Console, shown in figure 3, and a new project is automatically created for you. You can think of a project like a container for your work, where the resources in a single project are isolated from those in all the other projects out there
On the left side of the page are categories that correspond to all the different services that Google Cloud Platform offers (for example, Compute, Networking, Big Data, and Storage), as well as other project-specific configuration sections (such as authentication, project permissions, and billing). Feel free to poke around in the console to familiarize yourself with where things live.
Understanding projects
When we first signed up for Google Cloud Platform, we learned that a new project is created automatically, and that projects have something to do with isolation, but what does this mean? And what are projects anyway? Projects are primarily a container for all the resources we create. For example, if we create a new VM, it will be “owned” by the parent project. Further, this ownership spills over into billing—any charges incurred for resources are charged to the project. This means that the bill for the new VM we mentioned is sent to the person responsible for billing on the parent project.
In addition to acting as the owner of resources, projects also act as a way of isolating things from one another, sort of like having a workspace for a specific purpose. This isolation applies primarily to security, to ensure that someone with access to one project doesn’t have access to resources in another project unless specifically granted access. For example, if you create new service account credentials inside one project, say project-a, those credentials have access to resources only inside project-a unless you explicitly grant more access
On the flip side, if you act as yourself (for example, [email protected]) when running commands , those commands can access anything that you have access to inside the Cloud Console, which includes all of the projects you’ve created, as well as ones that others have shared with you. This is one of the reasons why you’ll see much of the code we write often explicitly specifies project IDs: you might have access to lots of different projects, so we have to clarify which one we want to own the thing we’re creating or which project should get the bill for usage charges. In general, imagine you’re a freelancer building websites and want to keep the work you do for different clients separate from one another. You’d probably have one project for each of the websites you build, both for billing purposes (one bill per website) and to keep each website securely isolated from the others. This setup also makes it easy to grant access to each client if they want to take ownership over their website or edit something themselves
Now that we’ve gotten that out of the way, let’s get back into the swing of things
and look at how to get started with the Google Cloud software development kit (SDK).
Installing the SDK
After you get comfortable with the Google Cloud Console, you’ll want to install the Google Cloud SDK. The SDK is a suite of tools for building software that uses Google Cloud, as well as tools for managing your production resources. In general, anything you can do using the Cloud Console can be done with the Cloud SDK, gcloud. To install the SDK, go to https://cloud.google.com/sdk/, and follow the instructions for your platform. For example, on a typical Linux distribution, you’d run this code:
$ export CLOUD_SDK_REPO=”cloud-sdk-$(lsb_release -c -s)”
$ echo “deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main” | \
sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
$ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo \
apt-key add –
$ sudo apt-get update && sudo apt-get install google-cloud-sdk
Feel free to install anything that looks interesting to you—you can always add or remove components later on. For each exercise that we go through, we always start by reminding you that you may need to install extra components of the Cloud SDK. You also may be occasionally prompted to upgrade components as they become available. For example, here’s what you’ll see when it’s time to upgrade:
Updates are available for some Cloud SDK components. To install
them, please run:
$ gcloud components update
As you can see, upgrading components is pretty simple: run gcloud components update, and the SDK handles everything. After you have everything installed, you have to tell the SDK who you are by logging in. Google made this easy by connecting your terminal and your browser:
$ gcloud auth login
Your browser has been opened to visit:
You should see a normal Google login and authorization screen asking you to grant the Google Cloud SDK access to your cloud resources. Now when you run future gcloud commands, you can talk to Google Cloud Platform APIs as yourself. After you click Allow, the window should automatically close, and the prompt should update to look like this
$ gcloud auth login
Your browser has been opened to visit:
[A long link is here]
Created new window in existing browser session.
WARNING: `gcloud auth login` no longer writes application default credentials.
If you need to use ADC, see:
gcloud auth application-default --help
You are now logged in as [[email protected]].
Your current project is [your-project-id-here]. You can change this setting
by running:
$ gcloud config set project PROJECT_ID
You’re now authenticated and ready to use the Cloud SDK as yourself. But what about that warning message? It says that even though you’re logged in and all the gcloud commands you run will be authenticated as you, any code that you write may not be. You can make any code you write in the future automatically handle authentication by using application default credentials. You can get these using the gcloud auth subcommand once again:
$ gcloud auth application-default login
Your browser has been opened to visit:
[Another long link is here]
Created new window in existing browser session.
Credentials saved to file:
[/home/jjg/.config/gcloud/application_default_credentials.json]
These credentials will be used by any library that requests
Application Default Credentials.
Interacting with GCP
Now that you’ve signed up and played with the console, and your local environment is all set up, it might be a good idea to try a quick practice task in each of the different ways you can interact with GCP. Let’s start by launching a virtual machine in the cloud and then writing a script to terminate the virtual machine in JavaScript
In the browser: the Cloud Console
Let’s start by navigating to the Google Compute Engine area of the console: click the Compute section to expand it, and then click the Compute Engine link that appears. The first time you click this link, Google initializes Compute Engine for you, which should take a few seconds. Once that’s complete, you should see a Create button, which brings you to a page, shown in figure 4, where you can configure your virtual machine.
On the next page, a form (figure 5) lets you configure all the details of your instance, so let’s take a moment to look at what all of the options are
First there is the instance Name. The name of your virtual machine will be unique inside your project. For example, if you try to create “instance-1” while you already have an instance with that same name, you’ll get an error saying that name is already taken. You can name your machines anything you want, so let’s name our instance “learning-cloud-demo.” Below that is the Zone field, which represents where the machine should live geographically. Google has data centers all over the place, so you can choose from several options of where you want your instance to live. For now, let’s put our instance in us-central1-b (which is in Iowa).
Next is the Machine Type field, where you can choose how powerful you want your cloud instances to be. Google has lots of different sizing options, ranging from f1-micro (which is a small, not powerful machine) all the way up to n1-highcpu-32 (which is a 32-core machine), or a n1-highmem-32 (which is a 32-core machine with 208 GB of RAM). As you can see, you have quite a few options, but because we’re testing things out, let’s leave the machine type as n1-standard-1, which is a single-core machine with about 4 GB of RAM.
Many, many more knobs let you configure your machine further, but for now, let’s launch this n1-standard-1 machine to test things out. To start the virtual machine, click Create and wait a few seconds.
TESTING OUT YOUR INSTANCE
After your machine is created, you should see a green checkmark in the list of instances in the console. But what can you do with this now? You might notice in the Connect column a button that says “SSH” in the cell. See figure 6.
If you click this button, a new window will pop up, and after waiting a few seconds, you should see a terminal. This terminal is running on your new virtual machine, so feel free to play around—typing top or cat /etc/issue or anything else that you’re curious about
On the command line: gcloud
Now that you’ve created an instance in the console, you might be curious how the Cloud SDK comes into play. As mentioned earlier, anything that you can do in the Cloud Console can also be done using the gcloud command, so let’s put that to the test by looking at the list of your instances, and then connecting to the instance like you did with the SSH button. Let’s start by listing the instances. To do this, type gcloud compute instances list. You should see output that looks something like the following snippet
$ gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP
EXTERNAL_IP STATUS
learning-cloud-demo us-central1-b n1-standard-1 10.240.0.2
104.154.94.41 RUNNING
CONNECTING TO YOUR INSTANCE
Now that you can see your instance, you probably are curious about how to connect to it like we did with the SSH button. Type gcloud compute ssh learning-cloud-demo and choose the zone where you created the machine (us-central1-b). You should be connected to your machine via SSH:
$ gcloud compute ssh learning-cloud-demo
For the following instances:
- [learning-cloud-demo]
choose a zone:
[1] asia-east1-c
[2] asia-east1-a
[3] asia-east1-b
[4] europe-west1-c
[5] europe-west1-d
[6] europe-west1-b
[7] us-central1-f
[8] us-central1-c
[9] us-central1-b
[10] us-central1-a
[11] us-east1-c
[12] us-east1-b
[13] us-east1-d
Please enter your numeric choice: 9
Updated [https://www.googleapis.com/compute/v1/projects/glass-arcade-111313].
Warning: Permanently added '104.154.94.41' (ECDSA) to the list of known hosts.
Linux learning-cloud-demo 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-
1+deb8u3~bpo70+1 (2015-08-08) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
jjg@learning-cloud-demo:~$
Under the hood, Google is using the credentials it obtained when you ran gcloud auth login, generating a new public/private key pair, securely putting the new public key onto the virtual machine, and then using the private key generated to connect to the machine. This means that you don’t have to worry about key pairs when connecting. As long as you have access to your Google account, you can always access your virtual machines
In your own code: google-cloud
Now that we’ve created an instance inside the Cloud Console, then connected to that instance from the command line using the Cloud SDK, let’s explore the last way you can interact with your resources: in your own code. What we’ll do in this section is write a small Node.js script that connects and terminates your instance. This has the fun side effect of turning off your machine so you don’t waste any money during your free trial! To start, if you don’t have Node.js installed, you can do that by going to https://nodejs.org and downloading the latest version. You can test that all of this worked by running the node command with the –version flag
$ node --version
v7.7.1
After this, install the Google Cloud client library for Node.js. You can do this with the npm command:
$ sudo npm install –save @google-cloud/[email protected]
Now it’s time to start writing some code that connects to your cloud resources. To start, let’s try to list the instances currently running. Put the following code into a script called script.js, and then run it using node script.js
Showing all VMs (script.js)
const gce = require('@google-cloud/compute')({
projectId: 'your-project-id'
});
const zone = gce.zone('us-central1-b');
console.log('Getting your VMs...');
zone.getVMs().then((data) => {
data[0].forEach((vm) => {
console.log('Found a VM called', vm.name);
});
console.log('Done.');
});
If you run this script, the output should look something like the following:
$ node script.js
Getting your VMs…
Found a VM called learning-cloud-demo
Done
Now that we know how to list the VMs in a given zone, let’s try turning off the VM using our script. To do this, update your code to look like this.
Showing and stopping all VMs
const gce = require('@google-cloud/compute')({
projectId: 'your-project-id'
});
const zone = gce.zone('us-central1-b');
console.log('Getting your VMs...');
zone.getVMs().then((data) => {
data[0].forEach((vm) => {
console.log('Found a VM called', vm.name);
console.log('Stopping', vm.name, '...');
vm.stop((err, operation) => {
operation.on('complete', (err) => {
console.log('Stopped', vm.name);
});
});
});
});
This script might take a bit longer to run, but when it’s complete, the output should look something like the following:
$ node script.js
Getting your VMs…
Found a VM called learning-cloud-demo
Stopping learning-cloud-demo …
Stopped learning-cloud-demo
.The virtual machine we started in the UI is in a “stopped” state and can be restarted later. Now that we’ve played with virtual machines and managed them with all of the tools available (the Cloud Console, the Cloud SDK, and your own code), let’s keep the ball rolling by learning how to deploy a real application using Google Compute Engine
Leave a Comment