Identity and API access This article extends my notes from Coursera course Google Cloud Fundamentals: Core Infrastructure | Coursera.
Compute Engine
- example of IaaS
- like AWS EC2
- with it, users can create and run virtual machines on Google infrastructure
- no upfront investments
- thousands of virtual CPUs can run on a system that’s designed to be fast and to offer consistent performance
Each virtual machine contains the power and functionality of a full-fledged operating system. This means a virtual machine can be configured much like a physical server, by specifying required:
- amount of CPU power (virtual CPUs)
- memory
- amount and type of storage
- operating system
- predefined
- custom, created by us
- We pay for what we need with custom machine types.
- We can in fact configure very large VMs, which are great for workloads such as in-memory databases and CPU-intensive analytics
- most Google Cloud customers start off with scaling out (autoscaling - see below), not up
- The maximum number of CPUs per VM is tied to its machine family and is also constrained by the quota available to the user, which is zone-dependent (see cloud.google.com/compute/docs/machine-types)
A virtual machine instance can be created via:
- Google Cloud console, which is a web-based tool to manage Google Cloud projects and resources
- Google Cloud CLI
- Compute Engine API
The instance can run:
- Linux and Windows Server images provided by Google or any customized versions of these images
- images of other operating systems that we build
Cloud Marketplace
- Offers software packages e.g. Bitnami LAMP stack (Bitnami package for LAMP – Marketplace – Google Cloud console)
- A quick way to get started with Google Cloud
- Offers solutions from both Google and third-party vendors
- With these solutions, there’s no need to manually configure the software, virtual machine instances, storage, or network settings, although many of them can be modified before launch if that’s required
- Most software packages are available at no additional charge beyond the normal usage fees for Google Cloud resources
Compute Engine’s pricing and billing structure:
- use of virtual machines is billed by the second with a one-minute minimum
- sustained-use discounts start to apply automatically to virtual machines the longer they run
- for each VM that runs for more than 25% of a month, Compute Engine automatically applies a discount for every additional minute
- also offers committed-use discounts: for stable and predictable workloads, a specific amount of vCPUs and memory can be purchased with a discount in return for committing to a usage term of one year or three years.
- if we have a workload that doesn’t require a human to sit and wait for it to finish–such as a batch job analyzing a large dataset we can save money, in some cases up to 90%, by choosing Preemptible or Spot VMs to run the job.
- Preemptible or Spot VM is different from an ordinary Compute Engine VM in only one respect: Compute Engine has permission to terminate a job if its resources are needed elsewhere. Although savings are possible with preemptible or spot VMs, we'll need to ensure that our job can be stopped and restarted.
- Spot VMs differ from Preemptible VMs by offering more features
- preemptible VMs can only run for up to 24 hours at a time
- Spot VMs do not have a maximum runtime
Storage
- high throughput between processing and persistent disks is default
Autoscaling
- Compute Engine feature
- VMs can be added to or subtracted from an application based on load metrics
Load Balancing
- balancing the incoming traffic among the VM
- Google’s Virtual Private Cloud (VPC) supports several different kinds of load balancing
Provisioning
When we create a new Compute Engine VM Instance we can specify:
- Name
- Region
- Zone
- Machine type e.g. Series E2, N2 etc...
- Boot disk image e.g. Debian GNU/Linux 11 (bullseye)
- boot disk's architecture (x86/64 or ARM) must be compatible with the selected machine type
- Identity and API access
- Service Account: e.g. Compute Engine default service account
- Requires the Service Account User role (roles/iam.serviceAccountUser) to be set for users who want to access VMs with this service account.
- Applications running on the VM use the service account to call Google Cloud APIs. Use Permissions on the console menu to create a service account or use the default service account if available.
- Access scopes: Select the type and level of API access to grant the VM. Default: read-only access to Storage and Service Management, write access to Stackdriver Logging and Monitoring, read/write access to Service Control.
- Default access
- Full access to Google APIs
- Set access for each API
- Firewall. By default all incoming traffic from outside a network is blocked. Select the type of network traffic you want to allow. Add tags and firewall rules to allow specific network traffic from the Internet
- Allow HTTP traffic
- Allow HTTPS traffic
- Allow Load Balancer Health Checks
- Advanced options
- Networking - Hostname and network interfaces
- Disks - Additional disks
- Security - Shielded VM and SSH keys
- Management - Description, deletion protection, reservations, and automation
- Automation >> Startup script - You can choose to specify a startup script that will run when your instance boots up or restarts. Startup scripts can be used to install software and updates, and to ensure that services are running within the virtual machine.
![]() |
click to see the original image |
Once instance is running we're able to see internal (e.g. 10.164.0.2) and external IP (e.g. 34.90.152.162) addresses assigned to it:
References:
Google Cloud Fundamentals: Core Infrastructure | Coursera.
No comments:
Post a Comment