- Pro: Both are production ready
- Pro: Can handle any throughput we will see
- Pro: More feature rich
- Healthchecks
- DNS and HTTP API available to map endpoints
- Lots of service discovery built in
- Pro: Solution could be used in more than one place (bld/prod/etc..)
- Pro: Configurations are pesisted to disk
- Con: More moving parts
- GO templating language
- Daemon on proxy node to poll consul
- HAProxy reloads
- Con: We would only use a small subset of features [1]
- Con: Is more for a SOA when we only need dynamic hosts
[1] http://www.consul.io/intro/vs/zookeeper.html
- Pro: Currently works for our need
- Pro: No config files needed (reads everything from EtcD)
- Pro: No restarting needed
- Pro: Interacts directly with EtcD (super simple)
- Pro: Provides only the features we are using right now
- Con: New software (VulcanD is unhardened and not production ready)
- Con: Doubtful VulcanD could handle Production volume
- Con: Configurations are soley kept in EtcD and may be lost on a reboot.
- http://www.maori.geek.nz/post/the_smallest_docker_web_service_that_could
- http://www.maori.geek.nz/post/docker_web_services_with_consul
- http://progrium.com/blog/2014/08/20/consul-service-discovery-with-docker/
- https://tech.bellycard.com/blog/load-balancing-docker-containers-with-nginx-and-consul-template/
I think that VulcanD/EtcD is the best combination for the test clusters project. This is primarily due to the fact that VulcanD and EtcD seems to be a much less complex setup than using Consul + a LB. When using Consul Template [1], it is required to run an additional daemon on the proxy node in order to poll Consul, generate the output from a template, and reload the proxy. This arrangement would be perfect for SOA, but we are only doing dynamic nodes here. Also, the VulcanD method has been proven working.
[1] https://github.com/hashicorp/consul-template
If we opt to go with VulcanD, we will not be able to reuse much of this infrastructure for Production use. In practice the EtcD and VulcanD nodes will only be able to be used for the test cluster appliction. This (IMHO) does not pose a significant problem as it allows us to be more leniant with the deployment of said services (no need for Production availability) and could be swapped out in the future if a Consul / HAProxy deployment were to be deployed by IE/Ops.