Hello Any help on the following use-case ? We are deploying Kong over Heroku, and we would like to be able to take advantage of Heroku github binding, and basically versionning our config. The final goal is to have a Kong instance which is controllable by some sort of “config file” versionned inside github, automatically deployed on Heroku, bringing automation, versionning in the process.
We would then be able to:
Have a versionned config file on github
Edit and push it
It redeploys automatically inside Heroku
It restarts the Kong
New routes are applied
And to “Roolback” from here to any previous point, using heroku github binding.
By nature, Kong “configuration” (I mean APIs configuration) is inside a datastore, which is not really meant to be manipulated directly, and the only stuff I found to make it declarative is https://github.com/mybuilder/kongfig which seems a good idea, but is using an old release of Kong, adds a middle Layer, and is not widely maintained.
Any thoughts / experiences / warning / advice on this ?
Yes, it is about automating tests (the project), but as you see, it is a config file that declares routes and services. That can clearly be extracted from the rest of the kong-upgrade-tests:
Quite closely answers the question. But that tool is not made as our official declarative config tool, but it might work depending on your needs. We don’t currently provide one. kongfig is probably the best that I have seen.
It would be very appreciable to hear this is upcoming to Kong core… I perfectly understand the need among load balancing and scalability, decoupled and common config, but as of 2018, everything is upcoming to a declarative approach, and having a config (this is still some sort of “config”, I guess) remaining imperative, inside such a trending framework, is a pain…
In my humble opinion, even a “choice” on using or not using the whole concept of datastore would be enough.
As a feedback, here’s our use case :
We have a separate loadbalancer
We want to deploy Kong over Heroku
The main pros for Kong (over raw nginx, haproxy, node.js as a proxy) is extensibility (plugins), community, fun, and simple configuration
For now, we’re unfortunately going to make another choice due to 2 reasons :
The lack of “config as declarative strategy” forces us to run a script at build time that make sequentail ajax queries to the server to DELETE every APIs and re-create them with some sort of config file of our own, or make some kind of diff then PUT them… As this seems to be the most reliable way (I didn’t test your solution, it looks promising though, but I’m not confident in using core-non-public-features in production)
The lack of a fully working, up-to-date Kong-backed buildpack for Heroku. https://github.com/heroku/heroku-buildpack-kong is backed by Heroku, and is non-official. The Kong version there is 0.11 and this seems too bad for us. The release cycle of it seems a bit slow too.
I fully understand your decision, and I am afraid that our product didn’t match your requirements at the moment. I look forward to get you back onboard when we can give better answers to your needs, — though it might be too late. I am really glad that you did take your time and explained your issues with Kong even when you have decided otherwise, I guess this will help others, and feedback like this is always highly valuable to us. I will point to this comment on our backlog, so that we remember it when we get this work prioritized.
I’ve been researching Kong as a possible gateway candidate at my organization. I’ve loved everything I’ve seen so far, but not being able to version the configuration has stopped me dead in my tracks. Without the ability to preserve the config in source control and easily apply it in various separate environments, I just cannot select it.
Kongfig seems to be behind Kong. I don’t see any support for services/route at this time. Other projects exist, but they have limited community support. They are just too small to rely upon.
Is there a future possibility for this feature to exist in a fully supported, core project manner? Until it does, I can only put Kong on my technology radar.
Use Konga an open source UI that helps you administrate Kong:
Then use the “snapshots” feature. This will let you take scheduled backups(think of this as your hourly/daily w/e have you version control, and apply them to other Kong clusters or to restore your existing Kong node to a prior state. His next branch almost has 100% compatibility with Kong 1.0 minus a few issues Kong is fixing around request-transformation plugin and a few others.