This article helps you understand the overall landscape of Google Cloud. Here, you'll take a brief look at some of the commonly used features that are available and how the parts work together can help you make decisions about how to proceed.
Google Cloud Resources
Google Cloud consists of a set of physical assets, such as computers and hard disk drives, and virtual resources, such as virtual machines (VMs), that are contained in Google's data centers around the globe. Each data center location is in a region. Regions are available in Asia, Australia, Europe, North America, and South America. Each region is a collection of zones, which are isolated from each other within the region. Each zone is identified by a name that combines a letter identifier with the name of the region. For example, zone a in the East Asia region is named asia-east1-a.
This distribution of resources provides several benefits, including redundancy in case of failure and reduced latency by locating resources closer to clients. This distribution also introduces some rules about how resources can be used together.
Accessing resources through services
In cloud computing, what you might be used to thinking of as software and hardware products, become services. These services provide access to the underlying resources. When you develop your website or application on Google Cloud, you mix and match these services into combinations that provide the infrastructure you need, and then add your code to enable the scenarios you want to build.
Global, Regional, and Zonal Resources
Some resources can be accessed by any other resource, across regions and zones. These global resources include preconfigured disk images, disk snapshots, and networks. Some resources can be accessed only by resources that are located in the same region. These regional resources include static external IP addresses. Other resources can be accessed only by resources that are located in the same zone. These zonal resources include VM instances, their types, and disks.
The following diagram shows the relationship between global scope, regions, and zones, and some of their resources:
The scope of an operation varies depending on what kind of resources you're working with. For example, creating a network is a global operation because a network is a global resource while reserving an IP address is a regional operation because the address is a regional resource.
As you start to optimize your Google Cloud applications, it's important to understand how these regions and zones interact. For example, even if you could, you wouldn't want to attach a disk in one region to a computer in a different region because the latency you'd introduce would make for poor performance. Thankfully, Google Cloud won't let you do that; disks can only be attached to computers in the same zone.
Depending on the level of self-management required for the computing and hosting service you choose, you might or might not need to think about how and where resources are allocated.
Projects
Any Google Cloud resources that you allocate and use must belong to a project. You can think of a project as the organizing entity for what you're building. A project is made up of the settings, permissions, and other metadata that describe your applications. Resources within a single project can work together easily, for example by communicating through an internal network, subject to the regions-and-zones rules. A project can't access another project's resources unless you use Shared VPC or VPC Network Peering.
Each Google Cloud project has the following:
A project name, which you provide.
A project ID, which you can provide or Google Cloud can provide for you.
A project number, which Google Cloud provides.
As you work with Google Cloud, you use these identifiers in certain commands and API calls. The following screenshot shows a project name, a project ID, and a project number:
In this example:
Example Project is the project name.
example-id is the project ID.
123456789012 is the project number.
Each project ID is unique across Google Cloud. After you have created a project, you can delete the project but its ID can never be used again.
When billing is enabled, each project is associated with one billing account. Multiple projects can have their resource usage billed to the same account.
A project serves as a namespace. This means every resource within each project must have a unique name, but you can usually reuse resource names if they are in separate projects. Some resource names must be globally unique.
How to Create & Manage Projects
Google Cloud projects form the basis for creating, enabling and using all Google Cloud services including managing APIs, enabling billing, adding and removing collaborators, and managing permissions for Google Cloud resources.
To create and manage Google Cloud projects using the Resource Manager API and the Google Cloud Console.
The following are used to identify your project:
Project name: A human-readable name for your project.
The project name isn't used by any Google APIs. You can edit the project name at any time during or after project creation. Project names do not need to be unique.
Project ID: A globally unique identifier for your project.
A project ID is a unique string used to differentiate your project from all others in Google Cloud. You can use the Cloud Console to generate a project ID, or you can choose your own. You can only modify the project ID when you're creating the project.
Project ID requirements:
Must be 6 to 30 characters in length.
Can only contain lowercase letters, numbers, and hyphens.
Must start with a letter.
Cannot end with a hyphen.
Cannot be in use or previously used; this includes deleted projects.
Cannot contain restricted strings, such as Google and SSL
Project number: An automatically generated unique identifier for your project.
Don't include sensitive information in your project name, project ID, or other resource names.
Subscribe: www.youtube.com/c/MaverickCloud
Commenti