Imported Google Group message.
Date:Tuesday, 14 April 2015 09:01:30 UTC+1.
A few people have reported success in running with docker, i believe the ones on dockerhub are a bit old though. From 1.6 onwards the release tag on github will have a stable binary in the /stage folder (it's there in master, but it's the latest build, not tagged release).
We're looking at making it easier to deploy with docker, and would be keen for the community to share their setups so we can help otpimise a "supported" version.
Supervisord can be tricky to get up and running, it usually requires absolute paths and the right permissions to run, supervisord would probably also be better for a regular server setup.
With a dockerised setup I'd recommend just running the application directly, as all it needs are the text-based config files to get started.
A dockerised Tyk setup would look something like this:
- A container for Mongo - This DB would need to be seeded with a manual dashboard setup at least once in order to create the base organisation record and a single dashboard user
- A container for your RedisDB
- A container per Tyk node, configured with the virtual IP of your dockerised MongoDB / RedisDB, with Tyk, so long as the configuration/app files are in /etc/ it will work just fine (you can just use the .deb package for this), this dcontainer should also have an instance of the host manager and it's asociated config file (simplest way to manage hot reload via the dashboard). For this you might need Supervisord, but you could also just run it as a process in the background.
- A container per Dashboard instance - Dashboard comes as a tarball and needs to run from within it's directory, it can;t live outside (e.g. /usr/bin), it has a lot more files it is dependent on, which is why it's like this for now.
The tricky thing is ensuring that each application can see the other, Tyk needs to be able to see MOngo and Redis, the Dashboard needs to be able to see a single tyk node (usually via a LB), Redis and Mongo
We suggest Supervisord because it's good at keeping processes running and does all the log management for you, would recommend if you are going down the supervisord route, to try it an avagrant instance first in non-daemon mode to debug it properly before transferring the configuration to docker
Keen to hear other people's experiences and setups, this is somehting we are very interested in and any support is appreciated!
- show quoted text -