I have followed all the steps and set up my backend buckets that point to storage buckets.
However when i point to my load balancer’s forwarding rule IP in the browser, i get the following error:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<ListBucketResult>
<Name>kierkegaard-bucket</Name>
<Prefix/>
<Marker/>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>cat.jpeg</Key>
<Generation>1723653909535859</Generation>
<MetaGeneration>1</MetaGeneration>
<LastModified>2024-08-14T16:45:09.539Z</LastModified>
<ETag>"603be4bf40ae47559b446501d13ffe1f"</ETag>
<Size>242448</Size>
</Contents>
</ListBucketResult>
Seems that your load balancer is correctly pointing to the storage bucket, but it’s displaying the bucket’s XML listing instead of serving the content as a website. This usually happens when the bucket isn’t configured to serve static content. Make sure you’ve set up the bucket to host a static website by enabling the “Website configuration” in your Google Cloud Storage settings. You should specify an index page (like index.html) so that the load balancer knows what to serve when accessed.
You can assign an index page suffix and a custom error page, which are known as specialty pages. Assigning either is optional, but if you don’t assign an index page suffix and upload the corresponding index page, users who access your top-level site are served an XML document tree containing a list of the public objects in your bucket.
Yes, that is correct. If you haven’t configured your index page yet, the load balancer will serve an XML document tree listing the public objects in your designated bucket.
You can use the gcloud storage buckets update command in the CLI to set your object as the main page instead of displaying the usual bucket listing. Based on the bucket and object name you provided, you can try this command:
When you request a non-existent object, you encounter an error because the requested resource is not found. To handle this, you should configure an error page. This error page will be served by your load balancer whenever a user attempts to access a non-existent object. You can achieve this by utilizing the –web-error-page flag.
@poncejohn but what i mean to say is shouldn’t unmatched paths (for example, <frontend_IP>/abc-path) also point to the kierkegaard-backend which contains cat.jpeg. So shouldn’t any unmatched path go to the kierkegaard-backend and then return cat.jpeg?
The idea behind unmatched paths is that they allow any existing path within your buckets to be read. Any path that doesn’t match a specific rule will be served by your default backend bucket. Let’s examine your provided routing rules and backend buckets.
Routing rules:
All unmatched (default)
All unmatched (default)
kierkegaard-backend
*
/seneca/*
seneca-backend
*
All unmatched (default)
kierkegaard-backend
Based on your configuration, your default backend bucket is kierkegaard-backend, which handles all paths that exist within it. However, any request targeting /seneca/*, such as “http://<loadbalancer_front_end_IP>/seneca/dog.jpg” (assuming dog.jpg exists), will use seneca-backend. For instance, if the /seneca/ folder also exists within your default backend (kierkegaard-backend), your load balancer will prioritize seneca-backend because you have a specific path rule for /seneca/*.
Furthermore, if objects are not being served, it’s likely due to requesting non-existent paths or objects as previously discussed.
@poncejohn thank you so much for the clarification.
ah okay… so even the unmatched path still need to be existing paths within the buckets. i was under the impression that it could be any random path (unrelated to the paths within the buckets). Did i get this right.
That is correct. Your request should specify an existing path and object within your default bucket. This is why you are receiving a raw XML response due to the path not existing and no object within your request.
If you want your load balancer to serve a web error page whenever a request is not found, you can use the “–web-error-page” flag, as previously discussed.