Private Base URL should be configurable through environment variable

[shahbazn]

Currently there is no way to configure Private Base URL parameter through environment variable and this will come in handy for self-managed deployments automation. With current workflow you either have to hard-code this on integration setting through online dashboard or download the file and updated it with correct internal endpoint for your backend service and use THREESCALE_CONFIG_FILE environment variable to load the file instead of pulling it from the portal.

Version

dokcer-image: registry.access.redhat.com/3scale-amp21/apicast-gateway:1.4

[mikz]

This is a bit tricky as you can have multiple services. So you'd need one variable per service, I guess? That is quite weird interface.

However, with recent policy changes you could write a policy that checks if there is some env var defined and can redefine the upstream. We are planning to do dynamic upstream policy soon and that could be used as and example how to change upstreams dynamically.

[shahbazn]

I see your point about problems with using environment variable configuration and good to know that you folks are thinking about this problem already. It would be awesome if there's a dynamic way to load internal service endpoints for self managed deployments. I have found environment variables to be easiest and most reliable when dealing with automating deployments so one suggestion could be prefixed environment variables for overriding the value from the dynamically pulled env file e.g. _API_ENDPOINT

[ianseyer]

This would be especially nice for our current use case, where we want to have multiple internally hosted gateways behind an ingress/application load balancer for path-based routing to individual gateways on the same 3scale service.

For example: user

public_url.com/v1/api_one ==> gateway_one ==> private base URL one

public_url.com/v1/api_two ==> gateway_two ==> private base URL two

Though it would appear your design paradigm would recommend two different 3scale services under a single plan. Is this correct?

[jafalter]

Would also be nice to have for us. We only have one service but have different private base URLs depending on the environment. Currently, we are taking the JSON file and manually replacing the URL in our staging APICast instance which is suboptimal.