Remember images in your cloudbuild.yaml!

If you've been using Cloud Build to automate Cloud Run service deployments for an amount of time, you might be familiar with the sort of configuration where you docker build, docker push, then gcloud run deploy your built container:

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/myproject/myservice', '.']

  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/myproject/myservice']

  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'myservice',
           '--platform', 'managed', '--region', 'us-central1',
           '--image',  'gcr.io/myproject/myservice']

The reason you have to docker push is because you want to make sure that the container repository you're using has the most recent version of your image. If you miss the push step on your first deployment, there's nothing in the registry to deploy!

Step #1: ERROR: (gcloud.run.deploy) 
Image 'gcr.io/myproject/myservice' not found.

And if you don't push each time, the version that's deployed won't be your most recent build! (Ask me how I know.)

---

So if you have to have a push step, what's the point of that images field?

images ↗

The images field in the build config file specifies one or more Docker images to be pushed by Cloud Build to Container Registry.

You're already pushing the image to the Container Registry, right?

Well, that's not all this configuration does.

If you go to your service in the Cloud Run part of the Cloud Console and navigate to the Revisions tab, you'll see information about that revision of your service:

• Container image URL: the container the revision is using
• Container build: (no build information available)
• Source: (no source information available)

If you define images, even if it ends up pushing an image you've already pushed, the Container build field populates with a direct link to the Cloud Build job that built the image!

---

Even better, if you enable the Container Analysis API and you're running your builds based on build triggers, you get a link to the exact commit your container is based on in the Source field! (Container Analysis is free, and inspects container metadata. Not to be confused with Container Scanning, which has a cost, but also enacts vulnerability scanning)

---

First config, without images: config only shows Container URL.
Second config, with images: config shows a link to the Cloud Build job log.
Third config, with images and Container Analysis API: config shows additional link to the GitHub commit that triggered the build.

---

You can enable the Container Analysis API for your project here, or with gcloud:

gcloud services enable containeranalysis.googleapis.com

You can add images: to your cloudbuild.yaml by appending it to the end:

--- a/cloudbuild.yaml
+++ b/cloudbuild.yaml
@@ -11,6 +11,9 @@ steps:
            '--image', 'gcr.io/myproject/myservice']

+images:
+    - 'gcr.io/myproject/myservice'
+

Here's to a richer Cloud Run experience!

Learn more:

• Structure of a build config file - Cloud Build Docs
• Continuous Deployment from git using Cloud Build - Cloud Run Docs
• Creating and managing build triggers - Cloud Build Docs
• Providing metadata for images - Container Registry Docs

Comments

[Reyad Salahin]

@glasnt , is there anyway to deploy to cloud run without pushing to container registry using cloud build?

[Katie McLaughlin]

Hi @reyadussalahin , there are a limited number of supported registries that you can deploy from. Check out cloud.google.com/run/docs/deployin...

[Reyad Salahin]

Thanks for your reply. I've already read it. Anyway, in this approach you still have to use Artifact Repository/Container Registry temporarily. So, I guess, there's no way to bypass it entirely.

If its not too much to ask, can you please justify this stackoverflow answer or this reddit comment.

I just wanted to deploy from docker hub directly.

[Katie McLaughlin]

With Cloud Build you can use Docker Hub cloud.google.com/build/docs/intera....

With Cloud Run for Anthos you can use Docker Hub cloud.google.com/kuberun/docs/depl... but note the warning: "As of November 1, 2020, Docker Hub rate limits apply to unauthenticated or authenticated pull requests on the Docker Free plan. To avoid disruptions and have greater control over your software supply chain, you can migrate your dependencies to Container Registry or Artifact Registry."

For Cloud Run (Fully Managed) (the typical "Cloud Run" experience), you must use Cloud Run or Artifact Registry.

[Reyad Salahin]

Thanks @glasnt . You've been a great help!

[Craig Labenz]

Thanks for unblocking me yet again, Katie :)