In this article, I'm going to show you what you need to know to deploy a single Cloud Run app from the command line – the stuff you'll need to do once, stuff you need to do for each project, and stuff you'll need to do for each app.
Stuff you need to do once
1. Sign up for a Google Account
You can sign up here.
Once you have an account, you'll have access to both
- a Free Trial
- a Free Tier
The Free Trial provides $300 of Cloud Billing credits to pay for resources for 90 days while you learn about Google Cloud.
The Free Tier provides access to Google Cloud products for free beyond the Free Trial as long as you stay below the Free Tier limits.
2. Enable billing
If you're using the Free Trial, Google creates a billing account for you and credits $300 to your account.
Once your Free Trial ends, you can continue to use the Free Tier, but you'll still need to enable a billing account.
3. Install the Google Cloud CLI
While you might find that using the Google Cloud online console or Cloud Shell environment meets your occasional needs, for maximum developer efficiency you will want to install the Google Cloud CLI (
gcloud) on your own system where you already have your favorite editor or IDE and git set up.
Enable gcloud interactive shell
Once you have downloaded and extracted the archive to
google-cloud-sdk directory and added it to your path, then you can then enable the gcloud interactive prompt. This feature is for
bash, so you will either need to start a
bash shell or else use
gcloud without the interactive prompt.
This is a beta feature, so to enable it, enter the following command.
gcloud components install beta
The interactive prompt makes it easier to work with
gcloud commands in your shell by providing menus for command completion along with contextual help.
Enter the following command.
gcloud beta interactive
Your shell should look something like this now:
Note the tips provided for command completion.
I like to use an alias for launching the interactive shell. You can create an alias (like
gshell) with the alias command:
alias gshell="gcloud beta interactive"
Stuff you need to do for each project
In this context, a project specifically refers to the collection of cloud infrastructure and application resources you will provision and deploy on Google Cloud.
You can deploy multiple Cloud Run apps (services) as part of the same project.
1. Log in
You might have several accounts, or your login has expired, or this is your first login. In any case, you can login with the following command:
gcloud auth login
This will open a page using your web browser. Confirm that the page is a link under https://accounts.google.com/ and authorize the Google Cloud SDK to be able to access your Google account. After that, you can close the page. Back in your shell, you should see confirmation that you've logged in like this:
2. Create your Google Cloud project
If you already have a specific Google Cloud project to use, you can skip this section and go on to 3. Link your project to a billing account.
Once you're logged in, you can create or specify an existing Google Cloud project to use and configure locally.
gcloud projects create my-amazing-demo-1
Note: If you're creating a project as part of an organization, you'll need to know the Folder ID that your project should be under. Discussing organization accounts is beyond the scope of this article, but you can learn more here. The command to create the project has an option for providing the Folder ID:
gcloud projects create [PROJECT_ID] --folder [FOLDER_ID].
3. Link your project to a billing account
Once you've created the project, you must link it to a billing account (see 2. Enable billing). You can find your billing account ID on your billing accounts page.
gcloud beta billing projects link my-amazing-demo-1 --billing-account 0X0X0X-0X0X0X-0X0X0X
As you might have noticed in the image above, I have my billing account ID saved in a shell variable.
4. Configure your Google Cloud project
Now you can configure settings for your current project so that you don't need to specify them as options each time you run a
Although you can set default settings, I highly recommend that you create named, project-specific configurations to make switching between projects easier. I also recommend that you give the configuration the same name as the project to help you remember the association when listing or switching configurations, as shown below.
Common settings for Cloud Run projects shown below include the project ID, run/region you want to deploy your app to, and artifacts/location (same thing as region) for your project's Docker repository (for storing the images for launching Cloud Run service containers for your apps).
gcloud config configurations create my-amazing-demo-1 gcloud config set account YOUR_ACCOUNT_EMAIL gcloud config set project PROJECT_ID gcloud config set run/region REGION gcloud config set artifacts/location REGION
To view your current configuration values:
gcloud config list
To list all of your configurations:
gcloud config configurations list
5. Enable Google Cloud service APIs
You will need to enable a few common Google Cloud service APIs for your project to be able to build, store, and deploy Cloud Run apps.
- To build Docker container images for your serverless apps, you need to enable Cloud Build.
- To store the Docker container images you'll need to launch serverless app containers on Cloud Run, you need to enable Artifact Registry.
- To launch and scale your serverless app containers, you need to enable Cloud Run.
These services all expose APIs that you will use through
Enter the following commands:
gcloud services enable cloudbuild.googleapis.com gcloud services enable artifactregistry.googleapis.com gcloud services enable run.googleapis.com
In addition to these APIs, Google provides many other APIs for hosting your apps (such as Cloud Functions) or for being used programmatically to facilitate building your apps (Memorystore, Pub/Sub, etc.). Take a look at the API Library and the API Explorer.
6. Create a Docker repo for your apps
After the Artifact Registry API has been enabled, you create a project-specific Docker container repository. The benefits of doing this is that your container repository will be in the same physical region as your Cloud Run apps under the same security policies as the rest of your project.
The following command assumes you'll name your Docker container registry as
gcloud artifacts repositories create docker-repo --repository-format=docker
Stuff you need to do for each app
1. Activate your project
Confirm that you're using the right project configuration and if not, then activate (switch to) it.
You can confirm that you're using the right project with either of the following two commands.
List all configurations and indicate which one is active (
gcloud config configurations list
List current settings and tell you the active configuration currently in use:
gcloud config list
If the configuration for the project you want to use is not currently active, then activate it with this command:
gcloud config configurations activate PROJECT
This assumes you're using the convention I recommended previously where your configuration has the same name as your Google Cloud project ID.
The interactive shell displays the active project as well:
2. Deploy your app
At this point you can finally deploy your app with a single command:
gcloud run deploy SERVICE_NAME --source=. --allow-unauthenticated
--source=. option tells
gcloud to deploy from the current directory.
--allow-unauthenticated option tells
gcloud to make your app URL publicly available when it deploys.
Try everything out with a demo
First, make sure you've taken care of all the stuff you need to do once.
Then, using your own shell, take care of the stuff you need to do for each app, as shown in the example below.
Note: Give your project a unique name and choose a region from one of these Cloud Run locations. Remember, you don't pay for anything during the free trial and even after that as long as your usage doesn't exceed the Cloud Run pricing rather generous quotas (CPU, memory, requests) for the free tier.
# Substitute with your own shell variable values $ BILLING_ACCOUNT=0X0X0X-0X0X0X-0X0X0X $ ACCOUNTfirstname.lastname@example.org $ PROJECT=cloud-run-hello-app-demo $ REGION=us-central1 $ SERVICE=hello $ gcloud auth login ... $ gcloud projects create $PROJECT ... $ gcloud beta billing projects link $PROJECT --billing-account $BILLING_ACCOUNT ... $ gcloud config configurations create $PROJECT $ gcloud config set account $ACCOUNT $ gcloud config set project $PROJECT $ gcloud config set run/region $REGION $ gcloud config set artifacts/location $REGION .... $ gcloud services enable cloudbuild.googleapis.com $ gcloud services enable artifactregistry.googleapis.com $ gcloud services enable run.googleapis.com ... $ gcloud artifacts repositories create docker-repo --repository-format=docker
Now deploy your server code. You can clone this repo for a simple demo:
$ git clone https://github.com/subfuzion/cloud-run-hello-app-demo.git $ cd cloud-run-hello-app-demo $ gcloud run deploy $SERVICE --source=. --allow-unauthenticated This command is equivalent to running `gcloud builds submit --pack image=[IMAGE] .` and `gcloud run deploy hello --image [IMAGE]` Building using Buildpacks and deploying container to Cloud Run service [hello] in project [cloud-run-hello-app-demo] region [us-central1] ✓ Building and deploying new service... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at https://console.cloud.google.com/cloud-build/builds/d71d846a-782d-4161-bbfa-a3f289ae669a?project=243539805744]. ✓ Creating Revision... ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [hello] revision [hello-00001-wek] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-5maonkvcja-uc.a.run.app
Presto! If all went well, your app is deployed at the Service URL, like shown above. If not, you'll need to investigate using the link to the build log shown instead.
While deploying an app is easy, there's no denying that there's quite a bit of administrative effort involved up front to get to that point. Although we're focused on serverless apps, Google Cloud provides many different services for running your workloads at planet scale along with a robust security model for enforcing enterprise policies that does add complexity even for modest needs.
In the next article in this series, we're going to show you how you can wrap most of these steps in a Node.js command-line app that you can use for your projects to streamline the effort.
We'll accomplish this in two stages, first wrapping
gcloud shell commands, and then refactoring to use the Node.js Cloud Client Library to invoke the necessary Google Cloud APIs directly. Once you see how this works, you'll be able to tailor the command-line app to suit your own specific needs as they evolve.
There may be dragons!
If you found this article helpful, give it a like and bookmark it. If you have any questions or suggestions, let me know in the comments. Then give me a follow and get notified when I publish the next article in the series. Stay tuned!
Oldest comments (0)