I would like to be able to configure APIs via json while using dashboard for key management, logging, performance, dev dashboard. Is this scenario explicitly not supported, and if so, what are the alternatives?
1 Like
Hello, are you planning to use JSON files & the dashboard?
Well, I was told in another thread that it’s not supported - it’s either file config or dashboard API, and they don’t mix well. Just wanted to confirm whether that’s indeed the case, and if so, what are my options for the scenario I outlined at the top. Basically, I want to store gateway configuration so it can go in github, and can be instantiated by simply starting a container, but I also want to use the dashboard for all the nice things it offers. What are my choices?
That’s right, this combination isn’t supported, because the dashboard uses a database to store all the configuration. This approach is the best for cloud / multiple instance deployments.
You could dump the API data from the database, and handle the provisioning of these files yourself, however this is not an approach we would recommend.
Is that the reason why file-configured APIs don’t even show up in the dashboard?
Another question is - is there a recommended and supported way to automatically provision APIs with the dashboard? Or is it always a manual process?
Right, the dashboard is loading the data from the database.
About the other question: is it under a cluster setup?
Not at the moment, but in the future I would like to run several nodes, yes.
Sounds like the answer is indeed either dashboard or file, and there is no viable way of configuring the gateway via text files while still using the dashboard.
Hi,
I’m also interested in possible solutions to the original question (which I dont think has received an answer yet).
Cloud setup of tyk.
So API config is using database, not file based.
What is the easiest way to provision the API configuration in a repeatable way (ie scripted in some way). I’m looking for the easiest way to import the file config into the dashboard I guess?
I’m a bit puzzled why the big cloud setup seems to be less foreseen for the automation of the setup whereas the small setup has a nice file-based approach?
I hope I am just missing something obvious here.
All help greatly appreciated.
I think there’s some confusion here, there are four setups:
- Cloud based setup with our cloud
- Cloud based setup with a local hybrid gateway, configuration is stored in our cloud system,
- On-premise (or your own cloud, e.g. AWS, Azure) with dashboard and gateway - here the dashboard stores the API definitions for you in MongoDB
- On-premise (or your own cloud, e.g. AWS, Azure) without dashboard - i.e. file-based installation, a.k.a Community Edition
In options 1,2 and 3 the Dashboard REST API can be used to programmatically add APIs to the setup, and in v2.3 of the software there will be an import/export API that makes it easier to create repeatable setups with the dashboard.
In option 4, it is purely file-based, and file-synchronisation across gateways is up to the implementer, we solve the centralisation / clustering problem at Tyk with the Dashboard.
If you are moving from a file-bnased to a dashboard-based approach, you can just use the Dashboard REST API to create the APIs in your new dashboard. In v2.2 it is more difficult to make this repeatable (retain IDs etc), but in v2.3, as mentioned above (released this week), it is easy.
The small setup that uses a file-based approach is the lowest-common-denominator setup of the gateway, the idea here is:
- What is the minimum requirements for someone to get started with Tyk - with Community Edition, it’s Redis and a few files
- For larger organisations, if you want a GUI etc, then it is assumed that the GUI / Management layer setup is more permanent (i.e. not designed for immutable architecture), so the dashboard provides a centralised configuration, and once set up, allows for simple gateway deployment without having to sync files - gateways here are suitable for immutable architecure, so they can be torn down and horizontally scaled without the need for syncing files etc. But you ge tthe flexibility of being able to manage the APIs that those gateways manage via na API and via a GUI centrally without re-deployment.
- For extra large orgs, you can decouple the gateways from the dashboard using our MDCB component (Multi Data Center Bridge), here you can have many gateways, autoscaling across many data centers with their own, isolated, Redis DBs, and here again, you don;t script the dashboard setup, but your deployments at the application layer are easy to replicate because everything is centralised via the MDCB master layer.
So bottom line, in v2.3 we make it easier to backup and recreate core elements of a dashboard setup, but the idea is that the dashboard and data layer are not torn-down and replicated all the time, whereas your gateways should autoscale easily and be hot-configurable from a central management layer.
Scripting a dashboard setup is quite straightforward, you use a combination of the admin and dashboard REST APIs to set up the orgs and users and then add your APIs either via the GUI or via the REST API - the objects are the same as the file-based mechanism.
To answer the original question: There are two configurations of Tyk: File based or DB-backed,there is no in-between.
thanks for the extensive reply.
we are in the category 3 or 4 solution at the moment.
base on your explanation; it will undoubtedly become 3.
looking forward to the v2.3 release this week
(we’re still using v2.2.0.28)
can I see the upcoming changes anywhere online already?