Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Deploying applications from source code
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
When you deploy an application directly from source code to a service like Cloud Run, you can skip writing a Dockerfile. Instead, Google Cloud automates the process of turning your code into a container using Cloud Buildpacks and Cloud Build. Buildpacks are tools that automatically look at your source code to figure out what language it uses, like Python or Java. They then find and install all the necessary dependencies by reading files like package.json.
The automation is handled by Cloud Build, which runs the packaging process for you in the cloud. You start it with a command like gcloud builds submit --pack. Once Cloud Build finishes, it stores the final container image in Artifact Registry, which is a secure place for your software packages. This whole system supports continuous delivery by automatically moving your code from a commit to a live, running service.
When Cloud Run gets the image, it creates a serverless environment to run your application. This environment can scale up when there's traffic and even scale down to zero when idle to save costs. The process also improves security. It provides a clear record of how the image was built and can automatically update the base components to patch vulnerabilities. To keep everything secure, you should use Secret Manager for sensitive data and control who can trigger builds with IAM roles.
Using the gcloud run deploy --source command lets you deploy your code directly without building a container yourself. This method uses the same automated buildpacks to create the image. To make this work, the system needs the right permissions. You must give the Cloud Run Builder role to the service account so it has permission to build and deploy your code on your behalf.
You control how your application runs by using deployment flags. For example, you can use --set-env-vars to pass configuration settings, like database passwords, into the app as environment variables. This lets you change settings without altering your source code. You also set resource constraints to manage performance and cost. You define how much CPU and memory each instance of your app can use, and you can control how many requests one instance handles at a time (concurrency).
You can automate deployments by setting up Cloud Build triggers. This means every time you push new code to your repository, a new build and deployment starts automatically. To optimize for both performance and cost, you can also set scaling rules. For example, you can keep a minimum number of instances ready to avoid slow "cold starts" when traffic arrives, and set a maximum to prevent runaway costs during a traffic spike.
The container images created from your source code are stored in Artifact Registry. This is a private, managed repository. Using a private registry ensures that only your authorized Cloud Run services can pull the images to run them. For source deployments, Cloud Run can automatically create a repository in Artifact Registry to hold your images.
Managing who and what can access these resources is done through IAM roles. Different roles are needed for different parts of the process. For example, a developer needs the Cloud Run Source Developer role to deploy from source. The Cloud Run service itself needs the Artifact Registry Reader role to pull the image. The automation service (Cloud Build) needs the Cloud Run Builder role to create and manage the Cloud Run service. Following the principle of least privilege—giving only the permissions absolutely necessary—is key to security.
Cloud Build uses a service account to do its work, and this account must have the correct permissions to access your source code and push images to Artifact Registry. To add stronger security to your deployment pipeline, you can use Binary Authorization. This acts as a gatekeeper, only allowing container images that were built by your trusted process to run. You can also use VPC Service Controls to create a security boundary around your resources, protecting them from data leaks.