Welcome back. In this lesson, we're going to talk about virtual machine instances. We'll talk about Compute Engine and creating instances and then once we have our instances running, we'll need to connect to them, so we'll talk about that as our closing topic.

Sometimes, we're building something like a web application and using hosted platforms like AppEngine makes a lot of sense. It abstracts away the need to think about individual virtual machines and that can make life easier on developers and operations. However, there are still plenty of applications and workloads that are better suited for running on VM instances. Things such as batch processing jobs as well as lifting and shifting legacy applications to the Cloud. And this is the rule of Compute Engine. And it's one of Google's compute offerings. It allows us to create networks and virtual machines and structure things just the way we need to.

Now, maybe you need something like a fairly simple small Ubuntu VM to run some legacy application or maybe you're working with something larger and more complex like a multi-player video game backend. Either way, Compute Engine has the ability to make all of that happen.

So what does Compute Engine offer in the way of features? It provides pre-configured machine types such as high CPU and high memory as well as standard or shared-core machine types. We'll cover these more in-depth in just a bit. It also provides persistent disks and these can be in the form of standard or SSD and even local SSD. And we can take snapshots of these disks as well and that will allow us to make back-ups or to create a base image.

Compute Engine also provides a metadata server which is really cool. The way it works is that we can get and set metadata related to the project or a running instance. The metadata server also holds things such as the startup and shutdown scripts. So whenever a server starts up, which includes a reboot, the startup script can run and initialize things. It's going to allow us to bootstrap our code or a configuration management client. And besides all of this good stuff, we also get APIs for auto scaling, we get per-minute billing, and custom machine types. And we'll be talking more about this stuff as we progress throughout the course.

Compute Engine is classified as infrastructure as a service, which is ideal for general computing workloads. And that means it takes more effort to create and manage the environments we need. However, it also means we have fewer limitations. You can select the tools and languages that work for you.

Now that we've talked about some of the cool features that Compute Engine offers, let's dive into actually creating instances. I want to make a quick point of clarification between image and instance. An image is basically a snapshot of a disk. And an instance is a copy of an image that contains a boot disk and it's one that can be started and stopped and deleted. It's an actual bootable VM.

Google provides us with several images based on common operating systems, though we can also create our own images if the existing ones don't work for us. Instances are created under a project and require a unique name. An instance needs a boot disk and a machine type. And when we create a VM instance, it will use other Compute Engine resources as needed, and that's things such as persistent disks, IP addresses, et cetera. Both instances and pre-defined machine types are zone-based resources.

Pre-defined machine types determine the hardware configuration. We mentioned it previously; there are four major types of pre-defined machine type. We have high memory, high CPU, standard, and shared-core. High memory machine types are ideal for tasks that require more memory relative to virtual CPUs. High memory machine types have 6.5 gigs of RAM per virtual CPU. High CPU machine types are ideal for tasks that require more CPU relative to memory. They have .9 gigs of RAM per virtual CPU. Standard machine types are good for tasks that need that balance between CPU and memory. Standard machine types have 3.75 gigs of RAM per virtual CPU. And then finally we have shared-core machine types which provide one virtual CPU and it's allowed to run for a proportion of time on a single hardware hyperthread on the host CPU that's running your instance. These are really designed to be cost-effective for running very small applications that aren't really resource-intensive. Now, if you skim over the list and none of these pre-defined machine types are what you need, then you can also use a custom machine type.

A custom machine type can be very cost-effective because it uses just the resources that you want. So if you need a machine that has one virtual CPU and one gig of RAM, you can do that. There are, however, some rules that you need to follow when creating a custom machine type. For example, anything over one CPU needs to be an even number and memory needs to be between .9 gigs and 6.5 gigs per virtual CPU. The total memory needs to be a multiple of 256 megabytes and also the maximum number of virtual CPUs allowed depends on the zone. Some processors can support more than others.

Okay, earlier I mentioned that instances need a machine type and a boot disk, and we've just talk about machine types. So let's cover boot disks. You can create an instance boot disk from the pre-defined images Google provides, or from a custom image which you could store on Cloud Storage or from a snapshot. So imagine you create an instance using a pre-defined image such as Debian, and then you install your web server software and get it all configured. You can then take a snapshot of that and use that to create new instances. And those new instances will have the same configuration and set-up of the instance the snapshot was based on at the time the snapshot was taken. Now this is a simple but very powerful mechanism because we can use it to set up base images or to restore an instance from back-ups and other uses. Now if you're using Linux, you can import an image from a raw disk image from existing Amazon AMIs or from a virtual box image. So this allows us to create our own custom virtual machine image. This can be really useful if we need control over the base image or if the public base images don't fit our needs. This is often useful when you need an OS that isn't already in the public images. However, it's also useful if you have very strict security requirements.

Let's see what it looks to actually create an instance through the console. Okay, you can see that once we get to the creation form, we have some options we need to fill out. We have the instance name, and recall that this needs to be unique to the project. And then we have the zone that we want this to run in. And we have the boot disk and we can base it on public images, we can use a snapshot, or if we have an existing disk that isn't already attached to a running instance, we can use that. We're just going to select Debian. And while there's more we could fill out here, we're not going to be talking about those features 'til later on in the course, so we're going to leave these as the default and we're going to select create. Okay, now if we look at the instances list, we can see our new instance is there. Let's use the command line interface so that we can describe the instance on a command line and you can see what it looks like to interact with it through the SDK.

So we'll use the gcloud compute command and we'll use the describe instances subcommand. And we get back all of this info. Now, this is the same basic info that you'd see if you were to interact with a rest API, the SDK is just using the rest API on our behalf. Now you can probably imagine the potential here from programmatically creating instances and returning data about them, or maybe programmatically identifying instances that aren't using a specific operating system that maybe you require for compliance reasons.

So we've just created a default Debian instance, which we could use for whatever we need. It's just a standard instance, but there are times when maybe we want to run complex batch tasks. And things such as this tend to do well with more computing power, and so Google offers what they call a pre-emptible instance. These are virtual machine instances that are less expensive and they run for a maximum of 24 hours. And the catch is that if the Google Cloud platform needs the resources back from these instances, they can terminate them without notice. Because of all this, we're able to use shutdown scripts to gracefully close out of any running tasks that we had. Now again, this isn't going to be suitable for all workload types, however, batch processing typically will stay running as long as we have the batch controller up and running. So in this case, pre-emptible instances will allow us extra less-expensive horsepower.

Okay, once we have an instance such as our Debian instance, we're going to need to connect into it. To connect to a Linux VM, we can use SSH. To connect to a Windows VM, we use RDP. For SSH, the simplest method is to connect via the gcloud command because gcloud will automatically handle the SSH keys, though it's also possible to generate SSH keys on our own that we can use with other tools.

Before we connect in, we need to make sure we have port 22 open, and the default network will create a firewall rule automatically for us that opens that port up. Once the port's open, we can connect in. If we're either an editor or an owner, as a role for that project, we can use the gcloud compute SSH command and it will copy down the keys required to connect in without any effort on our part. Non-project members will need to use an SSH client other than the gcloud compute command because they won't have access to pull down those keys.

Let's connect into our instance. We'll run the gcloud compute SSH command and it needs to know the instance name and the zone. Okay, now once it connects in, we get our command-line interface that we're used to when connecting in via SSH. Again, because I'm an owner of this project, I can easily this gcloud compute command to connect in, but if you weren't, you would need to generate the keys yourself and use just the standard SSH command.

Okay, so imagine we've created our instance, we connect in, and we're setting things up and we're finding that the servers that we're expecting to see just aren't on that network. What happens is, we look around and find out that we're in the wrong zone. And sometimes this happens, so when that happens, we have a few methods for moving an instance to another zone. We can use the gcloud command, calling the gcloud compute instances move command, and that's going to allow us to move an instance to a new zone. And since the gcloud commands are based on the REST API, then that means we could also use the API directly and optionally, we could take a snapshot of the disk and then use that to start up a new instance in the correct zone.

Once we have an instance or instances up and running, we'll end up needing to stop them at some point. And that's made simple again with the REST API, the gcloud command, or through the console. And we can also use the shutdown command from inside of the operating system. However there are issues with shutting down this way if you have a local SSD attached. So if you're planning on using the local SSD, make sure you look into the limitations first.

Now, between our startup process and the shutdown process, there are a few different statuses or states that an instance could be in. An instance has the provisioning state where resources are reserved for the instance, and then the instance moves into the staging status, where resources are acquired and the instance is being prepared and after that, we're in the status that we call running, and this just means that the VM instance is running. However, it doesn't mean that the operate system has fully booted, it just means that the instance has started up. And then if we shut down our instance or there's some sort of failure, we enter the stopping status. And then once it's completely stopped, we change to the terminated status, which sounds ominous, but terminated doesn't mean it's completely gone, what it means is it's just shut down until we start it up again.

Okay, now that we know about instances and we know about how to start one up, how to shut one down, let's talk about networking and that's going to be the subject of our next lesson so if you're ready to learn more about how Google Cloud platform handles networking, then let's get started with the next lesson.