Container Name Service (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 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 Triton Compute Service with public network interfaces will be available in DNS using the following FQDN patterns:

<instance name>.inst.<account uuid>.<data center name>.triton.zone
<service name>.svc.<account uuid>.<data center name>.triton.zone

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

<instance name>.inst.<account uuid>.<data center name>.cns.mnx.io
<service name>.svc.<account uuid>.<data center name>.cns.mnx.io

The FQDN base (triton.zone and cns.mnx.io 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 <instance name> 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.

Commands and usage

• Triton CLI
• Docker
• Triton Compute Service 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 MNX 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?