Google Professional Data Engineer – VPCs and Interconnecting Networks part 2

3. IP Addresses

We’ll now talk about IP addresses, how they work, and their specific characteristics on the Gcp. IP addresses can be assigned to specific resources such as virtual machines. Every virtual machine has an internal IP address. This is automatically assigned to the VM. You can also specifically pick an internal IP address for your VM, but typically you just take the one that is automatically assigned. Now this internal IP address depends on the subnet to that which that VM belongs and has to be drawn from that subnet’s IP address range. This internal IP address is what other instances on the Vpc can use if they want to communicate with this VM. A VM can also have one or more secondary IP addresses on the Gcp.

You can assign a secondary IP address range to a subnet, and the secondary IP address for a VM is drawn from this secondary IP range. If a VM wants to receive external traffic, it needs to have an external IP address. This has to be explicitly assigned to a VM. The internal IP address that is assigned to a virtual machine when it belongs to a subnet is used typically within a virtual private cloud. Now, it cannot be used across VPCs. That means instances which live on different VPCs cannot use the internal IP address of a VM on another Vpc unless you’ve set up some special configuration. That special configuration can be that those two VPCs are part of a shared Vpc, or they have some kind of VPN connection between them, making them a single network, and so on.

Internal IP addresses can be both static as well as ephemeral. They are typically Fml. Because internal IP addresses are used for internal communication. You typically do not want to assign a fixed static IP address to a particular VM. You are okay with the address changing when the VM is reset or when it reboots, and so on. An important thing to note is that every virtual machine is aware of their internal IP address. Every virtual machine knows the host name that has been assigned to it, and this host name, along with the internal IP address, is available to the network DNS, the domain name service that is associated with that Vpc. Now, not every virtual machine might have an external IP address.

In fact, external IP addresses can be considered a security risk because external IP addresses are used when you want to communicate across VPCs traffic. Going to external IP addresses can cause additional billing charges on the Google Cloud platform. A VM will typically have an external IP address when it wants to receive traffic from the Internet, when it wants to expose its IP address to the external world. External IP addresses can once again be smeral or static. They are smeral if they change when a machine reboots, or they can change at any point in time. There is no guarantee that an IP address will belong to a machine forever. Static IP addresses are those that you reserve and explicitly assign to a VM. VMs do not know what their external IP address is.

So if you log into a VM and you type is config on it, you’ll see that it knows its internal IP address. But the external IP address is available on the web console, but the VM itself is not aware of it. Let’s take a quick look at the differences between internal and external IP addresses. Internal IP addresses can be Fml or static, but are typically Fmril. They either change every 24 hours or when the VM restarts. External IP addresses can also be Fml or static. Often you want your external IP addresses to be static. This is because you want a constant IP address which does not change when your machine reboots to expose to external traffic resources, which are third party resources outside of your internal network will want a constant IP address to which they send their requests.

 Internal IP addresses are allocated from the range of IP addresses that are associated with a subnet to which that resource, that VM instance belongs. External IP addresses have nothing to do with the subnet itself. There is a pool of IP addresses available on the Google Cloud platform. One of these IP addresses simply picked and assigned to your virtual machine. If you want your external IP address to be static, that is not changed when a VM restarts or not change every 24 hours, you have to pick a static IP address. In this case, you explicitly reserve one on the Gcp. There is one important thing to note here though. If you reserve a static IP address and don’t assign it to a VM, it will incur charges from Google. If you assign it to a VM, the static IP address is free.

If you don’t assign it to a VM, it will be charged. This is because people were basically reserving a bunch of static IP addresses and not using it. These charges were introduced in order to disincentivize such behavior. A virtual machine is aware of what internal IP address has been assigned it. It has no knowledge of what external IP address is allocated to it. When you set up a virtual machine instance and you’ve done so already, you’ll associate a name with it. Now this name of the instance becomes part of the host name of that VM. The host name is of the format instance one dot c dot project one two, three dot internal where instance one is the name of your instance and test project one, two, three is the name of your project.

The DNS that is associated with your Vpc which facilitates internal traffic, maps this host name to the internal IP address. The external IP address is for traffic which comes from the internet. So the external IP address is what you’ll expose to DNS servers which live on the Internet within a VPC network. When you set up a host, the host name and the internal IP address will be automatically known to the network’s DNS. So Vpc networks automatically resolve the internal IP addresses to the host name and to the corresponding host. But in the case of an external IP address, you need to specifically publish DNS records which point to that particular instance which has that external IP, just like you would in a regular case.

Now, DNS records can be published using Cloud DNS, which is a fully managed service. We’ll talk about Cloud DNS in a little bit. Let’s also quickly understand the differences between Fml and static IP addresses. Ephemeral IP addresses are only available till the VMs stopped, restarted or terminated. They’ll change every 24 hours. Static IP addresses are permanent. They are associated with your project and you explicitly assign them to a particular VM instance. You have to reserve and block a static IP address. Fml IP addresses are all the same. There is no distinction or you don’t differentiate between regional and global IP addresses when they are internal IP addresses.

In the case of static IP addresses though, they can be either regional static IP addresses or global resources. And there is a difference between the two. When you specify a static IP address as a regional resource, only other resources which live within that particular region, within that particular data center, can use that static IP address. Resources which live in a different region can’t access or use the static IP address. Global IP addresses are available to multiple regions. They are only used for global forwarding rules. When we set up global load balancing, we’ll see load balancing later on in this course, and you’ll see where we use a static global IP.

And we’ve mentioned this earlier, but it’s worth mentioning again that if you have unassigned static IP addresses, they incur a cost on the Google Cloud platform. Once you assign them to a VM, they are free for you to use. The Google Cloud platform also allows you to alias IP ranges. Now, what does this mean and why is this useful? Now, typically, if you have just one service running on your virtual machine, it requires just one IP address. That one IP address will refer to that service. That service may be a website, it can be an app, back end, some API, and so on. Now, if you have a powerful virtual machine, then you might have several different services which run on the same VM.

Now, all these different services may need their own IP address. You don’t want to use the same IP address to refer to all the services. You want each of these services to have their own IP addresses. This you’ll achieve using alias IP ranges. Now, subnets can have a primary as well as a secondary Cider range that is associated with it. So it can have two ranges of IP addresses. IP aliasing on the Google Cloud platform allows you to set up multiple IP addresses which refer to the same VM instance. These IP addresses can point to different services on that VM instance. These IP addresses are typically drawn from the primary or the secondary Cider ranges. Here is a block diagram of a virtual machine.

Within the virtual machine there are a number of containers. You can imagine that each of these containers run a different service. The subnet to which this virtual machine belongs has a primary Cider range as well as a secondary Cider range. And they are, as you can see on screen, there are two IP ranges associated with that subnet. Now, the primary IP of this VM is drawn from the primary Cider range using IP aliasing. You can have the alias IPS for individual containers or individual services which are running on this virtual machine, and you can have them drawn from the secondary Cider range. This ability to set up alias IP ranges on the Gcp allows multiple containers or services which run on the same VM to have their own IP address.

They can be referenced separately using their own IP. The cool thing is that VPCs automatically recognize these alias IP ranges and they automatically set up the routes to access all of these IPS which are aliases for the same VM. The Vpc takes care of all the routing and the traffic management. Containers don’t need to do their own routing. This makes things very simple. Containers can simply focus on the application or the service that they are running. Using these IP aliases also enables us to separate infrastructure from containers so the VM, the actual infrastructure, can have its IP address from the primary range. And all the containers and services which run within that VM can draw their IP addresses from the secondary Cider range of the subnet.

4. Lab: Working with Static IP Addresses

In this demo, we will be creating a few static IP addresses and then assigning them to virtual machine instances. To start off, let us navigate to Vpc networks and external IP addresses to create a static address. We call this Ext Static IP One. We leave this as an iPV four address and created in the US. East region. Once this is complete, we go ahead and create a second address, also in the same region and also using iPV Four. So we can see here that these IP addresses are not in use at all. So let us fix that by going and creating some VM instances. So we navigate to Compute engine and VM instances. We create our first instance.

This will be in the US. East region. And to assign this one of our static IP addresses, we navigate to networking. And over here on the Network Interfaces, we specify the external IP to one of the addresses which we have created previously. We then hit done and create. We wait for this instance to be provisioned, and once it is ready, we see that the external IP we generated has now been assigned to this. We just head back to our external IP addresses page, and when we hit refresh, we see that even over here, the console shows which instance is now currently using this external IP address. Let us now go and create a second instance.

But this time let us not assign a static IP address to it. So this is in the US. East region, and we just hit Create. Once this host is ready, we navigate to our external IP addresses page, and we see that a new Ephemeral address has appeared on this list without a name, and the previously unassigned static IP address still remains unused. Let us now assign that other unused static IP address to our second instance. So we go into the instance and edit it. And in the Network Interfaces section, we change the external IP from Ephemeral to the second static IP. We hit Save and then we wait for our changes to take effect. We wait. We wait.

And yes, soon enough the external IP has been assigned to a second instance. Moving over to our IP addresses page, we hit refresh and we see that Ephemeral address has disappeared and our second static IP has been assigned to a second instance. Let us now create a third instance, which we shall call Instance Three, with all the default settings. Once this has been provisioned, we navigate to our list of external IP addresses and we see that a new Ephemeral address has popped up. We can change this from an Ephemeral address to a static one. By doing this, we will have to provide it a name. And we now have a new static IP address.

So we have seen two different ways of creating a static IP address, one of which was directly creating a static IP address, and the other was creating a static IP address out of an Ephemeral one. Let us now go ahead and delete one of the instances to see what happens to its address. So we have deleted instance one, and once it has been terminated, let us navigate to the external IP addresses page and we see that the static IP previously used by instance one has now been freed up. Since there is a charge to having static IPS which are not assigned to anything, let us just go ahead and release this one. We now navigate to our second instance.

We edit it, and then we change the external IP address for this from a static one to an Ephemeral one. We just hit save, and we wait for our changes to take effect. Once that is done, we can just navigate to our external IP address of page and we see that the static IP address which was previously assigned to that instance has now been freed up and a new Ephemeral address has appeared on the list. So let us just free up this other static IP address to wrap up this lab. Let us just do a quick clean up by terminating the instances, and once that is complete, we just go ahead and release the last static IP address. All right, so that concludes this lab. Bye.