Service discovery catalog
Once services have been registered into the catalog with their respective health checks, application consumers can now dynamically discover results to dial these services directly. As services scale up or scale down, the service catalog becomes the source of truth for finding healthy instances of a given service using DNS.
DNS discovery
Once you have configured DNS forwarding following recommendations from the initial configuration section, you will be able to discover services and dial them directly using consul’s domain and query syntax.
The default domain name is configured as “.consul”.
[<tag>.]<service>.service[.<namespace>.ns][.<partition>.ap].<domain>
The namespace, and partition are optional. By default, all service lookups use the default namespace within the partition of the Consul agent that received the DNS query.
Consul server agents reside in the default partition. If DNS queries are addressed to Consul server agents via DNS forwarding, you must explicitly specify the partition of the target service when querying for services in partitions other than “default”.
For more information on performing DNS queries against the service catalog, refer to the documentation.
Prepared queries
To perform more advanced dynamic queries, application developers should leverage prepared queries. Prepared queries enable you to register a service query that provides more complex filtering than the DNS query parameters can provide directly. Unlike configuration entries, prepared queries can only be defined via Terraform or the API within the default Partition of a Consul datacenter. You can not create prepared queries outside of the default Partition. But, you can target services or service sameness groups located within other Partitions. When creating prepared queries that target services located in other local Partitions within the same Consul Datacenter you do not need to export these services to the default Partition like you would for services that exist in remote peers as long as your consumer Consul token has service:read permission across the Partitions.
Prepared queries provide a rich set of lookup features. You can create queries that filter by the inclusion or exclusion of multiple tags, filter by service meta values, or filter services running on nodes based on node metadata defined inside the Consul client configuration. Another important consideration is that you can define a TTL within your prepared query definition in order to reduce the load on Consul Servers and anything in the DNS forwarding path. Prepared queries also offer rich failover capabilities which will be covered in the Standardizing Consul HVD Operating Guide where we cover running Consul Enterprise across multiple regions.
{
"Name": "my-query",
"Service": {
"Service": "redis",
"Near": "node1",
"OnlyPassing": true,
"Tags": ["primary", "!experimental"],
"NodeMeta": { "instance_type": "m3.large" },
"ServiceMeta": { "environment": "production" }
},
"DNS": {
"TTL": "10s"
}
}
Below is an example DNS query to discover services leveraging the above prepared query.
my-query.query.<domain>
For detailed information on creating and reading the configuration of existing prepared queries see here.