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 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
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!