Follow up to Support Multiple Kong Instances Issue #163

[kbhuvanamohan]

Hi Martin,

Sorry I couldn't reopen the ticket #163 as I had a follow up question and clarification on the earlier query. Hence creating a new issue.

Thanks for the response. Let me try to add more context to see if this can be accomplished.

We have the scenario of two separate Kong gateways within the same private network, each publishing different set of APIs, but we want to manage and publicize them from a single Wicked portal.

We are looking for options to leverage a single Wicked portal so that

1. The API developers should have the ability to select which API Kong Gateway to publish their APIs and
2. The Application Consumers can seamlessly subscribe to any of these APIs

This way, we can maintain a single portal that can act as a catalog for all the APIs available in the Enterprise.

Thanks!

[DonMartin76]

OK, given this information and that the Kong instances are all on the same private network (and this means I assume wicked can access Kong's 8001 ports), this is probably not something which is totally impossible to achieve, even though it's not on any priority list for me currently. It would require a whole lot of changes to various components; I will try to state them here just briefly.

• In the globals.json, there would have to be a set of Kong URLs, also giving "Kong IDs", with the URLs to DNS entry (apiHost), Proxy port and Admin Port; the configuration would need to be migrated from a single Kong instance to this set of Kongs, for backward compatibility -- how to deal with the Portal/wicked.ui itself? It also needs a Kong instance.
• The administration of the Kong instances would have to be implemented in the Kickstarter
• Each API must also be marked with the desired Kong instance ID, e.g. using a gatewayId property, default to a default one (the one from the migration)
• The Kong Adapter must take this new API property into account and run the initialization multiple times, once for each Kong instance ID
• All other webhook events must also be checked for which API/Kong instance it is intended for
• The UI must take the Kong instance ID into account when displaying (a) Auth Server URLs (authorization/token endpoints) and (b) the actual API endpoints

I bet I am missing tons of special cases here, but those are must-haves.

[kbhuvanamohan]

Hello @karthiknaga87 and @miguelpoyatosmora Can you please help with providing Don with any additional information if needed?