The course is part of these learning pathsSee 3 more
Google Cloud Platform: Fundamentals
If you’re going to work with modern software systems, then you can escape learning about cloud technologies. And that’s a rather broad umbrella. Across the three major cloud platform providers, we have a lot of different service options, and there’s a lot value in them all.
However, the area that I think Google Cloud Platform excels in is providing elastic fully managed services. Google Cloud Platform to me, is the optimal cloud platform for developers. It provides so many services for building out highly available - highly scalable web applications and mobile back-ends.
For me personally, Google Cloud Platform has quickly become my personal favorite cloud platform. Now, opinions are subject, but I’ll share why I like it so much.
I’ve worked as a developer for years, and for much of that time I was responsible for getting my code into production environments and keeping it running. I worked on a lot of smaller teams where there were no operations engineers.
So, here’s what I like about the Google Cloud Platform, it allows me to think about the code and the features I need to develop, without worrying about the operations side. Because many of the service offerings are fully managed.
So things such as App Engine allow me to write my code, test it locally, run it through the CI/CD pipeline, and then deploy it. And once it’s deployed, for the most part, unless I’ve introduced some software bug, I don’t have to think about it. Google’s engineers keep it up-and-running, and highly available. And having Google as your ops team, is really cool!
Another thing I really like about is the ease of use of things such as BigQuery and their Machine Learning APIs. If you’ve ever worked with large datasets, you know that some queries take forever to run. BigQuery can query massive datasets in just seconds. Which allows me to get the data I need quickly, so I can move on to other things.
And with the machine learning APIs I can use a REST interface to do things like language translation, or speech to text, with ease. And that allows me the ability to integrate this into my applications, which gives the end-users a better user experience.
So for me personally, I love that I can focus on building out applications; and spend my time adding value to the end-users.
If you’re looking to learn the fundamentals about a platform that’s not only developer friendly, but cost friendly, then this is the right course for you!
By the end of this course, you'll know:
- The purpose and value of each products and services
- How to choose an appropriate deployment environment
- How to deploy an application to App Engine, Container Engine, and Compute Engine
- The different storage options
- The value of cloud Datastore
- How to get started with BigQuery
This is a intermediate level course because it assumes:
- You have at least a basic understanding of the cloud
- You’re at least familiar with building and deploying code
What You'll Learn
SummaryA review of the course
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Introducing Google Cloud Platform||An introduction to the Google Cloud Platform|
|Getting Started||A review of projects and permissions.|
|App Engine and Cloud Datastore||An intro to the PaaS option for building web apps and the NoSQL database that works so well with App Engine.|
|Cloud Storage Options||What options exist for data storage?|
|Container Engine||How do we run Docker containers in the cloud?|
|Compute Engine||The IaaS option on Google Cloud.|
|Big Data and Machine Learning.||What options exist for data processing and machine learning|
Welcome back to Google Cloud Platform: Fundamentals. I'm Ben Lambert, and I'll be your instructor for this lesson. In this lesson, we're going to talk about Cloud platform projects, identity and access management, and interacting with the Google Cloud Platform. Let's start with projects. All Cloud Platform resources belong to a project.
Projects are the basis for enabling and using services, including managing APIs, enabling billing, adding and removing collaborators, and enabling other Google services. Each project is kind of it's own thing, consider it like a box. Each box can have it's own services and resources inside. Projects are billed and managed separately.
Now, this is something I really like, because we're able to use the concept of a project to break things down by their purpose. For example, you could have a project that is for your production web application, and then you could create another project that serves as a playground for developers, and that would allow them to try out new things without worrying about making changes that would impact your production application, because they're in completely separate projects.
Or you could break things down into separate projects, such as development, test, and production, allowing you to use these different environments at different points in your continuous integration, and continuous delivery process. Projects have three different types of identifiers. They have the project name, the project number, and the project ID.
The name is something that you can set. It's basically a user friendly identifier for your project, and it should allow you to recognize at a glance what that project is. The project number is something automatically generated for you by Google, and it can't be changed, and the project ID, it's something that you can initially set, but once it's set, you can't change it.
These IDs have a global unique scope, which means if I create one with a value of my-awesome-ID, then you won't be able to use that for yours, and if you created it first, I couldn't use it for mine. You can find these identifiers in the console under the IAM & Admin section, and then under the settings option.
You can interact with projects in two ways. One is through the Cloud Console, which is the web user interface we saw in our last lesson, after we created and logged into our account, and the other is through the Google Cloud Resource Manager API, which is not yet in general availability as of this recording.
However, it allows you to get a list of all projects associated with an account, create new projects, update existing projects, delete projects, and even undelete or recover projects that you don't want to delete. So, now that we've talked about projects, and the role they serve, let's actually create one.
We'll create a project called GCP Fundamentals, and we'll use it throughout the rest of the course. So, we'll start by clicking the dropdown at the top right hand side of the screen, and selecting create a project. By default, the dialog box asks for the name. Remember from earlier we said that the name is the user friendly name for the project, and if you click on this link here, you'll see that you can also edit the project ID.
Remember, this is globally unique, which is why you'll find that it automatically populates with a random name. It does this so that if you don't care to create your own project ID, you don't have to. However, if you want to, you also can, so, if you do want to change the ID, you'll want to make sure that you do it before you change the name of the project, or this is going to happen.
Alright, I'm gonna set the ID to some random string, and now watch what happens to the ID when I change the project name. Notice the change on this? Okay, so let's name the project first. We'll call it GCP Fundamentals, and then we'll set the ID, and we just want to make sure that this ID is globally unique, and then we'll have one additional option here, which is the show advanced options, and if we click this, we can see that we have a drop down that has a list of app engine locations.
This determines the regions that app engine will run in. Remember, regions are physical locations in the world where one or more zones exist, and zones are basically just data centers. So, I'm gonna choose us-east1 for no other reason than, I live on the east coast. So, now that we're happy with everything else, let's click create here.
Okay, behind the scenes, the project is being created, and you can see it pops up a notification on the lower left hand side of the screen, and in the top right, you can see this loading icon. It's swirling around the notification icon. Now, this can take a few seconds, and that's not uncommon. So, let's give it a little bit of time.
However, once it's done, it'll set the project as the current project, and return us to the dashboard. Notice the drop down that we used previously to select create new project now has the name GCP Fundamentals selected. It's worth mentioning now, before you start building out your apps, always make sure you're in the right project, before making any changes.
It's not uncommon to make a change to something in one project, forget that you're in that particular project, and then forget to switch to a different one before making another change, so you don't wanna make a change to the wrong project. It's just something to keep an eye on. Projects are a great way to organize your applications, however, it won't do you much good, if you can't give people the access they need, to do what they need to do.
And for that, we have two forms of roles, primitive roles, and predefined roles. Primitive roles, as the names suggests, are the original roles. Predefined roles are the newer, more granular roles. There are three primitive roles, and they're concentric, meaning that the less permissive roles are included in the more permissive roles.
Starting with the least permissive, a viewer role can view aspects of a project. The editor role, which includes the viewer role, can perform actions that change the project state. This includes things such as configuring services, and deploying applications. The primitive role with the most permissions is the owner role, which includes editor and viewer, and has the ability to invite members and remove members, as well as delete a project.
Now, what if you need finer-grain control over your resources than the primitive roles provide? Well, that's where identity and access-management predefined roles come into play. Identity and access-management is usually abbreviated as IAM, and it's used to determine who can do what to which resource.
In Cloud IAM, you grant access to the following types of identities, we have Google accounts, service accounts, Google groups, and Google app domains. Let's go through these. A Google account is a developer, administrator, or any person who uses the Google Cloud Platform. A service account is an account that belongs to your application instead of an individual user.
It allows you to specify the account that your code runs as. This lets your applications interact with Google Cloud services, such as Cloud storage and BigQuery, without the need to provide credentials in your code. You can create as many service accounts as you need in order to represent the different logical components of your applications.
A Google group is a named collection of Google accounts and service accounts. Every group has a unique email address associated with the group that you can find on the home page of the group by clicking the about link. Groups will allow you to apply policies to multiple users, so that you can change the access controls for a group of users, all at the same time.
And next we have Google App Domain. Google App Domain represents a virtual group of all the members in your organization. So if you use Google Apps, you can associate your email account with your domain, which allows you to use an email address from your own domain, rather than the Gmail domain, while using Gmail under the hood.
So, you can specify an identity by using any domain that is associated with a Google Apps account. We said previously that IAM is about who can do what to which resource. So, these identities that we just talked about are the who portion of that. And roles and permissions are the can do what portion, and that makes resources the to which resource portion.
Resources are things such as projects, virtual machine instances, Cloud storage, et cetera. Permissions determine what operations are allowed on a given resource. For Cloud IAM, permissions are represented in the form of service dot resource dot verb. An example of this would be something like, pubsub dot subscriptions dot consume, where pubsub is the service, subscriptions is the resource, and consume is the verb.
So if you wanted to call a particular method, then you'll need permissions for that method. Here's another example. If you wanted to call the publish method of the pubsub service, you would need pubsub dot topics dot publish permissions. So, permissions allow you to determine what operations are allowed on a resource, however, you can't assign permissions to a user directly.
Permissions are assigned to roles. So, a role is just a collection of permissions. When you grant a role to a user, you grant them all of the permissions that role contains. So, that's identity and access management at a very high level. Next, let's talk about interacting with the Cloud Platform. We talked about the console a bit throughout the lesson.
It's the user interface that we interact with Google Cloud Platform with. However, it's not the only method available. There are three ways to interact with the Google Cloud Platform. First is the Cloud Console, that's the web interface we've used so far, and we have the Cloud SDK, which is a software development kit, which can be run either locally or via Cloud Shell, and then we have the REST-based API.
The Cloud Console provides you with one centralized user interface to interact with all of your projects, with the ability to access product APIs and create and manage projects. It also has some developer tools loaded, such as the Cloud Shell, which will allow you to interact with the Cloud source code repositories, and the Cloud SDK.
The Cloud SDK provides command line tools such as gcloud, gsutil, and BigQuery. We'll be using the SDK throughout the course, so let's review the different commands that it provides. We have gcloud, which manages authentication, local configuration, developer workflow, and interactions between the Cloud Platform APIs.
We have the gsutil command, which is the Google storage utility command, it provides command-line access to manage Cloud storage buckets and objects. We have the bq command, which is the BigQuery command, it allows you to run queries, manipulate data sets, tables and entities in BigQuery through the command line.
And finally, we have the cube control command, which orchestrates the deployment and management of Kubernetes container clusters on gcloud. The SDK is available as a doc or image, and via the Cloud Shell. We've mentioned the Cloud Shell a couple of times now, but what exactly is it? Cloud Shell is a browser-based terminal, which means you get command-line access from your browser.
It works by starting up temporary virtual machine instances running Debian-based versions of Linux. So you'll get five gigabytes of persistent storage that's attached to your home directory. The Cloud SDK is pre-loaded, along with some other useful tools and programming languages. A feature I really like is the web preview, which allows you to run the development server in the Cloud Shell, and view the results in your browser.
And that's really cool. So, having all of this allows you to create and manage Compute Engine instances, create and access Cloud SQL databases, manage Google Cloud Storage data, interact with hosted or remote Git repositories, including Cloud sourced code repositories, and build and deploy Google App Engine applications.
And you can also perform other management tasks that are related to projects, resources, et cetera, using gcloud and other commands. And finally, we have the REST APIs, which give you programmatic access to products and services. The different APIs can be enabled through the console. Each API will have its own daily quotas and rates, and if you need to increase these daily limits, you can contact Google, and have them increase these caps for you.
In order to help out when using APIs, you can use the API explorer. The API explorer is an interactive tool that allows you to easily try out these different Google APIs in your browser. So, you can execute requests for any of these methods and see the responses in real time. There are also client libraries that are built around the REST APIs, allowing you to more quickly integrate with your project in the programming language of your choosing.
Okay, we've talked a lot about getting started with Google Cloud Platform, let's see how quickly we can get a LAMP stack up and running. LAMP stands for Linux Apache MySQL and PHP, and it's a pretty common set of technologies for building web applications. Once we're logged in to the console, we'll click on the menu on the top left, and just a few items down the list, we'll have Cloud launcher.
We're gonna click that, and it's gonna take us to the Cloud launcher landing page. Right off, if you scroll down you're gonna see a lot of options for pre-configured setups. We have operating systems, data bases, blogging platforms, content management systems and more. Let's use the search at the top, to filter out our request to just the LAMP stuff.
So, you can see here we have two options to choose from. I'm gonna select the one named LAMP Stack, it's in beta, but for our demo purposes, that's fine. Now, if we scroll down on this, we'll see some details about what's involved in this setup. We'll see the pricing information as well. And this assumes that our server is gonna be running 24-7, so if this seems like a pricey demo, then that's why.
So, we're gonna click the launch button, and it's gonna take just a moment to do its thing, but when it's completed, we're gonna get this screen here. This is gonna allow us to make some changes to the default configuration. We can change things like the region and the zone this is gonna be deployed into, and the instance type, we can change the boot disk, and some networking info.
Let's go ahead and deploy this with the deploy button on the bottom of the page. This takes us to our deployment manager. Here we can see the status of the different components that are being installed. After a few moments, we see that the server has been deployed, and now we just wait for the software to be installed and configured.
And once it's installed, we get some details about what's been installed, usernames, passwords, and next steps. If we click the site address link, we can see that the server is set up with Apache, and it's just awaiting our code. We can also connect into the server that was set up by clicking the SSH button here.
If we click the ellipses next to the SSH button, we can see that we have some options regarding how we connect, but by default, we'll connect in, in a separate browser tab with the web-based console. Let's check that out. If we change directories now, into the slash var, slash dub dub dub, slash html folder, we can remove the html file and replace it with a PHP file.
Then we can restart Apache, and test this out. So, let's change directories, we're gonna move into the var, dub dub dub, html, and let's just get rid of the index dot html file. Now, let's use nano to create an index dot PHP, and let's just paste in a very simple hello world sample. Great, now let's save the file.
Okay, we also wanna restart the web server, so we can restart the Apache2 service. Perfect, and now if we go back to our web page again and run it, we're gonna see hello world. So, let's clean up after ourselves, we're gonna remove this stack from our project, and we can do that by selecting it here, in the deployment manager, and clicking on the delete link at the top.
It'll take just a few minutes to wrap up, but when it's done, it will remove all of the resources that it added. So, in the span of just a few minutes, we were able to have an environment set up and configured for us, and even connect in and test it out with relative ease. Let's summarize what we've covered.
Google Cloud Platform uses the concept of projects for tracking resource usage, enabling billing, managing permissions and enabling services and APIs. It uses identity and access management to determine who can do what to which resource. And, you can interact with the Google Cloud Platform via the web user interface, called the Cloud Console, via the Cloud SDK, which includes several command-line tools, and the REST API.
In our next lesson, we'll take a look at App Engine and Cloud Datastore. So, if you're ready, let's get started.
About the Author
Ben Lambert is the Director of Engineering and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps.
When he’s not building the first platform to run and measure enterprise transformation initiatives at Cloud Academy, he’s hiking, camping, or creating video games.