Now that we’ve learned about the Cloud Run architecture and two possible application deployment types, it is time to deploy our first application – a service:
- We will start by clicking the CREATE SERVICE button:
Figure 7.5 – Initial screen before deploying the Cloud Run application
2. We can choose from any container image we wish, but in our case, we will use a sample container provided by Google Cloud. To do so, we need to click the TEST WITH A SAMPLE CONTAINER button:
Figure 7.6 – Cloud Run application deployment using a sample container provided by Google Cloud
3. We can allocate CPU where we are charged for the entire life cycle of the container instance or use CPU only when requests are processed.
4. In the Autoscaling section, we can choose the minimum and maximum number of instances. By default, the minimum is set to 0. We must allocate at least one container to improve the application’s latency. To learn more about cold start in Cloud Run, go to https://cloud.google.com/run/docs/tips/general?authuser=4#start_containers_quickly:
Figure 7.7 – The Autoscaling option of Cloud Run for specifying the minimum and maximum number of instances
5. The next option is choosing service access from internal Google Cloud resources or from everywhere:
Figure 7.8 – Cloud Run traffic configuration – internal traffic or direct traffic from the internet
6. We can allow unauthenticated service invocations or force authorization with Cloud IAM in the Authentication section. We will choose Allow unauthenticated invocations:
Figure 7.9 – Cloud Run authentication configuration
7. In the following sections – Container, Networking, and Security – we can fine-tune container deployment details such as capacity (the amount of memory, CPU, timeouts, or execution environment), HTTP2 or session configuration, and service account. We encourage you to try various options while learning Cloud Run. We will proceed with the default options.
8. We can access the application via its unique URL after deployment:
Figure 7.10 – The Cloud Run application is live
9. After visiting the URL in our browser, we can access the live application:
Figure 7.11 – Cloud Run application accessed from the browser
Now that we’ve successfully deployed our first service, it is time to dive deeper into revisions and traffic management.
Cloud Run application revisions
The following steps are based on the previously deployed sample container and look at the case where we want to update or change the container image we used previously. What do we do?
- First, we need to find an image we can use to replace our existing container or change image content.
- We will use several images to demonstrate revisions: Nginx and Apache HTTP Server images.
- Let’s start with Nginx. For this, we need to click the EDIT & DEPLOY NEW REVISION button:
Figure 7.12 – New revision in Cloud Run
4. We will change the container image URL to a new one – nginx – and We will change the container port from 8080 to 80 while leaving all the other settings as-is:
Figure 7.13 – New container image and container port in the new Cloud Run revision
5. Finally, we need to click the Deploy button.
6. In our case, as the image was small, the deployment took about 5 seconds. After revisiting the unique URL, we will see that the content has changed:
Figure 7.14 – The new container has been deployed as a new revision
7. In Cloud Console, we can see that a new revision has been deployed and that it’s serving 100% traffic:
Figure 7.15 – New revision visible in Cloud Console
8. We deployed Apache HTTP Server with the httpd Docker image, where 100% of traffic is served:
Figure 7.16 – HTTPD container created with a new version where 100% of traffic is served
9. When we visit the application URL, we’ll see that the content has changed:
Figure 7.17 – HTTPD container in a browser
In this section, We showed you how easy it is to deploy new revisions of applications. It can be the exact container or a different one. We can do it very quickly and without any hassle. In the next section, we will show you how to manage traffic between revisions.