Apigee with target backend cloud run in internal ingress

[sbouh]

Hello,

I have a backend service on CloudRun running with ingress=internal. This service is accessible through a VM in the same VPC. When i try to access it through Apigee (pay-as-you-go) that has been created in the same VPC i get a 404 not found. Is there any solution to get direct access without using and internal LB and PSC with Service attachment?

[gonzalezruben · Accepted solution]

You can increase the default 30 seconds timeout to the longest amount of time that your expect your psc backend to need in order to process a response.  For example:

gcloud compute backend-services update demo-psc-backend-service --global --timeout=31 --project=${PROJECT_ID}

 Alternatively you can also use the load balancer UX to update backend service timeout value.

[gonzalezruben]

Hi!

Unfortunately you can't configure Apigee to consume a Cloud Run endpoint that only allows traffic from internal VPCs or load balancers without using an ILB and PSC. Alternatively, you can follow this tutorial to consume Cloud Run with direct Internet access and protecting the traffic with Cloud IAM and Google Authentication. 

[dchiesa1]

---

@gonzalezruben wrote:

you can't configure Apigee to consume a Cloud Run endpoint that only allows traffic from internal VPCs or load balancers without using and ILB and PSC.

---

...this is because Apigee is a managed service and runs in a VPC that is owned and operated by Google.  It's not running in *your* VPC. It's a VPC that is dedicated to you, but it's a different security domain, so you need the ILB + PSC to connect form Apigee X to cloud run. 

[sbouh]

Hello,

Thanks for replying. I understand that Apigee runs on its VPC which is peered with my VPC. But I guess more people will ask for a feature giving direct access to serverless resources (cloud run). The problem with internal LB is that the timeout for requests is 30s and we can't change that. So it puts a limitation on our architecture.  Will be there anything in your roadmap to deal with that?

[gonzalezruben · Accepted solution]

You can increase the default 30 seconds timeout to the longest amount of time that your expect your psc backend to need in order to process a response.  For example:

gcloud compute backend-services update demo-psc-backend-service --global --timeout=31 --project=${PROJECT_ID}

 Alternatively you can also use the load balancer UX to update backend service timeout value.

[sbouh]

Hello Gonzalezruben,

I don't think there's a way to configure the timeout for a serverless neg backend. I quote from the documentation: 

" The backend service timeout setting does not apply to backend services with serverless NEG backends. Attempting to modify the backend service's resource.timeoutSec property results in the following error: Timeout sec is not supported for a backend service with Serverless network endpoint groups."

I tested it with your command, and i got the resource.timeoutSec error.

Even in the ILB interface it's disabled:

[gonzalezruben]

My mistake. I was referring to a PSC NEG. You're correct. The serverless NEG timeout isn't configurable. However, the default value is very generous (60 minutes).

[sbouh]

Yes the CloudRun itself timesout after the 60min which more than enough. The problem resides in the ILB which forces the timeout at 30s which is not enough when retrieving alot of data. Is this a bug in the LB? Is there any workaround for this?

[gonzalezruben · Accepted solution]

The UX and backend service resource showing 30 seconds as default is a known issue however the timeoutSec property is ignored for serverless NEG backends.

[dchiesa1]

oooh, this is good to know!   Thanks, Ruben!