HTTP vs DNS interface
256 views
Skip to first unread message
Finn Tran
Sep 27, 2016, 8:34:08 AM9/27/16
to Consul
Consul supports both. Since just about any client supports DNS already, what is the value proposition of integrating with the HTTP interface?
James Phillips
Sep 27, 2016, 10:57:29 AM9/27/16
to consu...@googlegroups.com
Hi Finn,
DNS is fine for basic service lookups and even complex behavior via
prepared queries (https://www.consul.io/docs/agent/http/query.html).
Integrating with the HTTP interface starts to add value for things like:
* Service self-registration (Nomad and Vault do this)
* Bootstrapping and built-in watching for peer nodes (Nomad does this)
* Built-in coordination using Consul's KV store (Vault does this)
* Built-in KV store integration for app configuration
(https://github.com/mitchellh/consulstructure)
Many of these are possible with DNS + consul-template + envconsul but
if an app natively integrates with Consul you can basically just start
it up and have it talk to the local Consul agent to do all these
things on its own.
-- James
On Tue, Sep 27, 2016 at 5:34 AM, Finn Tran <fina...@gmail.com> wrote:
> Consul supports both. Since just about any client supports DNS already, what is the value proposition of integrating with the HTTP interface?
>
> --
> This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/consul/issues
> IRC: #consul on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Consul" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/cfd982b8-09df-4ec8-8182-edf829b3a2c1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
DNS is fine for basic service lookups and even complex behavior via
prepared queries (https://www.consul.io/docs/agent/http/query.html).
Integrating with the HTTP interface starts to add value for things like:
* Service self-registration (Nomad and Vault do this)
* Bootstrapping and built-in watching for peer nodes (Nomad does this)
* Built-in coordination using Consul's KV store (Vault does this)
* Built-in KV store integration for app configuration
(https://github.com/mitchellh/consulstructure)
Many of these are possible with DNS + consul-template + envconsul but
if an app natively integrates with Consul you can basically just start
it up and have it talk to the local Consul agent to do all these
things on its own.
-- James
On Tue, Sep 27, 2016 at 5:34 AM, Finn Tran <fina...@gmail.com> wrote:
> Consul supports both. Since just about any client supports DNS already, what is the value proposition of integrating with the HTTP interface?
>
> This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/consul/issues
> IRC: #consul on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Consul" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/cfd982b8-09df-4ec8-8182-edf829b3a2c1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Aj K
Jan 11, 2017, 10:21:07 PM1/11/17
to Consul
Just reviving this older thread about HTTP vs. DNS to see if there are any other perspectives to consider.
One of other advantages of HTTP is that it allows future pluggability, extensibility (example plugging in your own scheduling algorithm) and control. Another consideration is of course that with DNS you need to become knowledgeable with DNS if you are running Consul on AWS such as how it interacts with AWS's own DNS service, how it will work across VPC peering and so on.
One of other advantages of HTTP is that it allows future pluggability, extensibility (example plugging in your own scheduling algorithm) and control. Another consideration is of course that with DNS you need to become knowledgeable with DNS if you are running Consul on AWS such as how it interacts with AWS's own DNS service, how it will work across VPC peering and so on.
Is HTTP api more actively worked on in opensource version?
Reply all
Reply to author
Forward
0 new messages