Google Cloud Platform is a set of cloud computing services which are offered by Google and it runs on the same infrastructure that Google uses for its end-user products, such as Google Search, Gmail, Google Drive, and YouTube. Google Cloud has been one of the top cloud providers in the IT industry. The services they offer can be accessed by software developers, as it provides a reliable and highly scalable infrastructure to build, test, and deploy their applications.

In this article we will be hosting a web server in Compute Engine resources with IAP that have private IP addresses and connecting it to the internet using NAT and configure an HTTP load balancer to support inbound connections from the internet to your VMs.

Creating Virtual Private Network (VPC)

You can think of a VPC network the same way you'd think of a physical network, except that it is virtualized within Google Cloud. A VPC network is a global resource that consists of a list of regional virtual subnetworks (subnets) in data centers, all connected by a global wide area network. VPC networks are logically isolated from each other in Google Cloud.

Here first we need to create a VPC and use custom for subnet creation mode (the other creation mode is automatic, when you create an auto mode VPC network, one subnet is created in each Google Cloud region). I have created two subnets in us-central1 region and asia-east1 region with IP address ranges of 10.0.1.0/24 and 10.0.2.0/24 respectively.

Deploy Cloud NAT

Cloud NAT, Google Cloud's managed network address translation service, enables you to provision your application instances without public IP addresses while also allowing them to access the internet—for updates, patching, config management, and more—in a controlled and efficient manner.

Now we will deploy two NAT Gateways by selecting our pre-created vpc network and regions (which is divya-vpc in my case and the two subnet regions, us-central1 and asia-east1) and create cloud routers in the regions.

Setup IAP

IAP TCP forwarding allows you to establish an encrypted tunnel over which you can forward SSH, RDP, and other traffic to VM instances. IAP TCP forwarding also provides you fine-grained control over which users are allowed to establish tunnels and which VM instances users are allowed to connect to.

In order to log in to VM instances, we connect to the instances using tools like SSH or RDP. Here we will not directly connect to the instance but will be using TCP forwarding in IAP (i.e., admin will connect to IAP using SSH and IAP will take the request further to the instances). For connecting the instance using SSH via IAP, we need to make a firewall rule as IAP connections come from a specific set of IP addresses (35.235.240.0/20).

Here, an IAP firewall rule is created with the name ‘divya-iap’ and using pre-created VPC network and source as IP 35.235.240.0/20, we allowed tcp 22 port for SSH connection for linux vm and tcp 3389 port for RDP connection for our windows vm. A target group is also specified here named ‘divya-http’, so we need to now create vm instances with this network tag.

Deploy Compute Instances

In this example, we will be using two compute instances or VMs. For reducing the cost I will be using micro VMs and deploy them on both of our subnets i.e, us-central1 and asia-east1. Also both the instances will have private IP addresses and they will make outbound connections to the internet through NAT.

Once both the Linux and Windows Instances are up and running, we can connect to the instances to configure the web server.

For the Linux instance we will connect to the instance through SSH using IAP. For that rum the following gcloud command:

gcloud compute ssh 
instance_name
 \
    --zone us-central1-a \
    --tunnel-through-iap

In this example we have taken us-central1-a as the zone.

In order to connect to the Windows instance, you need to install IAP Desktop if you are a Windows user or Microsoft Remote Desktop if you are a Mac user. Generate credentials (username and password) for Windows Server VM by using the Google Cloud console or the Google Cloud CLI. Use the gcloud compute start-iap-tunnel command to create an encrypted tunnel to the RDP port of the VM instance.

gcloud compute start-iap-tunnel 
instance_name
 3389 \
    --local-host-port=localhost:
local_port
 \
    --zone=asia-east1-a 

Enter “localhost:<port>” as the hostname in the Microsoft Remote Desktop (Here port is the one on which the tunnel is listening).

Install Web Servers (nginx/apache/IIS) in the both linux and windows vm and deploy Hello World apps into it and verify its working locally either by curl or browser by making local host entry in host file.

Setup UMIG Backend

An instance group is a collection of virtual machine (VM) instances that you can manage as a single entity.

Compute Engine offers two kinds of VM instance groups, managed and unmanaged:

• Managed instance groups (MIGs) let you operate apps on multiple identical VMs. MIG services offer autoscaling, auto-healing, regional (multiple zone) deployment, and automatic updating.
• Unmanaged instance groups (UMIGs) let you load balance across a fleet of VMs that you manage yourself.

We use unmanaged instance groups if we need to apply load balancing to groups of heterogeneous instances. Google Cloud load balancers require instance groups to act as backends for traffic. Here we will be using an unmanaged instance group.

We have created two instances groups, one in us-central1-a location and other in asia-east1-a location and specified the created network and subnetwork and the instances which will be the part of these groups (for example linux vm is in us-central1 subnet so a UMIG is created with us-central1-a location and div-vpc as network and us-central1 as subnet).

Configure HTTPS LoadBalancer

HTTPS load-balanced service enables you to run and scale your services using global anycast IP connection proxying. This feature provides a single public IP address that's terminated on Google's globally distributed edge. Clients can then connect to resources hosted on private IP addresses anywhere in Google Cloud.

The following resources are required for an HTTP(S) Load Balancing deployment:

• For regional external HTTP(S) load balancers only, a proxy-only subnet is used to send connections from the load balancer to the backends.
• An external forwarding rule specifies an external IP address, port, and target HTTP(S) proxy. Clients use the IP address and port to connect to the load balancer.
• A target HTTP(S) proxy receives a request from the client. The HTTP(S) proxy evaluates the request by using the URL map to make traffic routing decisions. The proxy can also authenticate communications by using SSL certificates.
  • For HTTPS load balancing, the target HTTPS proxy uses SSL certificates to prove its identity to clients. A target HTTPS proxy supports up to the documented number of SSL certificates.
• The HTTP(S) proxy uses a URL map to make a routing determination based on HTTP attributes (such as the request path, cookies, or headers). Based on the routing decision, the proxy forwards client requests to specific backend services or backend buckets. The URL map can specify additional actions, such as sending redirects to clients.
• A backend service distributes requests to healthy backends. The global external HTTP(S) load balancers also support backend buckets.
  • One or more backends must be connected to the backend service or backend bucket.
• A health check periodically monitors the readiness of your backends. This reduces the risk that requests might be sent to backends that can't service the request.
• Firewall rules for your backends to accept health check probes. Regional external HTTP(S) load balancers require an additional firewall rule to allow traffic from the proxy-only subnet to reach the backends.

Now we need to procure Google managed SSL certificate, Google-managed SSL certificates are Domain Validation (DV) certificates that Google Cloud obtains and manages for your domains.

The DNS records might be managed at your registrar's site, DNS host, or ISP. Where your DNS records are managed, make sure to add or update the DNS A records (for IPv4) and DNS AAAA records (for IPv6) for your domains and any subdomains.

Make sure that the records point to the IP address that is associated with the load balancer's forwarding rule or rules by using an A/AAAA record. Managed certificates can provision successfully if the following is true:

• Your domain's DNS records use a CNAME record that points to another domain.
• The other domain contains an A or AAAA record that points to your load balancer's IP address.

Setup Cloud CDN

Cloud CDN (Content Delivery Network) uses Google's global edge network to serve content closer to users, which accelerates your websites and applications. Cloud CDN works with the global external HTTP(S) load balancer or the global external HTTP(S) load balancer (classic) to deliver content to your users. The external HTTP(S) load balancer provides the frontend IP addresses and ports that receive requests and the backends that respond to the requests.

Now you can hit the domain name and see the content from both Linux and Windows compute instances.

That's all geeks. Thanks for reading :)