Overview of Compute Engine

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:
    • A 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 DSA, DBMS, Competitive Programming, Python, Java, JavaScript, etc. To practice and improve yourself in the interview, you can also check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!!