Discovery Service
Every environment on Cycle comes equipped with the discovery service, which facilitates communication between container instances running within the same environment. It is responsible for looking up local container hostnames, and forwarding all other DNS requests made by containers within the environment.
How the Discovery Service Works
Cycle creates a file inside every container at /etc/resolv.conf, that routes all DNS requests to the local discovery service
at hostname env-discovery. If the request is for a local container hostname, it is resolved to one or more private network IP addresses.
If there are multiple results, all will be returned, sorted by proximity to the requesting instance.
If there are no matching instances, the request will be round-robined between DNS resolvers hosted by Google, Cloudflare, and OpenDNS. These requests will be cached for 2 minutes on the discovery service, improving lookup times for repeated queries. Failed responses are cached for 10 seconds.
The .cycle TLD
The discovery service will resolve any hostname directly, and any hostname appended with a .cycle TLD.
# Assuming the container hostname is `api`, these will both work
curl http://api
curl http://api.cycleCustom Host Resolvers
The discovery service supports setting custom host resolvers, allowing domain names to resolve to specific IPs.
Set Up Custom Resolvers
Handling Empty NOERROR responses
DNS responses are handled differently depending on the OS and the client used. When resolving IPs, the discovery service
will return an empty response with the code NOERROR for any IPv4 lookups in a non-legacy mode environment.
Some older DNS clients don't know how to properly handle these empty responses, and get stuck waiting for an actual response to the query, eventually timing out. This can cause artificially long delays when resolving local services.
If there is a noticeable delay when resolving DNS queries, the discovery service can be set to delay the return of any empty
NOERROR results. The delay ensures that a non-empty result will be returned first, which older clients will generally use
without issue.
Configure Empty Sets
Forcing Random IP Order
By default, the discovery service returns a list of IPs by proximity to the requesting instance.
If a randomized order is preferred, the hostname in the request can be prefixed with an _.
curl http://_apiExternal Resolutions
Forcing random IP order will only work when resolving containers in the environment. It will not work for external resolutions.
Manage the Discovery Service
The discovery service can be configured in a number of different ways, including within a stack.