Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 14 December 2015 14:53:01 UTC.
Hi Carlos,
Yes we focussed on etcd, the service discovery setup for a Tyk API is best documented by our tests, here’s an example:
Imagine this is the configuration Consul will provide for our Upstream service:
[
{
“Node”: “foobar”,
“Address”: “10.1.10.12”,
“ServiceID”: “redis”,
“ServiceName”: “redis”,
“ServiceTags”: null,
“ServiceAddress”: “”,
“ServicePort”: 8000
},
{
“Node”: “foobar2”,
“Address”: “10.1.10.13”,
“ServiceID”: “redis”,
“ServiceName”: “redis”,
“ServiceTags”: null,
“ServiceAddress”: “”,
“ServicePort”: 8000
}
]
Then in order to create a load-balanced upstream service list for an API Definition, you can set it up with the following settings in the dashboard:
“Enable round-robin load balancing” - Checked
“Enable Service Discovery” - Checked
“Query Endpoint” - The http:// path to the consul service resource
“Does this endpoint return a list?” - Checked
“Are the values nested?” -Unchecked
“Data path:” - Address
“Is port information separate from the hostname?” - Checked
“Port data path:” - ServicePort
“Does the endpoint provide a target list?” - Checked
This should set everything up so that Tyk can extract the data from a consul endpoint for any defined API (the values in monospace should be used as is).
For your integration scenario: You use the Advanced API to push a new API Definition into Tyk, that API Definition has the above settings enabled (they all correspond to definition settings), that API definition will now use the consul endpoint to extract the data it needs to connect to the service.
We do not “Directly” integrate with Consul or Etcd, we integrate with an http endpoint that returns JSON data, you need to configure the data paths to extract the data from the JSON document that gets returned. It’s a little tricky, but it’s generic to work with almost any kind of configuration provider without a direct integration.
Let me know if that clarifies things a little.
Cheers,
Martin
