Home > Back-end >  Trouble Building and Deploying a Docker Container to Cloud Run
Trouble Building and Deploying a Docker Container to Cloud Run

Time:04-23

I've had a couple Cloud Run services live for several months. However, I attempted to make some updates to a service yesterday, and suddenly the scripts I have been using since the beginning are no longer functioning.

gcloud build submit

I've been using the following command to build my node/npm project via the remote docker container:

gcloud builds submit --tag gcr.io/PROJECT_ID/generator

I have a dockerfile and .dockerignore in the same directory as my package.json from where I run this script. However, yesterday I suddenly started getting an error which read that a dockerfile is required when using the --tag parameter and the image would not build.

Tentative Solution

After some research, I tried moving my build cnfig into a gcloudbuild-staging.json, which looks like this:

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "gcr.io/PROJECT_ID/generator",
        "."
      ]
    }
  ]
}

And I've chnaged my build script to:

gcloud builds submit --config=./gcloudbuild-staging.json

After doing this, the container will build - or as far as I can tell. The console output looks like this:

------------------------------------------------- REMOTE BUILD OUTPUT --------------------------------------------------
starting build "8ca1af4c-d337-4349-959f-0000577e4528"

FETCHSOURCE
Fetching storage object: gs://PROJECT_ID/source/1650660913.623365-8a689bcf007749b7befa6e21ab9086dd.tgz#1650660991205773
Copying gs://PROJECT_ID/source/1650660913.623365-8a689bcf007749b7befa6e21ab9086dd.tgz#1650660991205773...
/ [0 files][    0.0 B/ 22.2 MiB]                                                
/ [1 files][ 22.2 MiB/ 22.2 MiB]                                                
-
Operation completed over 1 objects/22.2 MiB.
BUILD
Already have image (with digest): gcr.io/cloud-builders/docker
Sending build context to Docker daemon  785.4kB

Step 1/6 : FROM node:14-slim
14-slim: Pulling from library/node
8bd3f5a20b90: Pulling fs layer
3a665e454db5: Pulling fs layer
11fcaa1377c4: Pulling fs layer
bf0a7233d366: Pulling fs layer
0d4d73621610: Pulling fs layer
bf0a7233d366: Waiting
0d4d73621610: Waiting
3a665e454db5: Verifying Checksum
3a665e454db5: Download complete
bf0a7233d366: Verifying Checksum
bf0a7233d366: Download complete
8bd3f5a20b90: Verifying Checksum
8bd3f5a20b90: Download complete
0d4d73621610: Verifying Checksum
0d4d73621610: Download complete
11fcaa1377c4: Verifying Checksum
11fcaa1377c4: Download complete
8bd3f5a20b90: Pull complete
3a665e454db5: Pull complete
11fcaa1377c4: Pull complete
bf0a7233d366: Pull complete
0d4d73621610: Pull complete
Digest: sha256:9ea3dfdff723469a060d1fa80577a090e14ed28157334d649518ef7ef8ba5b9b
Status: Downloaded newer image for node:14-slim
 ---> 913d072dc4d9
Step 2/6 : WORKDIR /usr/src/app
 ---> Running in 96bc104b9501
Removing intermediate container 96bc104b9501
 ---> 3b1b05ea0470
Step 3/6 : COPY package*.json ./
 ---> a6eca4a75ddd
Step 4/6 : RUN npm ci --only=production
 ---> Running in 7e870db13a9b

> [email protected] postinstall /usr/src/app/node_modules/protobufjs
> node scripts/postinstall

added 237 packages in 7.889s
Removing intermediate container 7e870db13a9b
 ---> 6a86cc961a09
Step 5/6 : COPY . ./
 ---> 9e1f0f7a69a9
Step 6/6 : CMD [ "node", "index.js" ]
 ---> Running in d1b4d054a974
Removing intermediate container d1b4d054a974
 ---> 672075ef5897
Successfully built 672075ef5897
Successfully tagged gcr.io/PROJECT_ID/generator:latest
PUSH
DONE
------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                                    IMAGES  STATUS
8ca1af4c-d337-4349-959f-0000577e4528  2022-04-22T20:56:31 00:00  31S       gs://PROJECT_ID/source/1650660913.623365-8a689bcf007749b7befa6e21ab9086dd.tgz  -       SUCCESS

There are no errors in the online logs.

gcloud run deploy

Here is the code I use to deploy the container:

gcloud run deploy generator --image gcr.io/PROJECT_ID/generator --region=us-central1 --set-env-vars ENVIRONMENT=DEV

The console output for this is:

Deploying container to Cloud Run service [generator] in project [PROJECT_ID] region [us-central1]
✓ Deploying... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [generator] revision [generator-00082-kax] has been deployed and is serving 100 percent of traffic.
Service URL: https://generator-SERVICE_ID-uc.a.run.app

No errors in the run console, either. It shows the deployment as if everything is fine.

The Problem

Nothing is changing. Locally, running this service with the front-end app which accesses it produces successful results. However, my staging version of the app hosted on Firebase is still acting as if the old version of the code is active.

What I've Tried

  • I've made sure I'm testing and deploying on the same git branch
  • I've done multiple builds and deployments in case there was some kind of fluke.
  • I've tried using the gcloud command to update a service's traffic to its latest revision
  • I've made sure my client app is using the correct service URL. It doesn't appear to have changed but I copy/pasted it anyway just in case

My last successful deployment was on March 19, 2022. Since them, the only thing I've done is update all my WSL linux apps - which would include gcloud. I couldn't tell what version I ws on before, but I'm now on 38.0.0 of the Google Cloud CLI.

I've tried searching for my issue but nothing relevant is coming up. I'm totally stumped as to why all of this has stopped working and I'm receiving no errors whatsoever. Any suggestions or further info I can provide?

CodePudding user response:

gcloud builds submit should (!?) continue to work with --tag as long as there is a Dockerfile in the folder from which you're running the command or you explicitly specify a source folder.

I'm not disputing that you received an error but it would be helpful to see the command you used and the error that resulted. You shouldn't have needed to switch to a build config file. Although that isn't the problem.

Using latest as a tag value is challenging. The term suggests that the latest version of a container image will be used but this is often not what happens. It is particularly challenging when a service like Cloud Run is running an image tagged latest and a developer asks the service to run -- what the developer knows (!) is a different image -- but also tagged latest.

As far as most services are concerned, same tag means same image and so it's possible (!) either that Cloud Run is not finding a different image or you're not providing it with a different image. I'm unclear which alternative is occurring but I'm confident that your use of latest is causing some of your issues.

So.... for starters, please consider using a system in which every time you create a new container, you tag it with a unique identifier. A common way to do this is to use a commit hash (as these change with every commit). Alternatively you can use the container's digest (instead of a tag) to reference an image version. This requires image references of the form {IMG}@sha256:{HASH}.

Lastly, gcloud run now (has always?) supported deployment from source (folder) to running service (it does the Cloud Build process for you and deploys the result to Cloud Run. It may be worth using this flow to reduce your steps and thereby the possibility of error.

See: Deploying from source code

  • Related