Getting Started

It is now time to set up our Cloud Run Instance that will run our wiki. Cloud run can be thought of as Containers as a Service. In the background it runs a Kubernetes style engine that orchestrates (starts, stops, and scales) containers automatically. The benefit to us is that it is fully managed by Google so we simply provide a container and some operational guidelines and Google handles the rest. On top of this Cloud Run is able to scale the number of running containers down to zero so that if nobody is using our wiki we will not be billed for having an active server running. If someone attempts to view the wiki when it is scaled to zero Google will simply start up a container and show it to our user as if nothing had happened.

Navigate to Cloud Run

On the top left of the screen there are three horizontal white lines. This is generally known as a "Hamburger" menu. Clicking on this will fly out a list of Google Cloud Resources that you can set up inside of your project. To set up our Cloud Run instance we need to scroll down this list until we find the “Serverless” section and the item “Cloud Run”.

Create Service

Google refers to Cloud Run instances as Services so for your first instance you will be shown a button to "Create Service". As well as being shown a brief description of what Cloud Run services are

Select Image

You will be asked to select a container image to use when starting the service. clicking on the Select button will being up a second menu where you will want to select your Artifact Registry then use the arrow buttons to navigate to your Repository and your desired Image and Version.

CPU Allocation

You will be given the options to have the CPU only on when it is handling a request or to have one fully dedicated to your service. In my case I am happy to let the CPU idle when my service is not being used. This means I will not be billed when my service is not in use.

Autoscaling

Another trick that Cloud Run can do is to launch multiple containers with the same image and route traffic to each one separately to handle large volumes of requests. Then as the demand decreased it can shut down unused containers to save costs. In my case I am allowing it to scale all the way down to zero containers. This is effectively having no service running. It means that there will be a small delay of a few seconds for the first person to come along and request my service (Cold Starts). But it also means that when not in use I will not be billed for having resources allocated.

Allowed Traffic

Google will allow you to select where you want to allow traffic from. This is generally used when you have a service you want to use but you want to make sure it is not available to the public. You can use this to allow only internal traffic from your account or set up your own internal load balancer.

For our purposes we will "allow all traffic" as this will let people reach our service from the internet.

Authentication

Just because we are allowing people to navigate to our page does not mean that we are allowing them access to it. With this option we can either allow everyone to access our service or we can restrict it to only people who have authenticated with our IAM policy.

Container Options

Here we need to tell Google what port inside of the container to send traffic to. For our purposes we want to use port 80. that is where the Apache web server is listening. There is also a section for changing the Entry point and Arguments that are run when the container starts. I recommend leaving these blank if you do not know what you are doing. These are set in the Dockerfile when creating the image and making changes can cause the container to crash.

Capacity

Here we can set how much RAM and how many CPUs to attach to each container. As well as how long to wait for a response from a container, and how many connections we believe that each container can handle at once.

To properly determine these numbers we would need to perform some load testing but for now I am going with 1 CPU and 0.5GB of Ram with a wait of 300 seconds and a maximum of 80 connections per container.

Execution Environment

Environmental Variables and Secrets

This is where we will add any details that we want to expose to the system as Environment variables. For our purposes we will use these variables as a way to remove sensitive information from the container as well as to provide an easily updateable external source of information.

• FQDN: Stands for Fully Qualified Domain Name. This will be updated in a later step after we launch our service and are given its Uniform Resource Locator (URL)
• DBHOST: This is where we will set the location of a Unix Socket that connects our container to our database. Using both the MediaWiki and the Google Cloud requirements it will need to be in the form of "localhost:/cloudsql/[Cloud SQL Connection Name]"
• DBNAME: This will be the name of our database inside of Cloud SQL
• DBPREFIX: This will be a prefix to our table names (if applicable)
• DBUSER: Username used to access your Cloud SQL databse
• DBPASS: Password used to access your Cloud SQL databse
• CONFIGBUCKET: Name of the storage bucket to hold configuration files
• IMAGEBUCKET: Name of the storage bucket to hold uploaded images and files

Do not worry about knowing what values to add here yet. We are simply adding them now so that we can update the values in a later step.

Secrets are another way to attach sensitive information to a container that we will not be using or covering in this instance.

Cloud SQL Connection

In the connections tab we find an option to add a connection to Cloud SQL. This builds the Unix Socket between the Cloud Run instance and our Cloud SQL instance. We will want to Add the connection to our Cloud SQL server.

Service Account

Under the Security Tab we are able to select which service account we would like to attach to our Cloud Run Instance. We will want to select the FUSE service account we created in previous steps (Creating a Service Account).

without selecting our created service account then container will not be able to connect to our storage buckets.

Instance Overview

with all of our options set we can create our new Cloud Run Instance. It may take serval minutes for Google to build up your service, but once it has started you will be shown a screen like the one above that tells you the URL to the container and several key metrics for its performance.

Next Steps

Setting Up your Wiki