Video: using Triton Container Name Service with Docker

January 17, 2017 - by Alexandra White

Triton Container Name Service (CNS) is a service that adds automatic, global DNS to your containers and VMs on Triton. Triton CNS is ideal for making applications discoverable on the internet.

If you've previously managed the process of mapping DNS names to IP numbers, you know what a hassle it can be. It's one of the reasons some servers turn into pets. And, when scaling your application up or down, you need to re-update all your DNS to IP mappings. Triton CNS knows when containers are running. DNS names are automatically updated as containers start and stop so that requests are only sent to running containers. You can learn all about how Triton CNS works by watching our introduction to Triton CNS.

Below you'll learn how to create Triton CNS-powered Docker applications and you can even watch a video of how to use Triton CNS with Docker. For more information, read about Triton CNS and Docker in our documentation.

Video: learn how to use Triton CNS with Docker

For those in need of a visual reference, this screencast will go over how to use Triton CNS with your Docker instances.

You can also read the transcript below.

Run a container with Triton CNS

Creating a new instance with Triton CNS is as simple as adding a CNS service label to docker run:

docker run -d -p 80 --label triton.cns.services=<service name> <yourusername>/<application name>

Let's break down this command step by step:

  • docker run creates a container.
  • -d detaches the container, which means it's running in the background. You can continue to run commands from outside of the container so you don't have to login to the container or start/stop it.
  • -p 80 tells Triton to use port 80. This declaration ensures your container will receive an external IP address that is reachable over the public internet.
  • --label triton.cns.services=<service name> tells Triton CNS to give your application a specific title, which will be used in the DNS string.
  • <yourusername>/<application name> is the format for a Docker Hub image that is being pulled. If you're using a different registry, it may be formatted differently.

The most important part of that command is triton.cns.services=<service name>. Use any DNS-safe name that has meaning for what the container does in your application. For example, if you were to create your personal portfolio you could use triton.cns.services=myportfolio.

Using Triton CNS with Docker Compose

Docker Compose makes it easy to start a number of Docker containers all at once. For example, the Autopilot Pattern WordPress application uses CNS for all services—Nginx, MySQL, Memcached, PHP, and others, each running in separate containers. Instead of having to use multiple docker run commands, starting the application is as easy as docker-compose up -d.

The docker-compose.yml file includes Docker labels that set the CNS service name for each of the different containers. Here's the CNS services label set for the Nginx container:

  labels:
    - triton.cns.services=nginx

That Docker Compose syntax has the same effect as setting a label with docker run as described above.

Using Triton CNS on preexisting instances

If you already have an instance up and running that you'd like to add Triton CNS power to, never fear. Run the following command:

triton instance tag set -w <instance name> triton.cns.services=<title>

Your container now has Triton CNS enabled and you can carry on to the next step.

Finding your DNS name

To find out the important details for your Triton CNS-powered instance, use docker ps to list all of your Docker containers or triton instances to list all of your instances running on Triton.

Once you know your container's name, get a list of details about your instance including CNS-generated DNS names:

triton instance get <container name>

Triton will tell you a lot of information about your instance. The last section, dns_names, lists several options:

{
    "id": "a216675d-acf9-42b4-a3bf-3079f7cfc92e",
    "name": "wordpress_nginx_1",
    "type": "smartmachine",
    [...]
    "dns_names": [
        "a216675d-acf9-42b4-a3bf-3079f7cfc92e.inst.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.cns.joyent.com",
        "wordpress-nginx-1.inst.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.cns.joyent.com",
        "nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.cns.joyent.com",
        "a216675d-acf9-42b4-a3bf-3079f7cfc92e.inst.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone",
        "spacewordpress-nginx-1.inst.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone",
        "nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone"
    ]
}

Some of the DNS names point to a public network interface (ending with .triton.zone) and some point to a private network interface (ending with .joyent.com). The DNS structure for a public Triton CNS powered instance is as follows:

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

Each DNS name structure has a different use case:

  • Names beginning with *.svc... are service names. All containers by the same user in the same data center sharing the same service tag will be part of the service name, and will be round-robin load-balanced.
  • Names beginning with *.inst... are instance names. Only one container by the same user in the same data center can have a given instance name. CNS automatically generates instance names using the container name and UUID.
  • Names ending with *.cns.joyent.com point to a private network interface for the instance or service. These names can only be used inside the Triton data center, since the IP addresses are not internet-routable.
  • Names ending with *.triton.zone point to public network interface for the instance or service. These names will only be provided if the container has a public IP address

The CNS-powered DNS name for my WordPress Nginx instance is nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone. No matter how many times I redeploy my WordPress application or you redeploy your Triton CNS powered application, Triton CNS will keep that DNS information the same and up-to-date.

Look up your DNS

It may take a while for your domain to propagate the new CNAME. You can check in on it by running dig <your DNS name>. This will reveal the record information about your domain, including where it is pointing and its TTL i.e. time to live (the timespan for which the record will be cached).

; <<>> DiG 9.8.3-P1 <<>> nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25534
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone. IN A

;; ANSWER SECTION:
nginx.svc.d9a01feb-be7d-6a32-b58d-ec4a2bf4ba7d.us-east-1.triton.zone. 29 IN A 165.225.139.145

;; Query time: 58 msec
;; SERVER: 10.32.200.16#53(10.32.200.16)
;; WHEN: Tue Jan 14 08:24:33 2017
;; MSG SIZE  rcvd: 102

We care most of all about ANSWER SECTION. This tells me that my domain has 1799 seconds left before the cache expires and is pointing to the instance IP 165.225.139.145. If I were to make changes right now to the CNS service name assigned to the instance, or if I spun up new instances with the same CNS service name, it would take at least 1799 seconds to propogate.

Where to be cautious about using DNS

DNS isn't the perfect solution for every application. DNS client problems are surprisingly common, including clients that refuse to respect TTLs and clients that don’t recognize multiple IPs in an A record. These problems are frustrating in a web browser (though modern browsers now have advanced DNS implementations that avoid these problems), but they can lead to applications failures when they occur inside the data center between the components of an application.

One way around those problems is using active discovery where possible. If you can't modify your app or runtime environment to ensure good DNS client behavior, then you should consider using an alternative to DNS for discovery of application components. ContainerPilot automates the processes of service registration, health checking, and discovery for this purpose.

Video transcript

Welcome to this tutorial for using Triton CNS with Docker. To learn more about Container Name Service, watch our introduction to Triton CNS video.

Triton CNS works hand-in-hand with your Docker instances on Triton. It can be added to any application, whether it’s made of a single service or many different services, and makes DNS mapping simple.

There are three ways to implement Triton CNS with Docker: set a tag to an existing instance with triton instance tag label; add a label to docker run -d --label at the start of a container; or add Triton CNS to the Docker Compose file within your application. Docker Compose allows you to start and scale many containers with a consistent configuration, instead of running individual docker run commands.

To get started, be sure Triton CNS is enabled with the triton account command. To add Triton CNS to a pre-existing Docker container, add a Triton CNS service name with triton instance tag set to any existing instance. You can check the DNS name by running triton instance get with your container’s name or ID.

Your container’s DNS name will contain your CNS service name, your account ID number, the data center name, and various other bits of information. You can investigate your DNS name further to see which IP address is behind it at any given moment. Check the IP address by running dig.

When you want to start a new Docker container, you’ll be adding a label to your docker run command. The CNS service name will form the DNS name which follow your service, no matter how many times you scale up or down or redeploy containers spun up from that service. If you give your Nginx container the CNS service name hellonginx, that means the automatically generated domain name for your application will begin with hellonginx.

When you scale up services either with multiple docker run commands with the same image and configuration or with docker-compose scale, the additional instances will carry the same CNS service name as the original service and therefore have the same DNS name.

Check the IP address associated with your hellonginx DNS name by running dig.

If you’re creating a new application, it’s simple to add Triton CNS to your Docker Compose configuration file. This is the easiest way to consistently execute numerous Docker commands.

Docker Compose makes it easy to start a number of Docker containers all at once. We’ve implemented it for our Autopilot Pattern WordPress application to make starting WordPress services as easy as docker-compose up. The docker-compose.yml file includes labels that set the CNS service name for each of the different containers.

That Docker Compose syntax has the same effect as setting a CNS service name with docker run.

Once you’ve added Triton CNS to your Docker container, you can scale up and down without thinking twice about DNS management. For a larger applications, like WordPress, the DNS names for each of your services will remain the same no matter how many instances of each service exist.

Run triton instance get on your scaled services. For wordpress_nginx_1, I can see that the DNS name starts with nginx. It’s the same for wordpress_nginx_2 and any future scaled up instances. No matter how many times I deploy or redeploy this application, the DNS names will remain the same.

If you have multiple instances, multiple A records will be reflected when you dig the DNS name.

Using Triton CNS with Docker is easy to do, be it with a new or pre-existing application. Make DNS management, scalability, and application updates hassle free.