Can I have an API proxy with a URL of an Internal Service?

Not applicable

I have some services into a internal network, and I want to deploy them using the microgateway, but for using the microgateway I need to create an API proxy and it needs a public URL, what can I do in that case?

Thanks!

Solved Solved
1 4 533
1 ACCEPTED SOLUTION

using the microgateway I need to create an API proxy and it needs a public URL, what can I do in that case?

Hmmm, yes, I think what you are saying is... the design of the microgateway requires that there be an API Proxy, but you don't want the external gateway to ever handle requests on that API proxy endpoint.

I always thought the design of the microgateway was a little unfortunate. The concept of an API proxy was well established. We all knew what that meant. Then with the launch of the microgateway, we established some magic naming conventions (edgemicro_*) on API proxies... and the proxies themselves aren't really used. Adding regular policies has no effect. Tracing won't work. The vhost is irrelevant. And there are other differences. The plugins are ... not managed in the central admin repository. Really all of this points to a need for using a different entity to manage these things used by the microgateway.

I'm describing all this to say "I feel your pain." But that is all decided now.

I think your question is , how do I configure an Edgemicro proxy that will never receive inbound calls on the Enterprise Gateway.

If that is the problem, then there's an easy solution. Create a new, secure vhost with a bogus alias. And reference that vhost in the edgemicro_ proxy. When you deploy it, the deployment will succeed, but no call will ever reach the API Proxy endpoint on the Enterprise Gateway.

Arghya described the approach here.

View solution in original post

4 REPLIES 4

using the microgateway I need to create an API proxy and it needs a public URL, what can I do in that case?

Hmmm, yes, I think what you are saying is... the design of the microgateway requires that there be an API Proxy, but you don't want the external gateway to ever handle requests on that API proxy endpoint.

I always thought the design of the microgateway was a little unfortunate. The concept of an API proxy was well established. We all knew what that meant. Then with the launch of the microgateway, we established some magic naming conventions (edgemicro_*) on API proxies... and the proxies themselves aren't really used. Adding regular policies has no effect. Tracing won't work. The vhost is irrelevant. And there are other differences. The plugins are ... not managed in the central admin repository. Really all of this points to a need for using a different entity to manage these things used by the microgateway.

I'm describing all this to say "I feel your pain." But that is all decided now.

I think your question is , how do I configure an Edgemicro proxy that will never receive inbound calls on the Enterprise Gateway.

If that is the problem, then there's an easy solution. Create a new, secure vhost with a bogus alias. And reference that vhost in the edgemicro_ proxy. When you deploy it, the deployment will succeed, but no call will ever reach the API Proxy endpoint on the Enterprise Gateway.

Arghya described the approach here.

Thanks for your reply @Dino-at-Google,

If I understood, you're saying that I can use the microgateway without doing calls to the API Proxy endpoint on the Enterprise Gateway?. At this moment I'm using Apigee trial version and I want to expose the internal services through the microgateway and if I can do it without the API proxy it could be great. Also, I have read that I need Docker or Kubernetes for deploying those services, is it correct?.

Thanks!


Yes, clients can invoke your services via the microgateway, but without traversing the public network, and without requiring the client to connect with the Edge enterpise gateway running in the cloud.

It's not quite true that "you don't need the API proxy". You need it, as a holder for the configuration. But at runtime the API proxy running in the cloud does not actually handle calls.

I always thought that rather than overloading the purpose of the "apiproxy" entity, there should have been a separate "holder of configuration" entity called a "micro proxy" or something like that. But as I said, all that stuff has been long decided.

If you want to expose internal services... . . . . you do not need to use Docker or K8s. If I understand your question correctly, you are asking about how to run and deploy your own internal services.

The microgateway is an HTTP proxy that you run. It connects via HTTP/S to a service that is accessible from the microgateway node. The target service need not be defined in docker, and it need not be deployed via kubernetes. I can run a self-standing single node HTTP Server using Apache, and the microgateway will be able to connect with it (given network connectivity of course). I can host a service with nginx, or a custom program written in Java and self-hosted. Someone recently asked about a Weblogic service - that's no problem too. The point is that any service that is HTTP-accessible, can act as the target for a microgateway.

If you happen to use Docker or k8s for your services, that's fine too. But irrelevant from the perspective of the microgateway.

To read more about the basics, check out this blog post from my buddy Nandan.

this second blog post talks about deploying the Edge microgateway on PaaS, like Google App Engine or Azure App Services. These approaches use Docker, but you don't need to use docker if you're just running the microgateway on your own nodes.

THIS github repo talks about deploying the Edge microgateway within Kubernetes environments. You don't NEED to do this. If you have k8s, then maybe it's interesting. Otherwise, not.

Hey Dino!, This is the answer that I've been looked for, Thanks so much!