Cloud Endpoints on non-Google backend

[Albert Hu]

Hi,

I was wondering if there was a way to support custom HTTP endpoints that aren't built on top of a GCP backend, e.g. I have my own HTTP server that I want Cloud Endpoints to redirect traffic to. If there is, could you point me to the documentation?

Thanks in advance!

Albert

[Wayne Zhang]

There are two modes to support this:

* side-car mode:  Endpoint proxy (ESPv2) can be deployed as side-car container next to your application.   Such deployment is similar to deploying ESP in GCE provided your VM supports docker engine. and you need to create a Google service account with enough permissions to call Google API. Please see this doc for the service account key

* remote mode:  ESPv2 can be deployed at GCP (At Cloud Run),  but your backend application can be deployed at non-GCP,   you just need to set x-google-backend "address" field to your routable backend.  This should be similar to deploy your app in app-engine, but ESPv2 in Cloud run as this doc

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/8eb9afa3-64e1-428c-ae8c-e063e6677948n%40googlegroups.com.

[Albert Hu]

Thanks Wayne for your response. I've managed to set up ESPv2 on Cloud Run with a x-google-backend pointing to my custom HTTP endpoint. However, on my endpoint, I'm only receiving the payload, no headers or anything. Is there some way to forward the headers along with the body to my endpoint?

[Teju Nareddy]

Do you notice any specific headers missing? ESPv2 should forward almost all headers, it will only modify a few headers required for the HTTP request to be proxied to your backend.

I suggest double checking the code you use in your backend to retrieve the headers.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/27d38a05-8a4e-420f-88c5-1ba0154504bdn%40googlegroups.com.

--

Teju Nareddy nare...@google.com Software Engineer

[Wayne Zhang]

Are you sure your endponts only receive http body, not headers?   ESPv2 forwards both http headers and body.  I am pretty sure of that, otherwise it will not be http.  Maybe you are saying the some header are modified by ESPv2.  Yes,  ESPv2 modifies "Authorization" header in order to carry ID token.

If you don't want that, you can add "disable_auth" in the x-google-backend

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/27d38a05-8a4e-420f-88c5-1ba0154504bdn%40googlegroups.com.

[Albert Hu]

I forgot to set the proxy on my backend correctly -- the headers are forwarded as expected. Thanks so much! I'm going to play around with side-car mode and try to see if I can make that work. Just to clarify: is my understanding that my backend needs to be run from within docker in order for this to work correct?

[Wayne Zhang]

No,  your backend doesn't need to be run inside docker containers,  Its ESPv2 proxy that has to be run inside docker containers. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/18dcbf5e-b389-44ec-a441-c4e6425edb27n%40googlegroups.com.

[Albert Hu]

Just to follow up -- I want to make sure that I'm forwarding my request through ESP on GCE to a non-google backend correctly. This is my openapi.yaml file. It's pretty much the same as the one provided in the tutorial https://cloud.google.com/endpoints/docs/openapi/get-started-compute-engine-docker , except I took out the required authorization to simplify my testing and changed the endpoint. I'm using https://postman-echo.com/post as a test for my non-GCP backend for now.

# [START swagger]

swagger: "2.0"

info:

  description: "A simple Google Cloud Endpoints API example."

  title: "Endpoints on Compute Engine"

  version: "1.0.0"

host: "echo-api.endpoints.<projID>.cloud.goog"

x-google-endpoints:

  - name: "echo-api.endpoints.<projID>.goog"

    target: "<COMPUTE_ENGINE_INSTANCE_IP_ADDRESS>"

# [END swagger]

consumes:

- "application/json"

produces:

- "application/json"

schemes:

- "https"

paths:

  "/post":

    post:

      description: "Echo back a given message."

      operationId: "echo"

      produces:

      - "application/json"

      responses:

        200:

          description: "Echo"

          schema:

            type: string

On my compute engine instance, I set up a docker container running with the command

sudo docker run \
--name=esp \
--detach \
--publish=80:8080 \
--net=esp_net gcr.io/endpoints-release/endpoints-runtime:1  \
--service=echo-api.endpoints.<projID>.cloud.goog    \
--rollout_strategy=managed \
--backend=https://postman-echo.com

Is this the expected setup for non-GCP backends on top of ESP? Basically my understanding is this setup is equivalent to setting the host field of `x-google-backend` to be the value of --backend, and the using relative addressing. Is that correct?

[Wayne Zhang]

flag "--backend " was designed for side-car mode with a local backend.   We never tested it for remote backends.   You should use x-google-backend in the openapi spec to specify remote backend.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/021f6cfd-1e72-4488-9cca-baea920adbafn%40googlegroups.com.

[Teju Nareddy]

To further clarify, there are 2 recommended deployment models you can use to route to non-gcp backends:

• Deploy ESPv2 on Cloud Run, and use x-google-backend in the OpenAPI spec to specify backends that are not on GCP.
• Deploy ESPv2 and your backend on non-gcp platforms on the same host or k8s pod. This is running ESPv2 as a sidecar. Then ESPv2 will be running non-gcp, and you use the --backend flag to specify the local backend.

Your deployment is running ESPv2 on GCE, but this is only recommended if the backend is also on the same GCE host. You should not do it for routing to remote backends.

I suggest you follow this tutorial, but use https://postman-echo.com as x-google-backend's address.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/CAGJCt2PjPgJAaPKo2PJYXWj_QDXjccXy-G2-c%3D8vB57R1pG2nQ%40mail.gmail.com.

[Albert Hu]

I realized I had a misconception regarding non-GCP backend and remote backend. What I'm actually interested in is remote non-GCP backends.

In this case, the only way I can run it on ESPv2 is through the x-google-backend address then right?

[Teju Nareddy]

Yup, correct. ESPv2 on cloud run would be the correct use case for you then.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/5c863056-2b09-4d1c-9c51-dfea25d6d305n%40googlegroups.com.

[Albert Hu]

Is there some way to do this on ESPv2 on GCE? 

I'm trying to build an application where I need to figure out what region a Google Cloud Endpoint is in, but I haven't found a way to parse out the region name of a Cloud Run URL. I also tried doing a DNS lookup on the Cloud Run URL and detecting the region by matching the IP address with the cloud.json file found on https://cloud.google.com/compute/docs/faq#find_ip_range, but the resulting IP address doesn't match any of the regions.

I want to try to get remote backends working on GCE because that will actually resolve to a region, in case there's no way of finding out what region a Cloud Run URL 

[Josh Einhorn]

> Is there some way to do this on ESPv2 on GCE? 

I can't be sure, but presumably you can deploy the same ESPv2 container you're using to GCE instead of Cloud Run, however this is not documented, supported, or currently tested.

> but I haven't found a way to parse out the region name of a Cloud Run URL.

The 4th DNS label of Cloud Run's domain name is actually a "region code" and maps deterministically to a particular Cloud region e.g. "uc" -> "us-central1". There's a caveat though: this is not guaranteed to remain stable for all possible future Cloud Run Services, though as a GA product the existing URLs you have are guaranteed to be stable. Would knowing the mapping be a viable solution to your problem? Some other thoughts:

Would it help for ESPv2 to include the location of itself as a header?

Also are you the one deploying ESPv2? If so, can you store a mapping of URL -> region in some database that you own?

-Josh

[Teju Nareddy]

We never tested it, but theoretically it should work even on GCE, as long as you configure the remote backend via `x-google-backend`. Let us know if you run into problems with it.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/5715c446-02ea-477f-a94b-1a47e0fd1616n%40googlegroups.com.

[Wayne Zhang]

I think Cloud Run default host name has region info.    e.g. xyz-oxouww7xzq-uc.a.run.app.  Here "uc" is the region name.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/5715c446-02ea-477f-a94b-1a47e0fd1616n%40googlegroups.com.

[Albert Hu]

To answer your questions:

> Would knowing the mapping be a viable solution to your problem?

A list of mappings would be perfect. Alternatively, an API that can provide the region, something similar to what Google Cloud Storage has would work as well. For a bit more context on this -- users will be deploying their own Cloud Endpoints on whatever region they want. We are going to be making calls to those endpoints, and want to be able to figure out what regions each Cloud Endpoint resides in for billing purposes. Ideally, we won't have actually call the endpoint to figure out what region it is in.

> I think Cloud Run default host name has region info.    e.g. xyz-oxouww7xzq-uc.a.run.app.  Here "uc" is the region name.

I think I read somewhere that that was the case. However, It'd be a lot easier to map the host name -> region if I had a mapping between the two.

[Josh Einhorn]

Sorry for the delay, here is the current mapping (subject to the constraints mentioned in my previous message):

  de: asia-east1
  df: asia-east2
  an: asia-northeast1
  dt: asia-northeast2
  du: asia-northeast3
  el: asia-south1
  as: asia-southeast1
  et: asia-southeast2
  ts: australia-southeast1
  lz: europe-north1
  ew: europe-west1
  nw: europe-west2
  ey: europe-west3
  ez: europe-west4
  nz: europe-west5
  oa: europe-west6
  nn: northamerica-northeast1
  rj: southamerica-east1
  uc: us-central1
  tz: us-central2
  ue: us-east1
  uk: us-east4
  uw: us-west1
  wl: us-west2
  wm: us-west3
  wn: us-west4 

If you think this would be a valuable API for Cloud Run to expose, I'd suggest filing a support ticket asking for such a feature.

-Josh

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/27a38dcb-56bf-4d30-84ee-2c2aaf5a5588n%40googlegroups.com.

[Albert Hu]

Sweet, thank you!