Until recently, this is how you deployed code to Cloud Run:
- Define your container-based app with a Dockerfile.
- Build the container image and push it to the Container Registry (typically with Cloud Build).
- Deploy the container image to Cloud Run.
Back in December, we announced the beta release of source-based deployments for Cloud Run. This combines steps 2 and 3 above into a single command. Perhaps more importantly, it also eliminates the need for a Dockerfile for supported language versions.
Now you can finally go from source code to a running Cloud Run service with a single command and without having to worry about the complexities of creating a container image. It’s nice to finally see the Cloud Run deployment experience on par with Cloud Functions and App Engine.
Pleased to see that the source-based deployment is now generally available, I decided to take an existing sample of mine and convert it to use the source-based deployment.
The old deployment experience
Previously, here’s how I deployed the app, a simple .NET Core 3.0 web application.
First, I had to author a Dockerfile, which is not trivial for more complex applications.
Then, I built the container image with Cloud Build:
PROJECT_ID=$(gcloud config get-value project) SERVICE_NAME=helloworld gcloud builds submit \ --tag gcr.io/$PROJECT_ID/$SERVICE_NAME
Finally, I deployed to Cloud Run:
REGION=us-central1 gcloud run deploy $SERVICE_NAME \ --image gcr.io/$PROJECT_ID/$SERVICE_NAME \ --allow-unauthenticated \ --region $REGION
The new deployment experience
Before trying the new deployment experience, I updated the app to .NET Core 3.1 and removed the Dockerfile.
Deploying the app is now a single command:
SERVICE_NAME=helloworld REGION=us-central1 gcloud run deploy $SERVICE_NAME \ --source . \ --allow-unauthenticated \ --region $REGION
In the output, you can see that Cloud Run is using Google Cloud buildpacks to detect the type of the app, build a container using Cloud Build, and deploy to Cloud Run, all in one step:
This command is equivalent to running "gcloud builds submit --pack image=[IMAGE] ." and "gcloud run deploy helloworld --image [IMAGE]" Building using Buildpacks and deploying container to Cloud Run service [helloworld] in project [dotnet-atamel] region [us-central1] ⠼ Building and deploying... Building Container. ✓ Uploading sources... ⠼ Building Container... Logs are available at [https://console.cloud.google.c om/cloud-build/builds/c5b2e30a-de35-427e-9983-4ea73aa3cf5d?project=9364216574 40]. . Creating Revision... . Routing traffic... . Setting IAM Policy...
This is almost magical!
The new deployment experience is great if your app is one of the language versions supported by Google Cloud buildpacks:
But what happens when the buildpacks do not support the language version of your app?
To find out, I created a .NET 5.0 version of the app and tried to deploy it. The build fails with an error and the Cloud Build logs provide a clue why:
[builder] Using the latest LTS version of .NET Core SDK: 3.1.413 [builder] Installing .NET SDK v3.1.413
The build is using the latest long-term supported (LTS) version of .NET Core 3.1.413 and my app is on .NET 5.0. This is expected. Not all builders will be able to support all versions.
Thankfully, there’s an escape hatch. I manually built a Dockerfile to use .NET 5.0 and tried building again with the source:
gcloud run deploy $SERVICE_NAME \ --source . \ --allow-unauthenticated \ --region $REGION This command is equivalent to running "gcloud builds submit --tag [IMAGE] ." and "gcloud run deploy helloworld --image [IMAGE]" Building using Dockerfile and deploying container to Cloud Run service [helloworld] in project [dotnet-atamel] region [us-central1]
You can see that the
Dockerfile is now used for building and the Cloud Run service is deployed with no problems.
Try it out
Whether you want to deploy directly from source or with your custom
Dockerfile, the new source-based deployment makes it really easy to go from code to a running Cloud Run service. Check out the documentation and feel free to reach out to me on Twitter @meteatamel for any questions or feedback.
By: Mete Atamel (Developer Advocate)
Source: Google Cloud Blog