StackPath Edge Compute provides an internal Discovery DNS service that lets all instances within the same workload to discover IP information about each other. The Discovery DNS service will automatically update when instances are created, removed, or updated. This service provides a Service Discovery solution through DNS that many existing solutions can leverage.
Overview
The Discovery DNS service is an internal-only DNS that provides basic service discovery capabilities exposed through standard DNS queries. Discovery DNS can be used to determine the public and private IPs of instances running within Edge Compute. This is accomplished through the creation of PTR records for each instance that resolve back to the FQDN of the instance. Instance PTR records will not be resolvable outside of Edge Compute.
Users will be required to use the StackPath DNS resolver (169.254.169.254) to leverage this functionality.
Discovery DNS vs StackPath DNS
DNS records created for Discovery DNS will not be available outside of StackPath Edge Compute. If you need stable DNS for workload instances that are publicly resolvable, you can manually create records with StackPath DNS.
Resolv.conf
The resolv.conf file is used to configure Linux's DNS resolver. The resolv.conf file is automatically configured with the DNS nameserver used to resolve both internal Discovery DNS queries and external DNS queries. This nameserver will always be 169.254.169.254. The hostname and IP of the instance is also placed into the hosts file. The search domain of the instance will automatically be set to [stack-slug].edgeengine.internal.
search [stack-slug].edgeengine.internal nameserver 169.254.169.254 |
DNS Records
DNS Record
|
Description
|
---|---|
[instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].[root-domain] [instance-name].[stack-slug].[root-domain] |
Resolves the IP address of a workload instance |
self.metadata.[root-domain] | Resolves the IP address of the requesting workload instance |
[deployment-scope].[target-name].[workload-slug].[stack-slug].[root-domain] | Resolves a list of A records of the IP address for all healthy workload instances within a deployment scope |
[target-name].[workload-slug].[stack-slug].[root-domain] | Resolves a list of A records of the IP address for all healthy workload instances within a target |
[workload-slug].[stack-slug].[root-domain] | Resolves a list of A records of the IP address for all healthy instances of a workload |
_[port-name]._[protocol].[deployment-scope].[target-name].[workload-slug].[stack-slug].[root-domain] _[port-name]._[protocol].[target-name].[workload-slug].[stack-slug].[root-domain] _[port-name]._[protocol].[workload-slug].[stack-slug].[root-domain] |
Resolves SRV records for the named port of the instances in a workload |
Record Variables Defined
Variable | Description |
[port-name] | name given to the port in the workload spec |
[protocol] | protocol used for the port |
[instance-name] | name of the workload instance |
[deployment-scope] | name of the scope in which the instance is deployed (eg, city code) |
[target-name] | is the name of the target within the workload the instance was created for |
[workload-slug] | unique slug for the workload the instance was created for |
[stack-slug] | unique slug for the stack that the workload instance is created in |
[root-domain] | either compute.edgeengine.io to resolve public IPs or edgeengine.internal to resolve VPC IPs |
Service Discovery
SRV Records
One powerful aspect of the Discovery DNS service is its support for SRV record based service discovery. SRV records allow applications to automatically discover the hostname and port of a service running within EdgeCompute. To use SRV records, your workload must have its ports defined within the container or VM spec. The name of the port will be used as part of the DNS query.
Let's take for example that you have a workload with a container with a port named `http` set to 80. With this, a SRV DNS query can be issued within a workload to query for all instances in the workload that have a port with that name. Given a stack with the slug my-prod-stack and a workload with the slug my-app-workload, this would be an example SRV request and response if we were to have 5 workload instances in this workload.
$ dig SRV _[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal
; <<>> DiG 9.14.7 <<>> SRV _[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56318
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. IN SRV
;; ANSWER SECTION:
_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. 5 IN SRV 0 100 8080 [instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal.
_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. 5 IN SRV 0 100 8080 [instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal.
_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. 5 IN SRV 0 100 8080 [instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal.
_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. 5 IN SRV 0 100 8080 [instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal.
_[port-name]._[protocol].[workload-slug].[stack-slug].edgeengine.internal. 5 IN SRV 0 100 8080 [instance-name].[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal.
A Records
Another option for discovering workload instances is through DNS queries that return multiple A records for each workload instance in the result set. It's possible to query for a list of IPs for all instances within a workload by performing a DNS query with the workload slug and stack slug.
$ dig [workload-slug].[stack-slug].edgeengine.internal
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> [workload-slug].[stack-slug].edgeengine.internal
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4952
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;[workload-slug].[stack-slug].edgeengine.internal. IN A
;; ANSWER SECTION:
[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.4
[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.6
[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.8
[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.11
[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.7
You can also get the instances for a specific target by using the target name in the DNS query.
$ dig [target-name].[workload-slug].[stack-slug].edgeengine.internal
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> [target-name].[workload-slug].[stack-slug].edgeengine.internal
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4952
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;[target-name].[workload-slug].[stack-slug].edgeengine.internal. IN A
;; ANSWER SECTION:
[target-name].[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.4
[target-name].[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.6
You can filter that further to also get the IPs for instances running in a specific locality based on the deployment scope.
$ dig [deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> [deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4952
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal. IN A
;; ANSWER SECTION:
[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.4
[deployment-scope].[target-name].[workload-slug].[stack-slug].edgeengine.internal. 5 IN A 10.128.48.6
DNS Options
By default, all queries that return IPs for multiple instances will only contain instances that are considered healthy based on their readiness probe. This behavior can be modified through DNS request options.
These options can be added to any discovery DNS query that returns multiple instances. Multiple options on a single query are supported. Options should be added after the [stack-slug] in the query: [stack-slug].[option].edgeengine.internal
Option
|
Description
|
---|---|
o--notself | This option will exclude the calling instance IP from the resulting set |
o--notready | This option will include IPs for instances regardless of the status of its readiness probe |
o--same-deployment | This option will include IPs for instances that are within the same deployment scope |
Discovering Peers
Options allow you to modify the behavior of the DNS queries that are performed to simplify working with applications. For example, by using the o--notself option, an instance can resolve the IPs of all other instances running within the workload. As an example, here is how you would discover all instances within a workload except the requesting instance.
$ dig [workload-slug].[stack-slug].o--notself.edgeengine.internal
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> [workload-slug].[stack-slug].o--notself.edgeengine.internal
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4952
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;[workload-slug].[stack-slug].o--notself.edgeengine.internal. IN A
;; ANSWER SECTION:
[workload-slug].[stack-slug].o--notself.edgeengine.internal. 5 IN A 10.128.48.4
[workload-slug].[stack-slug].o--notself.edgeengine.internal. 5 IN A 10.128.48.6
[workload-slug].[stack-slug].o--notself.edgeengine.internal. 5 IN A 10.128.48.8
[workload-slug].[stack-slug].o--notself.edgeengine.internal. 5 IN A 10.128.48.7