5. Step 05 – Scenarios – Instance Groups
Welcome back. In this step, let’s look at a few scenarios regarding instance groups. We played a lot with instance groups in the previous steps. Let’s look at a few example scenarios. You want MiG-managed applications to survive zone failures. So even if a single zone completely fails, you’d want the MiG to survive that. How can you do that? The way you can do that is by creating multizone MiGs, which are also called regional MiGs. Once you create a regional MIGS with multiple instances, your instances will be distributed across multiple zones in that specific region, and therefore you will be able to survive zoning failures. You want to create VMs with different configurations in the same group. How can you do that? Can I use a managed instance group (MIG)? The answer is no. You have to go for an unmanaged instance group. If you want to create VMs with different configurations, then you create an unmanaged instance group.
So in instance groups, you can go and create your instance group. And over here, you can see that by default, you are creating a new managed instance group that is stateless. However, you can also create a new unmanaged instance group. That’s the third option that is present here. These are a group of VMs that you manage yourself. Over here, you can go in and attach any VM instances that you want. You can go and create VM instances with any configuration. You can create 510 different configurations, and you can go in here and pick up the VM instances that you’d want to be able to add to the specific unmanaged instance group. You want to preserve VM state in a managed instance group. How can you preserve the VM state? The option is to go for a stateful MiG. You can go for a state-managed information group. This would preserve the VM state. This would preserve the instance name attached, persistent disks, and the metadata.
Whenever you have stateful workloads, like a database or a data processing app, you can go for a stateful managed information group. Where can you create a managed-instance group that is stateful? This is the place to set up a new managed instance group for stateful workloads like databases. You want high availability in a managed instance group even when there are hardware and software updates. There may be software or hardware updates that you want to apply to the instances. How can the virtual machines in a managed instance group be updated while maintaining high availability? The option is to configure the availability policy with the right values. So when we are creating the instance template for our managed information group, you need to ensure that availability is configured with the right values. For the availability policy, you need to ensure that automatic restart is enabled and that host maintenance is migrated.
Let’s quickly see how they can be configured. Let’s go back to our template, so virtual machines Instance Templates: This is where we actually create an instance template. The instance template is what is used to create your managed information group. Create an instance template; where can we configure the availability policy? You need to go to management. Security disks, networking, and soul tenancy And inside management is where you’d be able to configure the availability policy. On-host maintenance takes place here. When Compute Engine performs periodic infrastructure maintenance, it can migrate your VM instances to other hardware without downtime. This is also called “live migration.” The recommended option is to enable the migration of a VM instance. The other option available here is Automatic Restart. Compute Engine can automatically restart VM instances if they are terminated for non-user-initiated reasons like maintenance events, hardware failures, or software failures. In those kinds of situations, if you want the VM to be automatically restarted, you need to turn it on. If you want high availability, you’d want to actually set Host Maintenance to migrate VM instances and automatically restart them; unhealthy instances should be automatically replaced. How can you do that? It’s easy, right?
In a managed instance group, all that you need to do is configure a health check. Once you configure a health check, the managed instance group will use it to monitor the status of your VMs. If the health check fails, self-failing will kick in and the instance will be replaced with another instance. The next scenario is that you would want to avoid frequent scaling up and scaling down. How can you do that? There are a couple of options that you can make use of. The first is the cool-down period, and the second is the initial delay. Where can you configure them? When we are creating an instance group, you can actually configure a cooldown period in here, so it specifies how long it takes for your app to initialise from boottime until it is ready to serve.
And the cooldown period allows the autoscaler to make better scaling decisions. For example, high CPU utilisation during instancestack will be omitted during the initialization period. You can also see that predictive autoscaling also uses the cooldown period to start instances ahead of the anticipated load. That’s one, and the other one is the initial delay. You can configure an initial delay, specifying the time to allow an instance to boot and applications to fully start before doing the first health check. Before doing the first health check, you want to wait for a little bit of time. What is the time that you would want to wait for? That is what the initial delay refers to. So if I specify 30 seconds, for example, this would ensure that the application would be given a sufficient amount of time to start up, and then you can do the health check. Otherwise, if I don’t give it an initial delay, and if the initial delay is zero, for example, what would happen? The health check would be done immediately, and it is possible that the instance would be marked as unhealthy and be replaced. And this would result in scaling up and scaling down operations. In this app, we looked at some of the important scenarios related to instant groups.
6. Step 06 – Using Gcloud to play with Managed Instance Groups (MIG)
Welcome back in a step, let’s start playingwith managed instance groups from the command line.We have been using the cloud console until now. Let’s try playing with managed instance groups from the command line as well. The way you can access managed instance groups from the command line is through the cloud compute instance groups managed So keep in mind that this is a component of the Compute service.
That’s why it’s gCloud Compute, followed by instance groups, followed by managed. Let’s try and see what managed instance groups I have running right now. So I’ll paste that in Managed gCloud Compute Instances, and I’d like to paste it in List. So gcloud compute instance groups managed by a list would list the number of instances, wouldn’t it? There would be an error number one; it’s asking for authorization. Let’s go and give it authorization. I’ve just opened up Cloud Shell, so it’s asking for authorization. Let’s authorise it, and even after that, you would get an error because I have not set the current project. So before we would be able to execute any GCloud command, you need to set gcloud config set project, and I would want to set the project ID. Let’s get the project ID and paste it in here. Let’s do that. So we are updating the core project, so let’s go.
Finally, run gcloud compute instance groups managed list. You should see one managed instance group come up in my managed instance group, and you’d see that there is a base instance name and that there is an instance template that we are making use of, and you could see that we are having auto scaling. You’ll also see what your target size is, how many instances you want, and what the current size and status are. Important thing to remember is instant groups spaceManaged and it falls under the Compute.As a result, gcloud computes instant groups. Now that everything is managed, you can use the create command to create a new managed instance group. So you could say you want to manage and create gCloud compute instance groups.
So instead of listing, what we are doing in here is creating, and you can give it a name and specify which zone you’d want to create the managed instance group on. If you want to create a regionally managed instance group, you can specify the region as well. You can also specify the template you’d want to create the instance group with over here. This is a template that you would want to use. In addition to that, you can also configure the size of the instance group. I would want to create an instance group with a specific size. Let’s try executing this command right now. So I’ll copy this in here, paste it in here, and change a few things.
So the template that we have here is what I’d like to use. My instance template does not really exist. So what we want to do is use this “My Instance” template with a custom image. If you have difficulty typing this, Oops, I have a problem. If you have difficulty editing in here, you can actually also use a text pad. So go into textpad, edit the command there, and then come in here and paste it in. So it’s My Instance Template with Custom Image; that’s the big name that we have for the template. So my template with the custom image and this one I’ll keep the same, and I’ll call it My MiG. So I think the rest of this stuff looks good. So let’s press Enter right now, keep our fingers crossed, and hope it will be successfully created. It’s taking a little while for the command to execute. Let’s wait for it to come back with a result. Okay, success. So we are able to easily create a managed instance group with this specific command. You can see that the name is MiG.
We are creating it in US Central Area A, and we are creating a zonal over here; you can see that the earlier one that we created is regional. However, the current one that we have created because we specified just the zone is a zonal one, and you can see the name. The base instance name is My MiG, and you can see that the current size is zero. You had zero instances running at the time of the creation of this managed instance group. However, the target is one, and the instancetemplate details can also be seen here. And you can see that we have not setup any auto scaling for it either. So if I go ahead and now execute the earlier command gcloud compute, instance groups, managedList, you’d be able to see all the instance groups that are present right now. How many should you see? You should see two, right? I have the earlier one, My Managed Instance Group, and the new one, which is My MiG. and you can see all the details around them.
And you can see that right now there is one instance ready for even the new instance group that we have created, the My MiG. That’s cool. Now, when you are creating an instance group, there are a few options that you can configure. You can also configure a health check. So you can say “health check” is equal to the URL you’d want to configure the health check with. So, how do you know if an instance is healthy? You can also configure an initial delay. How much time should you give the instance to start before the health check is done? Now, similar to the Create command, we also have the commands gcloud compute, instantgroups, managed, delete, describe, and list. We already executed the list command. You can also delete. So you can say gcloud compute, instance groups managed, delete, and give the name of the instance group, and then that specific instance group will be deleted. Describe would give the details of that specific managed instance group. One of the interesting things that you would have seen earlier is the fact that we did not have autoscaling set up for this specific managed instance group. How can you set up autoscaling? The command set autoscaling can be used to enable autoscaling. Give it a name, and you can set the auto-scaling configuration. Setting the maximum number of replicas is required. And there are other options that you can configure as well. You can configure a cool-down period.
How much time should an autoscaler wait after initiating an autoscaling action? I’ve just executed an auto-scaling action. How long should I wait before looking at the autoscaling metrics again? That’s the cool-down period, the default of which is 60 seconds. The other thing that you can configure with auto scaling is: how do you want to do auto scaling? What metric should we consider? Do you want to go with CPU? So if you want to go based on the CPU, then you can use the option “scale based on the CPU” and configure a target utilisation as well. You can say the target CPU utilisation is equal to 60%. Or I can say I want to scale based on load balancing, and I can configure the target load balancing utilization. You can also configure a minimum number of replicas. How many instances do you want to maintain at a minimum? And you can also configure the mode.
What is the auto-scaling mode that you would want? Do you want it off? Do you want it on? Or do you want it to only scale out? When you have the mode set to only scale out, it will not reduce the number of instances. It will only increase the number of instances if there is a high load. Now, if I go back to the instance groups and pick up my MiG and say “edit,” these are the same options that you’d be able to see when you go to configure auto scaling. In here. The auto-scaling mode can be set to autoscale, don’t autoscale, or autoscale only for apps. You can configure the auto-scaling policy, what metrics to look at, what is the cool-down period, what is the maximum number of instances, what is the minimum number of instances, and all that stuff. This is exactly how you can configure them from the command line. I don’t want to put ten as the number of instances.
Let’s say the maximum number of replicas. I would want to put it at two. So let’s go back and use the same command. The name of my managed instance group is my MiG. So that looks good, and there are a lot of replicas. I’ll just say it’s two. So what would happen? The pen is enough. On the other hand, auto-scaling is enabled, and it says you didn’t specify a zone; what zone do you want to use? And it’s asking if this is the zone I would want to make use of. Actually, I don’t want to use that zone; instead, I want to use this one’s zone. I’ll go ahead and say control C and command breakout, and let’s go over the managed instance groups again. And what I’d do is, in addition to the earlier options that we gave here, I’d also configure a zone. So Hyphen’s iPhone zone and the zone of my MiG are your central ones. So let’s go ahead and do that. Hopefully, this will go smoothly.
Cool. You can see that now the auto-scaling policy is configured for that specific managed instance group as well. And if I do a “cloud compute instance groups managed list,” what will you see? What do we expect to see? Let’s wait for a few seconds. Yes, the answer comes back, and you can see that the auto-scaling for this is yes. So we now have an auto-scaling policy for my MiG as well. So that’s how you add in an auto-scaling policy. The important thing to remember in here is the fact that the command for creating an instance group is create, and the command for setting an auto-scaling policy is set auto-scaling. So the earlier path exactly remains the same for managing cloud compute instance groups, and that’s the reason why we put it in here. So all the commands that we’ll be talking about now, we’ll start with “gcloud compute instance groups managed.” And we looked at create, the deleted/edited list, and setting auto scaling. You can also stop auto scaling, which is similar to setting auto scaling. So stop auto-scaling, which is exactly the opposite.
So I can easily execute the command, except that I would need to add a zone if an iPhone zone, and the zone on which we have our specific MiG is US Central One A, and it would disable the auto scaling that we have configured. Let’s see what happens. Cool. It says deleted auto-scaling policy, and if I do a compute instance groups managed list, what should I see? What do I expect to see? Yes, you can see that auto scale is not enabled. That’s cool.
Now you might also want to update the managed instance group policies if you want to update the managed instance group policies that are basically the autohealing policies, which are health check and initial delay. These two together are also called auto-healing policies because the health check is used to identify whether an instance is available or not. And if it’s not available, we would want to do autohealing or replace it with a healthy instance. That’s why these are called auto-healing policies. The command is very, very simple. The command is “update my MiG.” and you can specify these options. You can say “initial delay.” I would like to change the initial delay. Or I would want to configure an initial delay. And you can also say “health check.” What is the health check you’d want to configure? We saw that the way we start the command is exactly the same for all the commands in here. G: cloud, compute, instance groups, managed. If you want to create an instance group, create If you want to enable auto scaling. Set auto scaling to on. If you want to update the auto-healing policies, update them. We also saw that there are a few other commands you can delete. a managed instance group. interesting time and
7. Step 07 – Gcloud and MIG – Making Updates
Welcome back. In this step, let’s continue to play with our managed instance groups. From the command line, let’s try and make a few updates to our managed instance groups. The first one we want to try is to resize the group. So I’d want to change the size of an existing group. You can accomplish this by using gcloud compute instance groups manage resize. my MiG I already have a group called My MiG, and you can specify the size. So let’s actually make a list first. So if I do a list, “instancegroups manage list,” what do you see? You should see two instance groups running right now, and you can see that the target size for my MiGis is two. I would want to change that back to one. How can I do that? I can copy this in. And let’s say size is equal to one. Oops.
I need to configure zones. So let’s do that. Zone is equal to whatever zone it’s running in. So enter US Central 1, A, and then press enter. Let’s see what would happen.It’s updated, and it shows the policy well enough. What would I see if I did instance group manage lists? Okay, I can see that the target sizeNAV is 1, so you can resize your managed instance group by using the command Resize. If you want to recreate one or moreinstances, you can use the command Recreate instances.This deletes existing instances and recreates them, and you can also specify which instances you want to replace. Now, let’s say I would want to list all the instances that are present in here so I can say, “Cloud, Compute Instances, List.” What would this give me? This would give me a list of all the instances, or compute instances, that are currently running, as well as their names and IP addresses. It’s taking a little while. I anticipate three plus one running with the first managed group and one running with the second. So my MiG-85FB is the name. So over here, what we are configuring is the name. So instances are equal to that specific instance. So for example, if I would want to actually recreate the instances right now for the existing one, the way I can do that is take the command up to instances, copy that in, and say that instances is equal to this specific instance. I would want to, let’s say, recreate it. That’s what we are doing in here, recreating that, and as usual, let’s specify the zone.
So the zone is the US central one, and you’d see that that specific instance would be recreated, so it says it was a success, and now if I actually do a G Cloud Instances list, what do we expect to see? You would see that that instance will be replaced by a new instance, so let’s say you discover that there is some problem with this specific instance and you want to recreate it. That is one of the scenarios, and you should go ahead and recreate it. As you can see, there are currently only three instances running. Let’s go again and run it through the Cloud Computing Instances list; there should be one more instance that should come up very soon. I’ve been waiting for almost 20 seconds now. Okay, there you go. A new one will be available in 85 FB. You might not want to always delete and recreate instances. Sometimes changes can be made without deleting and recreating the instance.
Maybe you can just restart the instance. In such cases, you can update specific instances, for example, through Cloud, Compute InstanceGroups, managed Update instances, and you can specify which instances you want to update. You can also specify the minimal action that you would like to take. For example, if you have updated the configuration of a managed instance group, you can specify that the minimal action is equal to refreshing or youcan say minimal action is equal to restart.In that kind of situation, your instances will be restarted; they won’t be deleted and recreated, but they will just be restarted. In addition, you can also configure the most disruptive allowed actions, so you can say the default is refreshed.
At the very least, I’d like to do a refresh, but at the very most, I’d like to restart. I don’t want to replace the existing instance. I don’t want to delete and recreate the existing instance. So updating instances gives you more options than recreating instances. When you’re doing a recreate, you can only delete and recreate instances. However, with updated instances, you have other options. If you are making minor changes in the managed instance group, you can simply refresh or restart the instance. Replace is kind of the worst-case scenario.
The next thing you might want to do with your managed instance group is update the instance template. So I don’t want to update to a new template, so I can say gcloud compute instance groups, managed set instance template for the specific managed group, and specify the template. I can set up an instance template. In the previous step, we looked at some of the important commands to help you make updates to an existing managed instance group. We saw instances resize, recreated, updated, and the instance template set. As far as the exam goes, it’s very important that you focus on the ones in bold. So remember to resize, recreate instances, update instances, and set the instance template. I’m sure you’re having a wonderful time, and I’ll see you in the next.
8. Step 08 – Gcloud and MIG – Managing Template Updates
There is another set of commands that you can use, which is called “Rolling Action Start Update.” When you recreate instances, you must do everything by hand. However, you can also automate the upgrade to the new version template in a more controlled fashion. That is where we will be talking about the rolling action start update command. So what are these rolling actions that are allowed? So the scenario is that you want to manage your release from V1 to V2 in a controlled way with as little downtime as possible or without any downtime at all. So the command is “g cloud compute instance groups managed.” The important thing to remember is rolling action so that the tolling action can be restarted. So you can say “gcloud compute instance groups-managed rolling action restart my MiG,” and you can configure a lot of things around this. You can set the maximum surge to 5, or you can specify 10% in percentage. What we are specifying here is the maximum number of instances updated at a time. So if you have 100 instances that are part of the managed instance group, you don’t want to upgrade all of them at the same time; you want to upgrade them in a controlled fashion.
So if you specify that the maximum surge is equal to five, then at a particular point in time five instances would be restarted, and once those were restarted, you would start with the next group. You can also replace the intra-free start with another option. You can actually say replace when you are doing a restart; it would just do a stop and start. However, when you are doing a replace, it will delete the existing instance and create it with the new template. Over here, it’s been restarted, and over here, it’s the replacement. You can see that it’s in bold. When you are doing replace, you can configure maximum search, and in addition, you can also configure a few more options. Maximum Unavailable can also be set. How many instances can be down for the update?
And you can also configure a replacement method, whether you want to recreate or substitute. When you do a recreate, the instances are created with new names. The names of the instances will also change. However, if you do substitute the substitute, it reuses the existing name for the instances. So that’s one way of updating to a new template. Update the template on the major instance group, and then you can do a replay or restart to roll out the new template. The other option is to directly update the instances to a new template. In this specific option, you can actually directly configure “rolling action start update.” So the command is “Rolling Action, Start Update,” and you can specify the version you’d like to upgrade to.
So the Hyphen FN version is equivalent to the V One template. There is also an advanced version, which is called the Canary version. In this specific version, you can actually update a set of instances to the new template. In addition to the version, you can configure a Canary version, as well as specify the Canary template and target size. So what would happen when you did a canary version? The V2 template would be applied to 10% of the instances. You can test those 10% of the instances, and once you are happy, then you can upgrade all the instances to the V-2 template. You can also control how the rollout happens with the Rolling Action Startup Date. Even with a rolling action startup date, you can use Mac Surge Max’s unavailable and replacement methods. In this step, we looked at how you can actually roll out a new template to an existing managed instance group. One option is to update the instance group with the template and slowly use the rolling action restart and rolling action replays. The other option is to also directly call “Rolling Action Start Update” with the template. There is also a canary version where you can specify a canary version with a specific target size. I’m sure you’re having an interesting time, and I’ll see you in the next.
