Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Table of contents
1.
Introduction
2.
Virtual machine instances
2.1.
Instances and projects
2.2.
Instances and storage options
2.3.
Instances and networks
2.4.
Instances and containers
2.5.
Tools to manage instances
2.6.
Managing access to your instances
2.6.1.
Linux Instances
2.6.2.
Windows Server instances
2.7.
Default time zone for VM instances
3.
Instance groups
3.1.
Managed Instance Groups (MIGs)
3.1.1.
Advantages of Managed Instance Groups
3.1.2.
Autohealing
3.1.3.
Health checking
3.1.4.
Regional or zonal groups
3.1.5.
Load balancing
3.1.6.
Autoscaling
3.1.7.
Automatic updating
3.1.8.
Support for stateful workloads
3.1.9.
Groups of preemptible instances
3.1.10.
Containers
3.1.11.
Network and subnet
3.2.
Unmanaged instance groups
4.
Creating and starting a VM instance 
4.1.
Prerequisite
4.2.
Create a VM instance from an image
4.2.1.
View a list of public images
4.2.2.
Creating a VM instance from a public image
4.2.3.
Creating a VM instance from a shared image
4.2.4.
Create a VM from a snapshot
4.2.5.
Creating a VM instance from a container image
4.3.
Creating a VM instance with access to other Google Cloud Services
4.4.
Creating a VM instance in a specific subnet
5.
Frequently Asked Questions
5.1.
What is Docker?
5.2.
What are containers?
5.3.
What is a VPC network?
6.
Conclusion
Last Updated: Mar 27, 2024

Overview of Compute Engine

Author Nagendra
0 upvote
Leveraging ChatGPT - GenAI as a Microsoft Data Expert
Speaker
Prerita Agarwal
Data Specialist @
23 Jul, 2024 @ 01:30 PM

Introduction

Compute Engine provides predefined virtual machine configurations for every need, from modest general-purpose instances to huge memory-optimized instances with up to 11.5 TB of RAM or fast compute-optimized instances with up to 60 vCPUs. Affordable computing instances appropriate for fault-tolerant applications and batch processes.
This blog describes Compute Engine in detail, as well as Virtual Machine Instances, Instance Groups, and the specific processes required to create and start a VM instance in the gCloud.

Without further ado, let's get started.

Virtual machine instances

Google's public Linux and Windows Server images, as well as privately created custom images that you can import from your current systems, can both be operated on Compute Engine instances. Instances running the Container-Optimized OS public image immediately launch Docker containers, which you can also deploy.
You have the option of using a preset set of machine types or designing your own custom machine types to control the machine parameters of your instances, such as the number of virtual CPUs and the quantity of memory.

Instances and projects

A project on the Google Cloud interface owns each instance, and a project may have one or more instances. The zone, operating system, and machine type of an instance are all specified when it is created in a project. An instance is eliminated from the project when it is deleted.

Instances and storage options

Each Compute Engine instance is preloaded with the operating system on a little boot persistent drive. You can upgrade your instance's storage settings if the apps that are executing on it need more room.

Instances and networks

A Compute Engine instance's network interfaces are each connected to a specific VPC network subnet. 

Instances and containers

A declarative technique for launching your apps utilising containers is supported by Compute Engine instances. You can specify a Docker image name and launch configuration when building a virtual machine (VM) or instance template. The rest will be handled by Compute Engine, including launching your container when the VM starts up and providing an updated Container-Optimized OS image with Docker installed.

Tools to manage instances

You can use a number of tools, including the REST API, the Google Cloud dashboard, and the gcloud command-line tool, to build and manage instances. Connect to your instances using Secure Shell (SSH) for Linux or Remote Desktop Protocol (RDP) for Windows Server to configure programs on the instance.

Managing access to your instances

One or more of the following approaches can be used to manage access to your instances:

Linux Instances

  • Managing Instance Access for Linux Instances Using OS Login, you may manage admin or non-admin access to the instance through IAM roles and link SSH keys to your Google Account or Google Workspace account. Compute Engine can generate SSH keys for you and apply them to your Google Account or Google Workspace account if you login to your instances using the Google Cloud CLI or SSH via the interface.
     
  • Instances without OS Login that have metadata access can have admin access if your SSH keys are managed in the project or instance metadata. Compute Engine can generate and apply SSH keys for you automatically if you connect to your instances via the Google Cloud CLI or SSH via the interface.
     

Windows Server instances

  • For a Windows Server instance, create a password.

Default time zone for VM instances

No matter what region you build your virtual machine instance in, it will always start at Coordinated Universal Time (UTC).

Lets dive into the details of instance groups.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job
Bootcamp

Instance groups

A collection of virtual machine (VM) instances that you may control as a single unit is known as an instance group.

Both controlled and unmanaged VM instance groups are available with Compute Engine:

  • You can run apps on numerous identical VMs with the help of Managed Instance Groups (MIGs). By utilising automated MIG features like autoscaling, auto-healing, regional (multiple zones) deployment, and automatic upgrading, you can make your workloads extremely available and scalable.
     
  • You may load balance among a fleet of VMs that you control yourself using Unmanaged Instance Groups.
     

Let's look at the details of Managed Instance Groups.

Managed Instance Groups (MIGs)

For situations like these, employ a managed instance group (MIG):

  • Stateless serving tasks, such as the front end of a website
     
  • Stateless batch, high-performance, or high-throughput computing applications, including processing images from a queue
     
  • Stateful programs, including databases, old programs, and lengthy batch calculations with checkpointing
     

Each managed instance of the MIG is maintained by Compute Engine according to the configuration you specify in an instance template and optional stateful configuration.

Let's look at the advantages of Managed Instance Groups.

Advantages of Managed Instance Groups

The following are the benefits of MIGs:

  • High accessibility
     
  • Maintaining running VM instances 
    The MIG automatically creates that VM in accordance with the specifications of the original instance (same VM name, same template) in order for the VM to resume its work if a VM in the group stops, crashes, or is deleted by a procedure other than an instance group management command (for example, an intentional scale in).
     
  • Application based Autohealing 
    Additionally, you may configure an application-based health check to check on a regular basis whether your application reacts as expected on each MIG instance. The auto healer will automatically generate a new virtual machine for you if an application on it is not responding. It is more accurate to check that an application replies rather than just making sure a VM is functioning.
     
  • Coverage over different regions (zones) 
    You can distribute the app load over several zones using regional MIGs. This replication offers zonal failure protection. In the event that does occur, your app can carry on serving traffic from instances operating in the remaining zones that are still available in the same area.
     
  • Balanced load 
    To evenly distribute traffic among all of the instances in the group, MIGs use load balancing services.
     
  • Scalability 
    Autoscaled MIGs can automatically increase the number of instances in the group to meet demand when your apps need more computational power. Autoscaled MIGs can automatically decrease if demand declines, lowering your expenses.
     
  • Automatic Updates 
    The MIG automatic updater provides a broad range of rollout scenarios, like rolling updates and canary updates, and enables you to securely deliver new software versions to instances in your MIG. You have control over the deployment's pace, scope, and degree of service disruption.
     
  • Assistance with stateful workloads 
    MIGs can be used to create highly available deployments and automate the use of stateful applications, such as databases, DNS servers, legacy monolithic programs, or lengthy batch computations with checkpointing. On machine restart, recreation, auto-healing, and update events, stateful MIGs maintain each instance's distinct state (instance name, associated persistent discs, and metadata).
     

Autohealing

Managed instance groups actively keep your instances available, which implies that they are in the RUNNING state to maintain the high availability of your applications. A MIG automatically recreates a non-RUNNING instance. But relying solely on the VM state might not be enough. When an application freezes, crashes or runs out of memory, you might want to recreate instances.

Health checking

There are some changes in behavior between the health tests used for load balancing and those used to monitor MIGs. Instead of forcing Compute Engine to recreate instances, load balancing health checks assist in directing traffic away from unresponsive instances and toward healthy instances. A managed instance group health check, on the other hand, alerts you to destroy unhealthy instances and establish new ones.

You can use distinct load balancing and autohealing health checks for the majority of cases. Because these health checks decide whether an instance receives user traffic, load balancing health checks can and should be conducted more frequently. Customers may depend on your services. Thus you need to immediately identify non-responsive instances so you may reroute traffic if necessary. The health check for autohealing, however, leads MIGs to proactively replace failing instances. Therefore it must be more conservative than a health check for load balancing.

Regional or zonal groups

MIGs can be created in one of two ways:

  • An instance deployment method is known as a zonal MIG.
     
  • A regional MIG that distributes instances among various zones within the same region.
     

All of the benefits of MIGs are available in both types. Regional MIGs offer increased capacity, with a maximum of 2,000 instances per regional group, and higher availability by distributing application load over various zones, protecting your workload from zonal failure.

Load balancing

Instance groups can be used by Google Cloud load balancing to serving traffic. You can add instance groups to a targeted pool or a backend service, depending on the kind of load balancer you pick.

Autoscaling

With the use of MIGs, autoscaling may be implemented, which dynamically adds or subtracts VM instances from the group in response to changes in load. To indicate how you wish to scale the group, you can configure an autoscaling policy. You can provide one or more signals in your autoscaling policy to scale the group based on CPU usage, load balancing capacity, Cloud Monitoring metrics, schedules, or, for zonal MIGs, by employing a workload that uses queues such as Pub/Sub.

Automatic updating

New software versions can be deployed to instances in a MIG quickly and safely. You can manage the speed and scope of the update rollout to reduce interruptions to your application. An update is automatically rolled out based on your specifications. Partial rollouts are an optional option that enables canary testing.

Support for stateful workloads

Stateful managed instance groups can be used to provide highly available deployments of stateful workloads on virtual machines (stateful MIGs). Systems containing stateful data or configuration, such as databases, old monolithic applications, and lengthy batch computations with checkpointing, are examples of stateful workloads.
Autohealing, controlled updates, and multi-zone deployments can increase the uptime and resilience of such applications while keeping the distinctive state of each instance, including the instance name's customizability, persistent discs, and metadata.

Groups of preemptible instances

You can lower the cost of your workload by employing preemptible VM instances in your instance group for workloads where minimal expenses are more essential than the speed of execution. Preemptible instances terminate gracefully after up to 24 hours, giving your application 30 seconds to quit properly. Preemptible instances can be destroyed at any time, but when preemptible capacity re-emerges, autohealing will restore the instances.

Containers

Using containers to deploy applications to instances in managed instance groups can make the process simpler. Each virtual machine in a managed instance group is generated with a container-optimized OS that supports Docker, and the container starts automatically on each VM in the group when you specify a container image in an instance template and use that template to build a managed instance group.

Network and subnet

You must make use of an existing instance template when creating a managed instance group. The VPC network and the subnet that member instances use are specified by the instance template. You can omit the subnet for auto-mode VPC networks, which tells Google Cloud to use the subnet that was generated automatically in the region supplied in the template. Google Cloud tries to utilise the default VPC network if you omit a VPC network.

Let's look at the details of Unmanaged Instance Groups

Unmanaged instance groups

Unmanaged instance groups may contain a variety of instances that you can add or remove at your discretion. Unmanaged instance groups are not a viable choice for delivering highly available and scalable workloads because they do not allow autoscaling, autohealing, rolling updates, multi-zone support, or the use of instance templates. If required to manage the instances yourself or apply load balancing to groups of heterogeneous instances, use unmanaged instance groups.

Let's look at the details of creating and starting a VM instance.

Creating and starting a VM instance 

You can build one or more discs for your virtual machine as you create it. After creating the VM, you can also add extra drives to it. Following creation, Compute Engine launches the VM instance automatically.

Let's first look at its prerequisites.

Prerequisite

Follow these steps to use the command-line examples in this guide:

  • Install the most recent version of the Google Cloud CLI or update it.
     
  • Decide on a default zone and area.
     
  • Set up API access if you wish to use the examples of the API in this guide.
     
  • There is a cap of 20 VM instances per second when building VMs from images or discs using the Google Cloud CLI or the Compute Engine API. Request a larger quota limit for the Images resource if you need to build more VMs per second.
     

Let's look at the details of creating a VM instance from an image.

Create a VM instance from an image

This section shows how to make a virtual machine (VM) using either a pre-made or a custom OS image. An OS image, a boot file system, and a bootloader are all components of a virtual machine (VM).

View a list of public images

Examine the list of public images that are accessible on Compute Engine before you create a VM using one.

  • Navigate to the Images page in the Google Cloud console.
     

Let's look at the details of creating a VM instance from a public image.

Creating a VM instance from a public image

Public OS images are provided and maintained by Google, open source communities, and independent vendors. All Google Cloud projects can, by default, create virtual machines using open-source OS images. However, you may only utilise the pictures on that list to create a VM if the Cloud project has a defined list of trusted images.
You cannot use integrity monitoring or the virtual platform trusted module to shield data while creating a shielded VM image with a local SSD (vTPM).

Follow the following steps to create a VM instance from a public image:
 

  • Navigate to the VM instances page in the Google Cloud console.
     
  • Click Choose Project, then Continue.
     
  • Click Create Instance.
     
  • Give your virtual machine a name. 
     
  • Change this VM's zone if you want to. To promote usage across many zones, Compute Engine randomly distributes the list of zones within each region.
     
  • For your VM, choose a machine configuration.
     
  • Click Change in the Boot disc area, then carry out the following steps:
    • Select the following options under the Public pictures tab:
      • Operating system
         
      • OS version
         
      • Boot disk type
         
      • Boot disk size
         
    • Optional: Click Show advanced configuration to access advanced configuration options.
       
    • Click Select to confirm your boot disc selections.
       
  • To allow HTTP or HTTPS access to the VM, choose Allow HTTP traffic or Allow HTTPS traffic in the Firewall section. When you choose one of these, Compute Engine creates a network tag for your virtual machine that links the firewall rule to the virtual machine. After that, Compute Engine builds the relevant ingress firewall rule, which permits all incoming traffic on TCP port 80 (HTTP) or TCP port 443. (HTTPS).
     
  • Optional: You can change the Shielded VM settings if the OS image you choose supports those capabilities. Expand the Security section under Networking, Disks, Security, Management, Sole Tenancy to see the settings for shielded VMs. Then, as necessary, make the following changes:
    • Choose Turn on Secure Boot to activate Secure Boot. By default, Secure Boot is turned off.
       
    • Clear the Turn on vTPM checkbox to disable vTPM. vTPM is by default turned on. Because integrity monitoring depends on the information provided by Measured Boot, disabling vTPM also renders integrity monitoring inoperable.
       
    • Clear the Turn on Integrity Monitoring checkbox to turn off integrity monitoring. Integrity monitoring is by default turned on.
       
  • Click Create to start the VM and create it.
     

Let's look at the details of creating a VM instance from a shared image.

Creating a VM instance from a shared image

Follow the following steps to create a VM instance from a shared image:

  • Go to the Create an instance page in the Google Cloud dashboard.
     
  • Give your virtual machine a name. 
     
  • Change this VM's zone if you want to. To promote usage across many zones, Compute Engine randomly distributes the list of zones within each region.
     
  • For your VM, choose a machine configuration.
     
  • Click Change to configure your boot disc, then complete the following steps:
    • The Custom Images tab should be chosen.
       
    • Click Select a project to choose the image project, then take the following actions:
      • Pick the project that has the image in it.
         
      • Click Open.
         
    • Select the image you wish to import by clicking it in the Image list.
       
    • Choose the boot disk's type and size.
       
    • Select to confirm your boot disc choices.
       
  • In the Firewall section, choose Allow HTTP traffic or Allow HTTPS traffic to allow HTTP or HTTPS traffic to the VM.
    The console establishes an ingress firewall rule and adds a network tag to your virtual machine, allowing all incoming traffic on port 80 (HTTP) or port 443. (HTTPS). The firewall rule is linked to the virtual machine through the network tag. 
  • Click Create to start and launch a VM.

Let's look at the details of creating a VM from a snapshot.

Create a VM from a snapshot

There are several ways to build a new virtual machine from a snapshot:

  • Restoring a virtual machine's boot drive 
    If you used a snapshot to back up a VM's boot disc, you can utilise that snapshot to create a new VM. See Restoring a boot disc snapshot to a fresh VM for instructions.
     
  • Restoring a non-boot drive 
    If you used a snapshot to back up a non-boot disc, you can use the VM creation process to restore the snapshot to a fresh non-boot disc. See Creating a VM with a non-boot disc based on a snapshot for instructions.
     

Instead of utilising a snapshot, generate a custom image, then create VMs from that image to easily create several virtual machines with the same boot disc.

Let's look at the details of creating a VM instance from a container image.

Creating a VM instance from a container image

When you create a Compute Engine VM, you should include a container image name and any optional configuration options. The most recent release of the Container-optimized OS public image, which includes Docker installed, is used by Compute Engine to generate the VM. When the VM starts, the Compute Engine then starts the container. See Deploying containers on VMs for further details.

Follow the following steps to create a VM instance from a container image:

  • Navigate to the VM instances page in the Google Cloud console.
     
  • Click Choose Project, then Continue.
     
  • Click Create instance.
     
  • Give your virtual machine a name.
     
  • Click Deploy container under the Container section.
    • Choose the image to use for the Container. For instance:
      • NGINX 1.12 container image can be chosen via Cloud Launcher by choosing:
        Command:
gcr.io/cloud-marketplace/google/nginx1:1.12
  • Always use the complete Docker image name when deploying an Apache container image from Docker Hub:

Command:

docker.io/httpd:2.4
  • Click the Advanced container options link if desired. See Configuring options to operate your container for further details.
     
  • Click Create to create the VM, start it up, and start the container.
     

Let's look at the details of creating a VM instance with access to other Google Cloud Services.

Creating a VM instance with access to other Google Cloud Services

 If you intend to run an application on your VM that requires access to other Google Cloud services, you have to create a service account before creating the VM, and then configure the VM in order to run as a service account. To access other Google Cloud services, you can utilise the credentials for a service account in your application code.

Let's look at the details of creating a VM instance in a specific subnet.

Creating a VM instance in a specific subnet

For each project, Google Cloud automatically establishes a default VPC network in auto mode. You must specify the subnet when creating the VM if you want to use a different network or a subnet that you manually configured in an auto mode or custom mode VPC network.

Consider these guidelines before building a virtual machine in a subnet:
 

  • If a network or subnet is not specified, Compute Engine uses the auto subnet in the same region as the VM and the default VPC network.
     
  • Compute Engine infers the network from the specified subnet if you don't specify a network.
     
  • A subnet must be specified along with a network if you want it to be part of the same network. Otherwise, the VM cannot be created.
     

Follow the following steps to create a VM instance in a specific subnet:

  • Navigate to the VM instances page in the Google Cloud console.
     
  • Click Choose Project, then Continue.
     
  • Click Create instance.
     
  • Give your virtual machine a name.
     
  • Change this VM's zone if you want to. To promote usage across many zones, Compute Engine randomly distributes the list of zones within each region.
     
  • Select Allow HTTPS traffic or Allow HTTP traffic in the Firewall section to allow HTTP or HTTPS traffic to the VM.
    The console produces an ingress firewall rule that permits all incoming traffic on tcp:80 (HTTP) or tcp:443 and adds a network tag to your virtual machine (HTTPS). The firewall rule is connected to the VM using the network tag.
     
  • Extend the sole tenancy, networking, discs, security, and management sections.
    • Expand the section on networking.
       
    • Give the network information for network interfaces:
      • Choose the VPC network that hosts the subnet you created in the Network field.
         
      • Choose the subnet that the VM will utilise from the Subnet field.
         
      • Select "Done"
         
  • Click create to create the VM and start it.
     

Frequently Asked Questions

What is Docker?

A software platform called Docker makes it simple to create, test, and deploy apps. Docker packages software into standardised units called containers that contain all of the components necessary for the software to function, such as libraries, system tools, code, and runtime.

What are containers?

Containers are software packages that come with everything needed to execute in any environment. Containers virtualize the operating system in this manner, enabling them to run anywhere, including on a developer's own laptop as well as on a public cloud or a private data centre.

What is a VPC network?

A VPC (Virtual Private Cloud) network is a worldwide resource made up of a collection of regional virtual subnetworks (subnets) in data centres that are all connected by a wide-area global network. In Google Cloud, VPC networks are logically separated from one another.

Conclusion

In this article, we have extensively discussed the details of Compute Engine along with the details of Virtual Machine Instances, Instance groups, and detailed steps of creating and starting a VM instance in gcloud.

We hope that this blog has helped you enhance your knowledge regarding Compute Engine, and if you would like to learn more, check out our articles on Google Cloud Certification. You can refer to our guided paths on the Coding Ninjas Studio platform to learn more about DSADBMSCompetitive ProgrammingPythonJavaJavaScript, etc. To practice and improve yourself in the interview, you can also check out Top 100 SQL problemsInterview experienceCoding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!!

Live masterclass