Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:04:32 +0000.
Sender:Neil Ellis.
Date:Wednesday, 4 February 2015 16:15:26 UTC.
Hi All
I’m working on a product which could 
have 100s or 1000s of APIs - in my ideal situation I’d like to have a single server fronting all the actual docker containers (1 container per API). This would therefore mean on one machine 100s or 1000s of configs. The alternative is that I run Tyk in each Docker container and administer them centrally.
I wonder what your thoughts are in this area, whether it’s better to multi-tenant the proxying server or have a Tyk per Docker container.
Loving Tyk so far, very well done
All the best
Neil
Imported Google Group message.
Sender:Neil Ellis.
Date:Thursday, 5 February 2015 02:39:04 UTC.
Hey Martin
So I got it all working all seemed to work very well. But I realised that Tyk isn’t multi-tenant in nature and that I was going to end up bending it out of shape and adding more complexity (like one MongoDB per Docker container) than was needed to use a simple and elegant piece of software.
So what I’m doing now is simply writing the configuration locally on container start and then I will push out changes using the API.
The hardest trick in software development has to be KISS 
Thanks again for the support I wouldn’t have been able to have tried all that out without your help.
I had also a small tip - if someone wants to display the portal not at the root level (/) but in a subdirectory at present it won’t work because of absolute paths. Maybe something to think about in the future.
If I can make one final suggestion, I think charging for the type of database you use would be a better charging model. So if you use MySQL or Oracle you pay for those connectors - if you add LDAP support you’ll be able to charge for that too. That way you can keep the offering for devs and startups free or very cheap. Also the license seems pretty cheap from an enterprise perspective - so features like LDAP you could charge a lot more for. Just 2p worth.
Thanks
Neil
Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 4 February 2015 16:23:48 UTC.
Hi Neil,
It depends on how those API’s will integrate key management, for sanity, one Tyk install per API is easier on the brain, then the Tyk configs can be managed alongside the API docker configuration (since those need to be managed too) - then you can use whatever management tool that is handling your docker containers also manage the individual Tyk configs.
If you want to centralise it, I’d use a database-backed Tyk install and the advanced API, then you can have the Tyk nodes pull their configs from a central database, and manage them all using the master API, this might involve getting a license though 
I think that may be the case if you start having dynamic configurations and lots of API’s being brought up and down dynamically and you don’t want to have thousands of files floating around your servers.
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 4 February 2015 16:35:11 UTC.
Many thanks Martin
Yes, my gut instinct was to keep it simple and have one Tyk per Docker instance (I’m presuming Tyk adds little overhead even with Redis running). I was actually originally thinking of pulling the Tyk config from a central database on server startup and again on changes (using Firebase) - but it would of course be simpler to sync the info with MongoDB.
So if I understand it one MongoDB can serve many Tyk instances as long as I keep the org/app_id unique, is that correct?
And thanks again for the great work - yes I got the license hint - if I see any revenue you’re top of my list
All the best
Neil
Imported Google Group message.
Sender:Neil Ellis.
Date:Wednesday, 4 February 2015 16:46:27 UTC.
Hi Neil,
You can have a central Redis server running too, Tyk generates API Keys based on the API ID and Organisation ID assigned to the node, so it’s unlikely to have collisions. Tyk adds minimal overhead otherwise, naturally if you start looking at really intense load (more than 200-300 requests per second), there will be a performance hit, so scaling is important at that scale.
Your assumption is correct regarding Mongo serving out the configs, the structure of the config held in in the DB is slightly different (it’s a wrapped configuration), but the bit Tyk needs is exactly the same as the one on file.
I’d recommend installing the dashboard (it works fully managing one API without cost) to get the DB structure (it’s a collection called tyk_apis, the only difference is that an API configuration is wrapped in a management schema), you can then manually interface with the collection and mimic the schema to CRUD your own configs, then just point your Tyk nodes at it with unique ID’s and Orgs and you should be flying
Let me know if you need any more tips, always happy to help out
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 4 February 2015 17:34:37 UTC.
Thanks again Martin, I’m working my way through this now, is there any way of doing the initial install of the dashboard without any user interaction - so it can be scripted in a Dockerfile?
ATB
Neil
Imported Google Group message.
Sender:Neil Ellis.
Date:Wednesday, 4 February 2015 17:48:03 UTC.
Hi Neill,
The only thing the dashboard needs is a user and an organisation, and this can be created with an API call to the Advanced Management API (https://tyk.io/advanced-api-v0-9/organisations/ and https://tyk.io/advanced-api-v0-9/users/), so you can just untar the archive, and drop in a cloned configuration file.
Let me know how you get along
Thanks,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 5 February 2015 02:39:04 UTC.
Hey Martin
So I got it all working all seemed to work very well. But I realised that Tyk isn’t multi-tenant in nature and that I was going to end up bending it out of shape and adding more complexity (like one MongoDB per Docker container) than was needed to use a simple and elegant piece of software.
So what I’m doing now is simply writing the configuration locally on container start and then I will push out changes using the API.
The hardest trick in software development has to be KISS
Thanks again for the support I wouldn’t have been able to have tried all that out without your help.
I had also a small tip - if someone wants to display the portal not at the root level (/) but in a subdirectory at present it won’t work because of absolute paths. Maybe something to think about in the future.
If I can make one final suggestion, I think charging for the type of database you use would be a better charging model. So if you use MySQL or Oracle you pay for those connectors - if you add LDAP support you’ll be able to charge for that too. That way you can keep the offering for devs and startups free or very cheap. Also the license seems pretty cheap from an enterprise perspective - so features like LDAP you could charge a lot more for. Just 2p worth.
Thanks
Neil