Today, Joyent introduces our free, automated DNS solution, Triton Container Name Service. Triton CNS makes it easy to use consistent and predictable addresses for all Triton compute instances, including Docker containers, infrastructure containers, and hardware virtual machines. The FAQ below includes examples for using it as a global DNS or to connect application components, and for instructions on how to turn it on and off, using it via Docker, and with the Triton CLI/CloudAPI.

We built the automated DNS features of Triton CNS to solve a seemingly straightforward problem: how to direct users and clients of applications hosted in Triton to those applications as the compute instances that power them change. Historically, we'd deploy an application to one or more compute instances and point our DNS to those instances, and when we needed to update the app, we'd update the existing instances. Manual DNS was acceptable because the rate of change was slow.

But, that was then. Today, of course, the preferred method of releasing updates is to deploy the updates on new compute instances, rather than update the existing instances. Manually managing DNS for changing infrastructure quickly grows tiresome, and reliably automating it is extra work that's now unnecessary with Triton CNS. By connecting Triton compute instances to your own domain using a CNAME or DNAME, Triton CNS will automatically direct requests to the right instances, even as you roll out updates and replace those instances.

Triton CNS can be used as an alternative to virtual IP addresses or load balancers. And, unlike those solutions, Triton CNS doesn't add any latency due to NAT or proxy, so it's ideal for use in high-performance, low-latency applications. Should you need a complete load balancing solution with active/passive clustering for maximum availability, Joyent can offer that as well.

Triton CNS is a free (both zero cost and open source) feature available with all Joyent compute instances in Joyent's public cloud and in Triton-powered private data centers. We look forward to your feedback about this public preview in the sdc-discuss mail list.

Please read on for the full FAQ.

What is Triton CNS?

Triton Container Name Service (CNS) is a completely automatic, universal DNS for your containers and VMs on Triton. It is tightly integrated with Triton to eliminate complexity and simplify operations.

Triton CNS serves address records (both A and AAAA) for containers by instance name and tags. Multiple containers providing the same service can share the same tag and will be returned in the same address record. Because Triton CNS knows when containers are started or stopped, including unexpected stops, the DNS information is automatically updated and requests will be sent to running containers.

See what Triton CNS does below, and examples for global DNS, using it via Docker, and with the Triton CLI/CloudAPI.

What does Triton CNS do?

Triton CNS is designed to do two things very well:

1. Serve address records for instances by instance name (each instance gets a DNS name that just refers only to that container)
2. Serve address records for instances grouped by service label/tag (multiple instances are listed in one DNS name, depending on their availability)

When activated for an account, running instances in Joyent's Triton Cloud with public network interfaces will be available in DNS using the following FQDN patterns:

.inst...triton.zone.svc...triton.zone

When activated for an account, running instances in Joyent's Triton Cloud with private network interfaces will be available in DNS and accessible inside the data center using the following FQDN patterns:

.inst...cns.joyent.com.svc...cns.joyent.com

The FQDN base (triton.zone and cns.joyent.com in the examples above) is fully configurable when running Triton CNS in private clouds.

All the DNS names for an instance can be found in the instance details in CloudAPI, easily accessed using the triton instance get command.

What is Triton CNS not designed for?

Triton CNS is not a general purpose DNS solution, and, while it is very convenient way to interconnect application components inside a data center, there are caveats that developers and operators should be aware of.

Triton CNS can be used in conjunction with a general purpose DNS provider to provide name services using your own domain name, but cannot be directly configured by users to serve custom domain names (note that data center operators can configure their own domain names in Triton CNS).

What should I use it for?

Triton Container Name Service is ideal for making applications discoverable on the internet, and, in narrow circumstances, supporting discovery between application components inside the data center. For many use-cases, it is a convenient and free alternative to load balancers, hosted proxies, and virtual IP addresses.

Examples

• Global DNS
• Consul bootstrapping

Commands and usage

• Triton CLI
• Docker
• my.Joyent.com Triton Cloud portal

FAQ

• Can I use it for load balancing or scaling?
• Is it HA?
• When do containers appear in DNS?
• What happens when a container stops?
• Is it possible to mark an instance for maintenance?
• Can I configure my own health checks?
• Are there any caveats about using Triton CNS that I should be aware of?
• Can I use my own domain name with Triton CNS?
• How do I set my resolvers to use Triton CNS?
• What types of compute instances does it work with?
• Can I use it with existing instances?
• How do I turn it on or off?
• Can I turn it off?
• Does it interfere with DNS I’ve implemented in my application?
• Does Triton CNS serve PTR records or reverse DNS?
• Is Triton CNS IPv6 compatible?
• Does it work with Triton in my data center?
• Does it work in the Joyent public cloud?
• Is it open source?
• What if I need a solution with more features than I can get with Triton CNS?
• Triton CNS compared to ELB, Elastic IPs, and Brocade VTM (Steelapp)
• Triton CNS compared to Docker --link and Docker’s embedded DNS
• How can I find my account UUID?