The Google Cloud Platform resource hierarchy

Loading...

來自 Google Cloud 的課程

Google Cloud Platform Fundamentals: Core Infrastructure

7021 個評分

Google Cloud

Google Cloud Platform Fundamentals: Core Infrastructure

7021 個評分

課程 1（共 3 門，Specialization Networking in Google Cloud Platform）

<<< ATTENTION >>> Learners interested in Google Cloud Platform can continue to learn in either of our latest GCP infrastructure specializations. Option 1: The Developing Applications with Google Cloud Platform Specialization is available on Coursera. This brand-new Specialization teaches you to build secure, scalable, and intelligent cloud-native applications. Visit https://www.coursera.org/specializations/developing-apps-gcp for more details. Option 2: The Architecting with Google Cloud Platform Specialization is also available. This Specialization has updated, improved content that will help you if you are preparing for the Google Certified Professional - Cloud Architect exam. Head to https://www.coursera.org/specializations/gcp-architecture to explore the updated content. Google Cloud Platform Fundamentals: Core Infrastructure covers the fundamentals of Google Cloud Platform and is the first course in both specializations. This course introduces you to important concepts and terminology for working with Google Cloud Platform (GCP). You learn about, and compare, many of the computing and storage services available in Google Cloud Platform, including Google App Engine, Google Compute Engine, and Google Container Engine. Note: •Google services are currently unavailable in China.

從本節課中

Getting Started with Google Cloud Platform

GCP customers use projects to organize the resources they use. They use Google Cloud Identity and Access Management, also called “IAM,” to control who can do what with those resources. They use any of several technologies to connect with GCP. This module covers each of these topics, and it introduces a service called Cloud Launcher that is an easy way to get started with GCP.

The Google Cloud Platform resource hierarchy5:51

與講師見面

Google Cloud Training

You may find it easiest to understand the GCP resource hierarchy from the bottom up.

All the resources you use,

whether they're virtual machines, cloud storage buckets,

tables and big query or anything else in GCP are organized into projects.

Optionally, these projects may be organized into folders.

Folders can contain other folders.

All the folders and projects used by

your organization can be brought together under an organization node.

Project folders and organization nodes are all places where the policies can be defined.

Some GCP resources, let you put policies on individual resources too.

Like those cloud storage buckets I mentioned.

We'll talk more about cloud storage later in the course.

In the meantime, remember that policies are inherited downwards in the hierarchy.

All Google Cloud platform resources belong to a project.

Projects are the basis for enabling and using GCP services like managing APIs,

enabling billing and adding and removing

collaborators and enabling other Google services.

Each project is a separate compartment and each resource belongs to exactly one.

Projects can have different owners and users,

they're built separately and they're managed separately.

Each GCP project has a name and a project ID that you assign.

The project ID is a permanent unchangeable identifier and it has to be unique across GCP.

You use project IDs in several contexts to tell GCP which project you want to work with.

On the other hand, project names are for your convenience and you can assign them.

GCP also assigns each of your projects a unique

project number and you'll see a display to you in various contexts.

But using it is mostly outside the scope of this course.

In general, project IDs are made to be

human readable strings and you'll use them frequently to refer to projects.

You can organize projects into folders although you don't have to.

They're tool at your disposal to make your life easier.

For example, you can use folders to represent different departments,

teams, applications or environments in your organization.

Folders let teams have the ability to delegate administrative rights,

so they can work independently.

The resources in a folder inherit I am policies from the folder.

So, if project three and four are administered by the same team by design,

you can put I am policies into folder B instead.

Doing it the other way,

putting duplicate copies of those policies on

project three and project four would be tedious and error prone.

One word of caution, to use folders,

you need an organization node at the top of the hierarchy.

So what's that? Let's talk about it now.

You probably want to organize all the projects in your company into a single structure.

Most companies want the ability to have centralized visibility

on how resources are being used and to apply policy centrally.

That's what the organization node is for.

It's the top of the hierarchy.

There are some special roles associated with it.

For example, you can designate

an organization policy administrator so that

only people with privilege can change policies.

You can also assign a project creator role,

which is a great way to control who can spend money.

So how do you get an organization node?

In part the answer depends on whether your company is also a Gswee customer.

If you have a Gswee domain,

GCP projects will automatically belong to your organization node.

Otherwise, you can use google cloud identity to create one.

Here's a tip, when you get a new organization node,

it lets anyone in the domain create

projects and billing accounts just as they could before.

That's to avoid surprises and disruption.

But it be a great first step with a new organization node to

decide who on your team should really be able to do those things.

Once you have an organization node,

you can create folders underneath it and put it in projects.

Here's an example of how you might organize your resources.

There are three projects each of which uses resources from several GCP services.

In this example, we haven't used

any folders although we could always move projects into folders.

Resources inherit the policies of their parent resource.

For instance, if you set a policy at the organization level,

it is automatically inherited by all its children projects.

And this inheritance is transitive,

which means that all the resources in those projects inherit the policy too.

There's one important rule to keep in mind.

The policies implemented at a higher level in

this hierarchy can't take away access that's granted at a lower level.

For example, suppose that a policy applied on

the bookshelf project gives user PAC the right to modify a cloud storage bucket,

but a policy at the organization level says that PAC can only

view cloud storage buckets not change them.

The more generous policy is the one that takes effect.

Keep this in mind as you design your policies.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2018 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取