Few Queries on Apigee Edge with Apigee Edgemicro 2.0.0

[#1]

Background Information

Apigee Edge (SaaS)

Apigee Edgemicro 2.0.0

Amazon Linux

Node.js v4.4.3

I have the following questions:

1. Do my "edgemicro_test" proxy have to be deployed (either on test/prod) on Edge (SaaS) so that my Edgemicro can detect the APIs? Can I just save the configurations and not deployed it?
2. If we MUST deploy it before Edgemicro can detect it, how do we handle the case whereby my 2 proxies "test" (for external users on SaaS) and "edgemicro_test" (for internal users on-prem) APIs have the same base path (of "/test" for example)
3. For Edgemicro 2.0.0, How do I start edgemicro as a daemon/background process? I am currently using "screen".
4. For Edgemicro 2.0.0, why isnt there a "stop" and "list" function (theres only "start") ?
5. For Edgemicro 2.0.0, what is the correct way to force a sync down from Edge to Edgemicro when I make some changes to the proxy's endpoint?

[prabhat · Accepted solution]

Answers inline:

1. Do my "edgemicro_test" proxy have to be deployed (either on test/prod) on Edge (SaaS) so that my Edgemicro can detect the APIs? Can I just save the configurations and not deployed it?

It needs to be deployed. We wanted to align with Edge model where a proxy is only active when it's deployed. Do you have a strong reason for it to work otherwise? Advantage of this is that you can look at UI and see edgemicro proxies are active.

1. If we MUST deploy it before Edgemicro can detect it, how do we handle the case whereby my 2 proxies "test" (for external users on SaaS) and "edgemicro_test" (for internal users on-prem) APIs have the same base path (of "/test" for example)

Hmm good question. But let's dig a bit deeper. For external user it's different endpoint anyway so why can not that user have different base path which map to same target as your edgemicro proxies?

1. For Edgemicro 2.0.0, How do I start edgemicro as a daemon/background process? I am currently using "screen".

With 2.0.0, it's a single process so any existing mechanism you have would work. Screen is one as you have already found but you can also have it run as part of systemd/init.d.

1. For Edgemicro 2.0.0, why isnt there a "stop" and "list" function (theres only "start") ?

Those were needed in 1.x because agent "could" launch multiple instances since we don't have agent anymore, it did not make sense to keep those. The lesser the code, the lesser the bug, the lesser the documentation. 🙂

1. For Edgemicro 2.0.0, what is the correct way to force a sync down from Edge to Edgemicro when I make some changes to the proxy's endpoint?

You are on a roll for asking great questions. Kudos. 🙂 Our thinking is that you would usually have load balancer like nginx in front of Microgateway instances which allows for rolling upgrade/restart of apps behind it so you would do something similar.

[#3]

1. For Edgemicro 2.0.0, what is the correct way to force a sync down from Edge to Edgemicro when I make some changes to the proxy's endpoint?

You are on a roll for asking great questions. Kudos. 🙂 Our thinking is that you would usually have load balancer like nginx in front of Microgateway instances which allows for rolling upgrade/restart of apps behind it so you would do something similar

My response to this: I have such a massive environment - and will be running microgateway in such strange places - i dont know if this is feasable.

I would love to know how others are planning on solving this problem. I could have product managers updating product configurations at will using the UI - and I dont really have a way of capturing that data to trigger a restart (or a good way of doing it en-mass... )

Additionally - i might have ... different configurations of microgateway deployed to different places (different plugins to support different use cases) and at the moment i dont have any way of using automation to know which ones I will need to restart.

[#4]

Hi prabhat,

Thank you for your prompt response as well as the points !

Below are my replies/comments to your answers:

1. It needs to be deployed. We wanted to align with Edge model where a proxy is only active when it's deployed. Do you have a strong reason for it to work otherwise? Advantage of this is that you can look at UI and see edgemicro proxies are active.

[Leroy] My rationale of not having it deployed on Edge is because I am using Edgemicro as a fully on-prem internal gateway that is hosted within a private subnet. I am using Edge just for its configuration (e.g. creation of API through edgemicro_<<api>>). I do not want to expose my internal APIs over the internet which in this case is not possible because it has to be deployed (either on prod/test) on Edge. If the Edgemicro's APIs does not have to be deployed on Edge but rather just have a "saved" copy of it on Edge, it will enable me to have a fully on-prem internal gateway (without having to expose any internal APIs over the Internet). Right now, I have to protect my Edgemicro proxies on Edge with some kind of authentication (I know that this is ignored when Edgemicro pulls down the configurations) so that the Edgemicro proxies on Edge itself is not open to the Internet. Currently, when you create "edgemicro_test" on Edge, the Edge proxy is by default open to the world as opposed to the API proxy (on Edgemicro) that requires API key authentication by default.

Previously, I have deployed Edgemicro inside a private subnet of a VPC with NAT instance for outbound internet connection to Edge. As Edgemicro initiates the connection to Edge, it worked well with my use case as an fully on-prem internal API gateway.

2. Hmm good question. But let's dig a bit deeper. For external user it's different endpoint anyway so why can not that user have different base path which map to same target as your edgemicro proxies?

[Leroy] I would prefer APIs that are exposed to both Internet as well as internally to have the same basepath for consistency. E.g.

https://demo-org-prod.apigee.net/test

http://localhost/test

They have the same basepath of /test

3. You are on a roll for asking great questions. Kudos. 🙂 Our thinking is that you would usually have load balancer like nginx in front of Microgateway instances which allows for rolling upgrade/restart of apps behind it so you would do something similar.

[Leroy] If I made changes to target endpoint configuration on Edge, the correct way of syncing down the new configurations is via stopping the Edgemicro instance through "ctrl-c" and then start it again via "./edgemicro start" ?

[#5]

@prabhat Just in case you missed my reply.

[prabhat]

@Birute Awasthi

Can we please reward @Leroy Chan for asking great questions. I could not do it myself.

[birute]

Granted 100 points on your behalf 😉

[#8]

1. For Edgemicro 2.0.0, what is the correct way to force a sync down from Edge to Edgemicro when I make some changes to the proxy's endpoint?

You are on a roll for asking great questions. Kudos. 🙂 Our thinking is that you would usually have load balancer like nginx in front of Microgateway instances which allows for rolling upgrade/restart of apps behind it so you would do something similar

My response to this: I have such a massive environment - and will be running microgateway in such strange places - i dont know if this is feasable.

I would love to know how others are planning on solving this problem. I could have product managers updating product configurations at will using the UI - and I dont really have a way of capturing that data to trigger a restart (or a good way of doing it en-mass... )

Additionally - i might have ... different configurations of microgateway deployed to different places (different plugins to support different use cases) and at the moment i dont have any way of using automation to know which ones I will need to restart.