Welcome back. In this lesson we'll be talking about persistent disks, SSDs, RAM disks, boot disks, and virtual machine images. Let's jump right into it.

Persistent disks are important because they allow us to store the operating system and/or any persistent data that we'll need to run our server and applications. Persistent disks are zone based resources and they are encrypted by default. Each instance can have a maximum of 16 persistent disks and up to 64 terabytes of storage. And while typically disks would be attached to a single instance, it is possible to attach one to multiple instances in read only mode and that's kind of cool.

Let's head in to the console and check out how to actually create a new disk. So we start on the compute engine page and we click on the disks section on the left-hand side navigation and it starts with a name. And we're going to call ours app-disk. We'll skip the optional description. We don't need it for this demo. And then let's select a zone. We're going to leave the disk as a standard disk though we could use it as a SSD, but again for a demo that's not really needed. Then let's pick an image. We don't have any snapshots so we can't select that anyway. Let's use a ubuntu image. Okay, we need a size. That 10 gigs by default is going to be fine. Then we'll also leave the encryption set to automatic. Now the other option's for customer supplied where the customer can supply their own encryption key. The abilities to use your own encryption keys are going to be important for some companies for compliance reason, however, having Google automatically manage and rotate the keys is pretty valuable so I'm going to leave this by default. Okay and now we're going to create it and it'll take just a second. Okay there it is.

The question is what did we just do? We just created a boot disk that we can use for new instances. If we create an instance and we use this disk as its boot disk it's going to have ubuntu 1604 and it's going to be up and running with 10 gigs of space.

Okay. We'll get back to taking about disks and images, however, I want to take a quick detour and I want to talk about Solid State Drives which are abbreviated SSD. Sometimes you're going to need higher IOPS than the standard disks provide. IOPS stands for Input Output Operations per Second. So for this we can use SSDs. If you find that solid state drives aren't enough random IOPS and there's also an option for local SSDs.

Now local SSDs are physically attached to the server that hosts your virtual machine instance. Local SSDs have higher throughput and lower latency than standard persistent disks and SSDs. Though the data that you store on local SSDs persist only until you stop or delete the instance. They offer sub-millisecond latency with up to 680,000 read IOPS and up to 360,000 write IOPS. Local SSDs will be great when you need to do some caching operations and you don't want to use the system memory.

So if local SSDs aren't fast enough for you then there's always RAM disks. They're extremely fast, however, they're not persistent. So as soon as you reboot or shut down, anything that you have in that disk is going to be lost.

So if we look at the disk types in this comparison we can see that both standard and SSD disks offer all of the functionalities such as snapshotting, and as you know the SSD are great for random IOPS. And then when we move to the local SSDs and the RAM disks we lose most of the features in favor of speed. So you need to consider these trade offs when selecting which type you want to use and for which type of applications you want to use them for.

Okay. Let's jump back to talking about disks and images. Do you recall when we created that persistent disk we had to select an image? We touched on it previously, but what exactly is that image? That was an operating system image and what that means is it was the disk with a boot loader and operating system and a block device containing our file system. The specific image we used was for an ubuntu image and it came from the public images that Google provides, though if we had our own image we could also use that to create instances and it would be considered a private image because it's only accessible to our projects. We can create an instance based off of any images that we have access to, public or private.

Let's check out how to actually create an instance on the command line. Okay, so here's what we'll do, we'll use the gcloud command to create and instance so we'll use the compute instances create subcommand and we just need to pass them the name of our image, and it's going to take a moment to run. Okay. Now that it's done we've created an actual instance. It's up and running. We can connect to it and use it as we need to and if we look in the console we're going to see that this same image exists and there it is. We can create instances with the console just as easily as we can create them on the command line.

Here's a few other options we can use when creating instances. Now we can create an instance from an image within the project and we've seen that, from an image in an alternate project, from a URI for a tar file that's hosted on cloud storage. We could use an alias for the latest version of an image, and finally we have the option of specifying a specific version of an image. So we have a few different methods that we can choose from when selecting the images that we want to use for our instances.

Now we can also create our own images. If we need to create an image, we can create it based on a running instance. We'd use an existing base, as our example unbuntu, and then install whatever we need to before we delete the instance and use the keep disk option and that'll leave us with a boot disk image. There's also documentation to create something from scratch if we don't want to use one of the existing images.

Images are used for things such as a bootable "gold master" image for deployment, an image with standard tools for the development teams, an image with approved production software and libraries, or even a foundation for cluster deployments. And so having images with everything we need loaded on there is incredibly valuable, however, there are alternatives to doing it this way.

We could configure instances at boot time with start up scripts. And start up scripts are something we're going to cover later in the course. We can configure with provisioning tools such as Ansible, Chef, and Puppet. We could use docker and container images. So we have options for how we would get our images production ready and due to the effort involved in setting up custom images as golden images I tend to recommend some sort of boot time configuration. Now that depends on the circumstances because sometimes you're going to have a boot time configuration that adds too much boot time and so it's going to slow down the actual process of getting that instance into the load balancer and if you're seeing heavy traffic that might be a blocker. However, if your traffic increases fairly evenly then boot time configuration will allow you to get everything installed and configured on startup. And that'll make it more flexible to implement changes because once our configuration management code has been tested and deployed we can easily run it against the targets of our choosing.

Okay, let's wrap up this lesson by summarizing what we've covered so far. We talked about persistent disks and different disk types. We talked about standard hard disk drives and how they support things such as snapshots and encryption, however it won't be as fast as solid state drives or random IOPS. We talked about local and RAM disks which are very fast, however, don't support things such as snapshots. And we talked about how to create and use disk images that can be used as a base image. And then we wrapped up the discussion by talking about methods that would allow us to use a standard image and configure it at boot time.

Okay, in our next lesson we're going to talk about authorization and IAM. If you're ready to keep going then let's get started with the next lesson.