Imagine an application fronted by Nginx. Multiple Nginx containers terminate SSL and load balance among multiple upstream applications. Each Nginx instance shares the same tag and Triton CNS address record. The tag can be added using the
triton CLI tools, as well as in the Triton Compute Service portal. Those Nginx containers will be globally findable using the following DNS FQDN:
<service name>.svc.<account uuid>.<data center name>.triton.zone
Web browsers can go to the generated hostname, but it’s easier to CNAME a convenient domain name. In BIND DNS, that would look like the following:
<my domain name> IN CNAME <service name>.svc.<account uuid>.<data center name>.triton.zone.
And here's what it looks like in CloudFlare DNS:
Requests to those DNS domain names will be sent to one of the Nginx containers at the front of the app. Triton CNS, in this case, makes it easy to globally discover my application.
As we scale the number of Nginx instances up and down with demand, or replace instances as I update them, the new IPs of those instances will be reflected in the address records returned by Triton CNS.
Triton CNS’ automated DNS services make it easy for users to find the application, even as the specific instances hosting that application change. This makes it easy to build highly available and highly performant applications with no additional charges beyond the application infrastructure.
While Triton CNS may not be a good fit for interconnecting all parts of an application (see caveats), it’s ideal for bootstrapping application components. Watch for an upcoming update in our blueprint for launching an HA raft of Consul instances as one example, but it also makes it very easy to link all application components to that Consul raft.
Inside the data center, instances that don’t have public network interfaces can be found in private DNS using:
<service name>.svc.<account uuid>.<data center name>.cns.joyent.com