dachad
First service discovery integration to pick one instance/IP - Eureka
In order to facilitate the consumption for services not statially tied to a single DNS (or maybe behind a load balancer we don't want to test), discovering and testing an individual instance from a service discovery would be great. Starting by eureka without auth will unlock its usage in Sch
@chadell , I'll take care if you don't mind
Hi! In regards to this feature, one idea from @jvgutierrez was to keep eureka integration out of the scope, and just generate a cmdclient that takes care of the service -> ip address resolution (i've found some "good ones" we can reuse or extend - they lack tests, for instance, especially to guarantee compat with latest versions -, rather than implementing from scratch as i was doing. See https://github.com/ArthurHlt/go-eureka-client or https://github.com/Alcereo/eureka-cli). So an user trying to incorporate this to their CI/CD pipeline can integrate both things... this is closer to the Unix philosophy (do one thing and do it well).
However, and just from my perspective, considering the tool mission (facilitate its integration in the test suite), I'd bet on continuing the service discovery integration, as makes easier the integration with the delivery pipelines (you avoid an extra wrapper/script...), and i think is a common need (we are already resolving dns to ip addresses for free, right? xD). Please, if you don't agree with the approach, raise your hand.
I understand your point on facilitating the integration with the delivery pipeline, but I also see using two tools is something good because if not we are making it too much tangled with Eureka (and other use-cases could need to integrate with other service discovery tools). I mean, if we can provide an easy way to decouple this it could be easy to reuse for other use cases, and if the current solutions for Eureka doesn't fulfill our requirements, we can always extend them.
A service discovery client in form of a CLI tool could be pretty useful for debugging purposes, ping $(discovery service1-backend) or nc -zv $(discovery service1-backend) 443. It can be easily reusable and you keep this tool in UNIX style, (do one thing and do it well)
Hi. Thanks everyone for the feedback, especially @jvgutierrez!! While I also think tcpgoon should just do one thing well, my concern is the discovery client means another binary/script requiring installation; that may not be a problem in most of the scenarios, but one of the project goals is to facilitate as much as possible the integration in your test suite (that's one of the reasons of deliverying also a dockerized version of the tool), so a dependency/second tool requiring stretch collaboration breaks the possibility of shipping and executing all the logic in a "single docker run".
So then, considering this, and bearing in mind this discovery logic should be as decoupled as possible to the main tool logic, the implementation could end up by:
- refactor one of the eureka clients I mentioned before so they conform an standard interface we will make any discovery implementation to follow
- apply dependency inversion: inject the discovery implementation we need as a dependency (keeping it as an external package), so the project is as decoupled as possible, and adding extra discovery implementations do require minimal changes in this project
Do not hesitate to continue sharing your feedback!!