In this lab, you configure Cloud Content Delivery Network (Cloud CDN) for a Cloud Storage bucket and verify caching of an image. Cloud CDN uses Google's globally distributed edge points of presence to cache HTTP(S) load-balanced content close to your users. Caching content at the edges of Google's network provides faster delivery of content to your users while reducing serving costs.
In this lab, you learn how to perform the following tasks:
- Create and populate a Cloud Storage bucket
- Create an HTTP load balancer with Cloud CDN
- Verify the caching of your bucket's content
- Invalidate the cached content
The different types of backends that Cloud CDN can generate contnet for are below:
- Compute Engine virtual machine (VM) instance groups
- Zonal network endpoint groups (NEGs)
- Internet network endpoint groups (NEGs), for endpoints that are outside of Google Cloud (also known as custom origins)
- Google Cloud Storage buckets
export project id to use in creating a globally unqiue bucketname
export BUCKET_NAME=$(gcloud info --format='value(config.project)')gsutil mb -l asia-east1 gs://$BUCKET_NAMEgsutil cp gs://cloud-training/gcpnet/cdn/cdn.png gs://$BUCKET_NAME
gsutil cp gs://cloud-training/gcpnet/cdn/regions.png gs://$BUCKET_NAME gsutil acl ch -u AllUsers:R gs://$BUCKET_NAME/cdn.png
gsutil acl ch -u AllUsers:R gs://$BUCKET_NAME/regions.pngTo create a HTTP load balancer programmatically, we need to do the following
- Create the backend bucket
- Create the url map
- Create the http target proxy
- Create the forwarding rule for the frontend configuration
-
Create the backend bucket with cloud CDN enabled
gcloud compute backend-buckets create cdn-bucket --gcs-bucket-name=$BUCKET_NAME \ --enable-cdn -
Create the URL map
gcloud compute url-maps create cdn-lb \ --default-backend-bucket cdn-bucket
-
Create the target HTTP proxy
gcloud compute target-http-proxies create cdn-lb-proxy \ --url-map cdn-lb
-
Create the forwarding rule
gcloud compute forwarding-rules create http-lb-ipv4 \ --ip-version=IPV4 \ --target-http-proxy cdn-lb-proxy \ --ports=80 \ --global
Get IP Address of Load Balancer and testing timing
export LB_IP_ADDRESS=$(gcloud compute forwarding-rules describe http-lb-ipv4 --global --format='value(IPAddress)')for ((i=0;i<10;i++)); do curl -w \
"%{time_total}\n" -o /dev/null -s http://$LB_IP_ADDRESS/cdn.png; doneThe following output should be seen
When an object is cached, it normally remains in the cache until it expires or is evicted to make room for new content. Sometimes, you might want to remove an object from the cache before its normal expiration time. You can force an object, or set of objects, to be ignored by the cache by requesting a cache invalidation.
Open a new browser tab and navigate to http://[LB_IP_ADDRESS]/cdn.png, replacing [LB_IP_ADDRESS] with the IP address of the load balancer
Replacing the old image in the cloud storage bucket with a new one
gsutil cp gs://cloud-training/gcpnet/cdn/updatedcdn.png gs://$BUCKET_NAME/cdn.pnggsutil acl ch -u AllUsers:R gs://$BUCKET_NAME/cdn.pnggcloud compute url-maps invalidate-cdn-cache cdn-lb \
--path "/cdn.png"This command takes a while to run as it propages globally to all regions
In this lab, you configured Cloud CDN for a backend bucket by configuring an HTTP load balancer and enabling Cloud CDN with a simple checkbox. You verified the caching of the bucket's content by measuring the time it takes to access the image. The first time you accessed the image, it took longer because the cache of the edge location did not contain the image yet. All other requests were quicker because the image was provided from the cache of the edge location closest to your Cloud Shell instance.
You then replaced the image and observed that the old image was still being cached. You resolved this by invalidating the cache through the Cloud Console.