Buildpacks for source-based deployment in GCP - Mini Project: Build & Apply

Buildpacks for source-based deployment

📖 Scenario: You are a developer who wants to deploy a simple web application to Google Cloud Platform (GCP) using Cloud Buildpacks. Buildpacks automatically detect your source code language and create a container image without writing a Dockerfile.This project will guide you through setting up a source repository, configuring buildpacks deployment, and completing the deployment process.

🎯 Goal: Deploy a source-based application to Google Cloud Run using Buildpacks. You will create the source code folder, configure the build command with buildpacks, and deploy the container image to Cloud Run.

📋 What You'll Learn

Create a source folder with a simple web application file

Set a buildpack builder variable for the build process

Use the gcloud buildpacks build command to build the container image

Deploy the built container image to Cloud Run with proper service name and region

💡 Why This Matters

🌍 Real World

Buildpacks simplify containerizing applications by detecting language and dependencies automatically, speeding up deployment without writing Dockerfiles.

💼 Career

Many cloud engineers and developers use buildpacks to streamline CI/CD pipelines and deploy apps quickly on platforms like Google Cloud Run.

1

Create source folder with app file

Create a folder called myapp and inside it create a file named app.py with the following simple Python web server code.

GCP

# Create folder myapp and file app.py with simple web server
# Your code here

Hint

Use your file explorer or terminal commands to create the folder and file. The file should contain the simple HTTP server code starting with import os and including Hello from Buildpacks!.

2

Set buildpack builder variable

Create a variable called BUILDER and set it to the string gcr.io/buildpacks/builder:v1 which is the official Google Cloud Buildpacks builder image.

GCP

myapp/app.py
import os
import socketserver
from http.server import BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(b'Hello from Buildpacks!')

PORT = int(os.environ.get('PORT', 8080))
with socketserver.TCPServer(('0.0.0.0', PORT), Handler) as httpd:
    httpd.serve_forever()

# Set BUILDER variable to 'gcr.io/buildpacks/builder:v1'
# Your code here

Hint

Assign the string 'gcr.io/buildpacks/builder:v1' exactly to the variable BUILDER with no spaces around the =.

3

Build container image using buildpacks

Write the gcloud command to build a container image named gcr.io/my-project/myapp from the myapp folder using the buildpack builder stored in BUILDER. Use the command gcloud builds submit --pack with the --builder flag.

GCP

myapp/app.py
import os
import socketserver
from http.server import BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(b'Hello from Buildpacks!')

PORT = int(os.environ.get('PORT', 8080))
with socketserver.TCPServer(('0.0.0.0', PORT), Handler) as httpd:
    httpd.serve_forever()

BUILDER='gcr.io/buildpacks/builder:v1'

# Build container image with gcloud builds submit --pack and --builder
# Your code here

Hint

Use gcloud builds submit with the --pack flag and specify the builder with --builder $BUILDER. Tag the image as gcr.io/my-project/myapp.

4

Deploy container image to Cloud Run

Write the gcloud command to deploy the container image gcr.io/my-project/myapp to Cloud Run service named myapp-service in region us-central1. Use the gcloud run deploy command with --image, --region, and --platform managed flags.

GCP

myapp/app.py
import os
import socketserver
from http.server import BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(b'Hello from Buildpacks!')

PORT = int(os.environ.get('PORT', 8080))
with socketserver.TCPServer(('0.0.0.0', PORT), Handler) as httpd:
    httpd.serve_forever()

BUILDER='gcr.io/buildpacks/builder:v1'

gcloud builds submit myapp --tag gcr.io/my-project/myapp --pack --builder $BUILDER

# Deploy to Cloud Run with gcloud run deploy
# Your code here

Hint

Use gcloud run deploy with the service name myapp-service, specify the image, region, and platform managed.

Practice

1. What is the main benefit of using buildpacks for source-based deployment in Google Cloud Run?

easy

A. They only work with pre-built container images.

B. They require you to write Dockerfiles manually.

C. They automate building and containerizing your app from source code.

D. They disable automatic scaling of your app.

Solution

1. Step 1: Understand buildpacks purpose

   Buildpacks automate the process of building and packaging apps from source code without manual Dockerfile creation.

2. Step 2: Compare options

   Claims that buildpacks only work with pre-built images or require manual Dockerfiles contradict automation; disabling scaling is unrelated.

3. Final Answer:

   They automate building and containerizing your app from source code. -> Option C

4. Quick Check:

   Buildpacks = automate build and containerization [OK]

Hint: Buildpacks automate build and container creation from source [OK]

Common Mistakes:

• Thinking buildpacks require manual Dockerfiles
• Assuming buildpacks only work with images
• Confusing buildpacks with scaling features

2. Which command correctly deploys source code to Cloud Run using buildpacks?

easy

A. gcloud run deploy --source ./app

B. gcloud run deploy --image gcr.io/my-project/my-image

C. gcloud run deploy --dockerfile Dockerfile

D. gcloud run deploy --buildpack my-buildpack

Solution

1. Step 1: Identify source-based deploy syntax

   The correct command uses '--source' flag with the path to source code.

2. Step 2: Eliminate other options

   Using --image deploys a container image; --dockerfile uses a Dockerfile directly; --buildpack is an invalid flag.

3. Final Answer:

   gcloud run deploy --source ./app -> Option A

4. Quick Check:

   Source deploy uses --source flag [OK]

Hint: Use --source flag to deploy source code directly [OK]

Common Mistakes:

• Using --image instead of --source for source deploy
• Trying to specify Dockerfile with buildpacks
• Using invalid flags like --buildpack

3. Given this command:
gcloud run deploy my-app --source ./myapp
What happens during deployment?

medium

A. Cloud Run builds a container image from source using buildpacks and deploys it.

B. Cloud Run deploys the source code directly without building a container.

C. Cloud Run requires a Dockerfile in ./myapp to build the container.

D. Cloud Run deploys a default container ignoring the source code.

Solution

1. Step 1: Understand --source deploy behavior

   Using --source triggers Cloud Run to build a container image from source using buildpacks automatically.

2. Step 2: Evaluate other options

   Cloud Run does not deploy source code directly without building a container, as it always builds one; a Dockerfile is not required; it does not ignore the source code.

3. Final Answer:

   Cloud Run builds a container image from source using buildpacks and deploys it. -> Option A

4. Quick Check:

   --source triggers buildpacks build [OK]

Hint: Deploy with --source builds container via buildpacks [OK]

Common Mistakes:

• Thinking source code is deployed without container
• Assuming Dockerfile is mandatory
• Believing Cloud Run ignores source with --source flag

4. You run gcloud run deploy --source ./app but get an error: "No supported buildpack detected." What should you do?

medium

A. Restart Cloud Run service and try again.

B. Remove the --source flag and deploy with --image instead.

C. Create a Dockerfile manually in the source directory.

D. Add a supported language file (like package.json or requirements.txt) to your source directory.

Solution

1. Step 1: Understand buildpack detection

   Buildpacks detect app type by files like package.json (Node.js) or requirements.txt (Python).

2. Step 2: Fix missing detection files

   Adding these files helps buildpacks identify how to build the app, resolving the error.

3. Final Answer:

   Add a supported language file (like package.json or requirements.txt) to your source directory. -> Option D

4. Quick Check:

   Buildpacks need language files to detect app type [OK]

Hint: Include language files so buildpacks detect app type [OK]

Common Mistakes:

• Ignoring missing detection files
• Trying to deploy without source files
• Restarting service without fixing source

5. You want to deploy a Python app with source-based deployment using buildpacks. Your source folder contains app.py and requirements.txt. Which command and environment variable setup ensures the app runs on port 8080 as Cloud Run expects?

hard

A. gcloud run deploy my-python-app --source ./app

B. gcloud run deploy my-python-app --source ./app --set-env-vars PORT=8080

C. gcloud run deploy my-python-app --image python:latest

D. gcloud run deploy my-python-app --source ./app --set-env-vars PORT=80

Solution

1. Step 1: Use source deploy with buildpacks

   Deploying with --source triggers buildpacks to build the container from Python source.

2. Step 2: Set PORT environment variable to 8080

   Cloud Run expects apps to listen on port 8080; setting PORT=8080 ensures the app uses the correct port.

3. Step 3: Evaluate other options

   Using --set-env-vars PORT=80 sets the wrong port; using --image deploys a pre-built image instead of source; omitting the PORT=8080 setting may cause failure.

4. Final Answer:

   gcloud run deploy my-python-app --source ./app --set-env-vars PORT=8080 -> Option B

5. Quick Check:

   Set PORT=8080 for Cloud Run apps [OK]

Hint: Set PORT=8080 env var when deploying source apps [OK]

Common Mistakes:

• Not setting PORT environment variable
• Using default port 80 instead of 8080
• Deploying with image instead of source