URL maps for routing in GCP - Mini Project: Build & Apply

URL Maps for Routing in GCP

📖 Scenario: You are setting up a simple web application on Google Cloud Platform (GCP). You want to route incoming web traffic to different backend services based on the URL path. For example, requests to /app1 should go to one backend, and requests to /app2 should go to another.

🎯 Goal: Create a URL map configuration that routes traffic to two backend services based on URL paths /app1/* and /app2/*. This URL map will be used by a load balancer to direct traffic correctly.

📋 What You'll Learn

Create a URL map resource named my-url-map.

Define a path matcher with rules for /app1/* and /app2/*.

Route /app1/* traffic to backend service backend-service-app1.

Route /app2/* traffic to backend service backend-service-app2.

Set a default backend service backend-service-default for all other traffic.

💡 Why This Matters

🌍 Real World

URL maps are used in GCP load balancers to route web traffic to different backend services based on URL paths or hostnames. This helps organize and scale web applications.

💼 Career

Understanding URL maps is essential for cloud engineers and architects managing traffic routing and load balancing in GCP environments.

1

Create the basic URL map structure

Create a YAML file named url-map.yaml with a resource of kind compute.v1.urlMap and name it my-url-map. Include an empty pathMatchers list and a defaultService field set to backend-service-default.

GCP

apiVersion: compute.googleapis.com/v1
kind: compute.v1.urlMap
metadata:
  name: my-url-map
spec:
  defaultService: backend-service-default
  pathMatchers: []
# Your code here

Hint

Start by defining the URL map resource with the required name and default backend service.

2

Add path matcher for /app1/*

Add a path matcher to the pathMatchers list with name main-matcher. Set defaultService to backend-service-default and add a pathRules entry that matches /app1/* and routes to backend-service-app1.

GCP

apiVersion: compute.googleapis.com/v1
kind: compute.v1.urlMap
metadata:
  name: my-url-map
spec:
  defaultService: backend-service-default
  pathMatchers:
  # Add path matcher for /app1/* below
  # Your code here

Hint

Define a path matcher with the correct name, default service backend-service-default, and a path rule for /app1/* to backend-service-app1.

3

Add path rule for /app2/*

Add another pathRules entry to the main-matcher that matches /app2/* and routes to backend-service-app2.

GCP

apiVersion: compute.googleapis.com/v1
kind: compute.v1.urlMap
metadata:
  name: my-url-map
spec:
  defaultService: backend-service-default
  pathMatchers:
  - name: main-matcher
    defaultService: backend-service-default
    pathRules:
    - paths:
      - /app1/*
      service: backend-service-app1
    # Add path rule for /app2/* below
    # Your code here

Hint

Add a second path rule for /app2/* to the pathRules list in main-matcher.

4

Set host rules to use path matcher

Add a hostRules section to the URL map spec. Create one host rule with hosts set to ['*'] and pathMatcher set to main-matcher. This will route all hosts to the path matcher.

GCP

apiVersion: compute.googleapis.com/v1
kind: compute.v1.urlMap
metadata:
  name: my-url-map
spec:
  defaultService: backend-service-default
  pathMatchers:
  - name: main-matcher
    defaultService: backend-service-default
    pathRules:
    - paths:
      - /app1/*
      service: backend-service-app1
    - paths:
      - /app2/*
      service: backend-service-app2
  # Add hostRules below
  # Your code here

Hint

Host rules connect hosts to path matchers. Use wildcard host '*' to route all traffic to main-matcher.

Practice

1. What is the main purpose of a URL map in Google Cloud Platform's load balancing?

easy

A. To store user data for web applications

B. To create virtual machines automatically

C. To route incoming web traffic to different backend services based on URL paths or hosts

D. To monitor network traffic usage

Solution

1. Step 1: Understand URL map role

   A URL map directs web traffic to backend services depending on URL patterns.

2. Step 2: Identify correct function

   Routing based on URL paths or hosts matches the description of URL maps.

3. Final Answer:

   To route incoming web traffic to different backend services based on URL paths or hosts -> Option C

4. Quick Check:

   URL maps route traffic = B [OK]

Hint: URL maps decide backend by URL pattern [OK]

Common Mistakes:

• Confusing URL maps with storage or VM services
• Thinking URL maps monitor traffic instead of routing
• Assuming URL maps create resources automatically

2. Which of the following is the correct syntax to define a path matcher in a GCP URL map configuration?

easy

A. "pathMatcher": {"name": "pm1", "defaultService": "backend1"}

B. "pathMatchers": [{"name": "pm1", "defaultService": "backend1"}]

C. "pathMatchers": {"name": "pm1", "defaultService": "backend1"}

D. "pathMatcher": [{"name": "pm1", "defaultService": "backend1"}]

Solution

1. Step 1: Identify correct key for multiple path matchers

   The key for multiple path matchers is plural: "pathMatchers" with an array value.

2. Step 2: Confirm value type

   The value must be an array of objects, so square brackets [] are needed.

3. Final Answer:

   "pathMatchers": [{"name": "pm1", "defaultService": "backend1"}] -> Option B

4. Quick Check:

   Multiple path matchers use "pathMatchers" array = A [OK]

Hint: Use plural "pathMatchers" with array brackets [OK]

Common Mistakes:

• Using singular "pathMatcher" for multiple entries
• Using object instead of array for pathMatchers
• Mixing singular/plural keys incorrectly

3. Given this URL map snippet, which backend service will handle the request to https://example.com/images/logo.png?

{
  "defaultService": "backend-default",
  "pathMatchers": [
    {
      "name": "pm-images",
      "defaultService": "backend-images",
      "pathRules": [
        {"paths": ["/images/*"], "service": "backend-images"}
      ]
    }
  ]
}

medium

A. backend-images

B. No backend matches, request fails

C. backend-logo

D. backend-default

Solution

1. Step 1: Check path rules for "/images/*"

   The path matcher "pm-images" has a path rule matching "/images/*" directing to "backend-images".

2. Step 2: Match request URL path

   The request path "/images/logo.png" matches the "/images/*" pattern, so it routes to "backend-images".

3. Final Answer:

   backend-images -> Option A

4. Quick Check:

   Path "/images/*" matches request = backend-images [OK]

Hint: Match URL path to pathRules first, else defaultService [OK]

Common Mistakes:

• Choosing defaultService without checking pathRules
• Assuming no match causes failure instead of default routing
• Confusing path patterns with exact matches

4. You have this URL map configuration snippet:

{
  "defaultService": "backend-default",
  "pathMatchers": [
    {
      "name": "pm1",
      "defaultService": "backend1",
      "pathRules": [
        {"paths": ["/app/*"], "service": "backend-app"}
      ]
    }
  ]
}

Why does a request to https://example.com/app go to backend-default instead of backend-app?

medium

A. The defaultService overrides all pathRules

B. The path matcher name "pm1" is invalid

C. The backend service "backend-app" is not defined

D. The path "/app" does not match the pattern "/app/*" which requires a trailing slash

Solution

1. Step 1: Understand path pattern matching

   The pattern "/app/*" matches paths starting with "/app/" but not "/app" exactly.

2. Step 2: Check request path against pattern

   The request path "/app" lacks the trailing slash, so it does not match "/app/*" and falls back to defaultService.

3. Final Answer:

   The path "/app" does not match the pattern "/app/*" which requires a trailing slash -> Option D

4. Quick Check:

   Trailing slash matters in path patterns = C [OK]

Hint: Path patterns with * need trailing slash to match [OK]

Common Mistakes:

• Assuming "/app" matches "/app/*" without slash
• Thinking defaultService always overrides pathRules
• Believing backend service must be explicitly defined to route

5. You want to route requests to https://example.com/api/v1/users to backend-v1 and requests to https://example.com/api/v2/users to backend-v2. Which URL map configuration correctly achieves this?

hard

A. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-default",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"},
{"paths": ["/api/v2/*"], "service": "backend-v2"}
]
}
]
}

B. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-v1",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"},
{"paths": ["/api/v2/*"], "service": "backend-v2"}
]
}
]
}

C. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-v2",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"}
]
}
]
}

D. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-default",
"pathRules": [
{"paths": ["/api/*"], "service": "backend-v1"},
{"paths": ["/api/*"], "service": "backend-v2"}
]
}
]
}

Solution

1. Step 1: Check path rules for specific version routing

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } defines two distinct path rules: "/api/v1/*" to "backend-v1" and "/api/v2/*" to "backend-v2" which matches requirements.

2. Step 2: Verify defaultService and pathRules consistency

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } uses "backend-default" as defaultService, so unmatched paths go there, which is correct.

3. Step 3: Identify issues in other options

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-v1", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } sets defaultService to "backend-v1" which may misroute unmatched paths. { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-v2", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"} ] } ] } misses "/api/v2/*" pathRule. { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/*"], "service": "backend-v1"}, {"paths": ["/api/*"], "service": "backend-v2"} ] } ] } duplicates "/api/*" paths causing conflict.

4. Final Answer:

   Option A correctly routes /api/v1/* and /api/v2/* to respective backends -> Option A

5. Quick Check:

   Distinct pathRules for versions = A [OK]

Hint: Use distinct pathRules for each version prefix [OK]

Common Mistakes:

• Setting defaultService to one version backend
• Missing pathRule for one version
• Duplicating same path pattern causing conflicts