The last piece of the Continuous Deployment Pipeline is, you guessed it, deployment. There are several options to deploy an application onto GCP, each with their own capabilities, advantages, and drawbacks. The most popular choices are App Engine Standard, App Engine Flexible, Google Kubernetes Engine, Cloud Functions, and Compute Instances.

App Engine Standard is a service that will take containers and run them on the GCP infrastructure. The containers are scaled based on load and utilization. However, only certain languages and runtimes are supported by App Engine Standard. For others, there is another alternative called App Engine Flexible, which has a wider variety of languages to choose from. However, App Engine Flexible achieves this by spinning up compute instances and running containers on them, which sacrifices some speed when scaling. There are some other minor differences between these services. For example, App Engine standard can scale down to zero, which means if it's not being utilized, there's no payment for it either. App Engine Flexible on the other hand always needs to have at least one compute instance running. So, you'll be paying for that instance whether it's being used or not.

Google Kubernetes Engine, or GKE, is GCP's managed Kubernetes offering. Kubernetes is its own subject, and there are entire courses out there devoted to how to use and manage it, but for this course, it's enough to know that Kubernetes is a container orchestrator built by Google for microservices. A lot of the patterns that other GCP services use around the creation and destruction of compute instances and containers follow the same patterns as Kubernetes, so it's worth doing some additional reading on this.

Cloud Functions is an offering which doesn't require building containers yourself. It will take code that you have written and run it for you without needing to store it in a Container Registry. These can be triggered from an event in a different service such as Cloud Storage Buckets or Cloud Pub/Sub, but they can also be called from an HTTP endpoint or on a timer. 

Finally, compute instances are like having a virtual machine in the cloud. The deployment to these is hardest to automate because nothing is managed for you. If at all possible, consider using one of the other alternatives first.

For the demo in this section, we'll build a container, run some tests on it, and then deploy it to Kubernetes all from our Cloud Build pipeline. Let's get started.

In this demo, we're going to go over how to use our CI/CD Pipeline to test, build, and deploy our app, all from Cloud Build. So, to set the stage here, I still have the same hello-cloudbuild app trigger that I had in the last demo. That hasn't changed. I also have no currently built images in the Container Registry. There are no running Kubernetes clusters in this project.

So, now that we've reviewed the infrastructure, there's two changes here that I want to draw out. The first is kubernetes.yaml, which is a build configuration file for Kubernetes. This is what we're going to use to apply our changes. Second, is the cloudbuild.yaml now has some additional steps after test. I've taken some of the other steps from the other demos in this project, and gone ahead, and put them in here as well. So, aside from test, it will now build the container, push it to GCR, and then apply that to our Kubernetes cluster.

So, now that we know all of our code is set, let's go ahead and start the demo by creating a Kubernetes cluster. I'm back here at my terminal and I'm going to run gcloud containers clusters create hello-cloudbuild with one node in the us-central1-b zone. This is gonna take a moment to run. So, let's just skip ahead.

All right, looks like my cluster's now running. Let's go back to the console. And just to confirm, here is my Kubernetes clusters, you see the hello-cloudbuild cluster is now deployed and running. We have one more step we have to do before we can make this work.

I'm here under settings in my Cloud Build console and one thing is, when you run Cloud Build, it runs it under a service account that's created for you in GCP. If I'm gonna deploy anything onto Kubernetes, I need to make one change to this account. And that is to enable this role, the Kubernetes Engine Developer. Now that that's done, I can go and start triggering my build.

I'm here with my hello-couldbuild app trigger and this would work if I pushed new code to it, which I've shown in other demos. This time I'm gonna run it manually and, since it has this handy link, we can go straight to the build. Now, it's gonna show the build steps here, all four of them, as well as the logs from bottom to top. Normally, it's top to bottom, but I've set it this way just to make it a little bit easier to read on the demo. Let's wait for this to build and see what happens.

Okay, it looks like all steps have finished and our app is deployed. Let's go ahead and check a few things first. Over here in my Container Registry, where there was not a container before, we go into hello-cloudbuild and we see there is actually a couple of images here. All right, that's it for this demo. Thanks for watching.