We typically think about cloud infrastructure in terms of compute virtualization, but what use is a virtual compute instance in the cloud if it doesn't have fast, reliable, and secure networking? Triton takes a unique approach to networking that makes it easy to securely isolate each application (as well as dev and QA instances of those applications) on its own network, while also allowing you to directly connect the application to the public internet.

This post is the first of a series in which we'll answer your questions and demonstrate how to take advantage of Triton's powerful networking features for your own applications.

What networks can my instance connect to?

Triton has core features that handle the virtualization and management of layer 2 and layer 3 networks, and both can be broken down in two basic types:

• Networks defined by the data center operator (remember, Triton is open source, so you could be using a Triton implementation that has a slightly different configuration than our Triton Cloud). These can be networks that have internet-routable IP ranges (so you can connect your applications to the public internet), or they might have a private address space that is not reachable by the public internet. These networks are typically shared by multiple customers (shared layer 2 and 3), but it's also possible for the operator to create truly isolated networks that can be used and accessed by a single user (private layer 2 and 3).

• Networks defined by the user. These networks are sometimes called overlay or VXLAN networks, and they are private to the user who creates them. These network fabrics offer a convenient way to create isolated (private layer 2 and 3) networks to securely connect the internal components of your applications. At this time, each user can create up to 1024 different networks, so you can easily create separate networks for each application, and isolate staging instances of the application on their own network separated from production.

Importantly, these networking features are available to all the instance types Triton supports, including Docker containers, infrastructure containers, and hardware VMs.

How do I find my IP address(es)?

Each instance, including Docker containers, infrastructure containers, and hardware VMs, gets one or more IP addresses on different networks. You can check the IP address(es) assigned to each instance in a number of different ways:

• The my.Joyent portal
• Triton CLI and CloudAPI
• Docker
• Inside the instance

Finding instance IP addresses using the my.Joyent portal

Sign into my.joyent.com → Compute → Instances, where you'll see a full list of all of the containers and VMs you have running on Triton Cloud.

By clicking on the name of an instance, you’ll see a summary of all of those instance details. In the first section, labeled Summary, several pieces of information will appear. Among the data, you can get the instance IP addresses.

Finding instance IP addresses using Triton CLI and CloudAPI

The Triton CLI tool is a fast and convenient way to mange infrastructure on Triton. You can get a list of your instances with triton instances, but watch the screencast for a quick overview of how to use it. To get IP addresses using Triton, run the following command:

triton instance get 

For clarity sake, when I use you can use either the instance ID or the instance name.

That command will return an abundance of information about your instance, including the image it is running, instance state, DNS names, and the instance IP(s). It will look something like this:

{    "id": "ea66e367-031b-47c4-8a56-3649becb789f",    "name": "agitated_heyrovsky",    "type": "smartmachine",    "brand": "lx",    "state": "running",    "image": "6e9f2ba8-0ec3-3b9e-86a9-c0b84f0d042a",    "ips": [        "192.168.128.30",        "72.2.114.213"    ],   [...]    "primaryIp": "72.2.114.213"}

As you can see, there are two IPs listed for this instance, and we have both an array of ips and a single primaryIp. In Triton Cloud, primaryIp is often a public IP address on your instance, but if you didn't request a public IP address (see below for how to request or not public IPs for your instance), it will typically¹ be the next most public IP address.

Pro tip #1: You can actually get the "primary" IP address when listing instances. Here are a few examples:

$ triton instances -lID                                    NAME   IMG                 BRAND   PACKAGE          STATE    FLAGS  PRIMARYIP       CREATED40ea080c-8436-4fa3-9048-16b31ab063f0  gloom  base-64-lts@15.4.1  joyent  g4-highcpu-256M  running  -      165.225.151.17  2016-05-16T19:43:58.304Z$ triton instances -o name,primaryIpNAME                     PRIMARYIPwp_nginx_1               165.225.156.123wp_nginx_2               165.225.156.48wp_mysql_1wp_mysql_2wp_mysql_3

Pro tip #2: Nobody wants to read JSON just to find an IP address. Install our this JSON-parser with npm install -g json, then you can extract the IP address from the JSON output:

triton instance get -j  | json primaryIp

Finding instance IP addresses using Docker

If you don't want to use Triton commands at all and want to stick with Docker commands, you can do that, too. However, this won't reveal all of your IP addresses, just your primaryIp:

docker inspect 

The output of that will be a long JSON collection, but the IP address will be buried inside NetworkSettings → IPAddress. Of course, you can get your list of containers (to get the name or ID) using docker ps.

If you want to get just the IP address, this will do as well:

docker inspect --format '{{ .NetworkSettings.IPAddress }}' 

Finding instance IP addresses from inside the instance

If you're inside an instance, within a shell, you can use either ifconfig -a or ip addr to show the IP address. The command in use depends on the base OS/distro.

eth0      Link encap:Ethernet  HWaddr 90:b8:d0:7d:9f:e5          inet addr:192.168.128.7  Bcast:192.168.131.255  Mask:255.255.252.0          inet6 addr: fe80::92b8:d0ff:fe7d:9fe5/10 Scope:Link          UP BROADCAST RUNNING MULTICAST  MTU:8500  Metric:1          RX packets:3 errors:0 dropped:0 overruns:0 frame:0          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1          RX bytes:138 (138.0 B)  TX bytes:1480 (1.4 KB)eth1      Link encap:Ethernet  HWaddr 90:b8:d0:20:27:06          inet addr:64.30.128.116  Bcast:64.30.129.255  Mask:255.255.254.0          inet6 addr: fe80::92b8:d0ff:fe20:2706/10 Scope:Link          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:30142 errors:0 dropped:0 overruns:0 frame:0          TX packets:13926 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1          RX bytes:42094996 (42.0 MB)  TX bytes:983433 (983.4 KB)lo        Link encap:Local Loopback          inet addr:127.0.0.1  Mask:255.0.0.0          inet6 addr: ::1/128 Scope:Host          UP LOOPBACK RUNNING MULTICAST  MTU:8232  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

In the example above, from ifconfig -a, eth0 is connected to a private overlay network and is best used for internal connections between application components. The eth1 interface is connected to the public internet with a routable public IP address, 64.30.128.116.

What are NICs and why do I have so many?

Network Interface Controllers (NICs) connect your instances to a computer network. Each of your instances has one or more NICs, each connected to particular networks. This is a key feature of network virtualization and isolation in Triton: the virtual NICs maximize performance, security, and convenience. Docker containers, for example, can be directly connected to the public internet on their own NIC, and you'll never need to worry about port collisions among multiple containers trying to use ports 80 or 443, or other common ports.

Each NIC can give you access to a different network, allowing you to create the exact network topology you need to isolate your applications while still connecting the components.

Can I connect my instances together on a private network?

You certainly can! You can choose the networks you want to connect your instance to when you create it, and add or remove network connections (NICs) while the instance is running.

By default, each instance will be connected to a private network and may also be connected to a public network. Exactly what type of private network and whether or not the instance gets a public network by default depends on the instance type, see below.

Private networks are good choices to connect the components of your application, since their isolation from the public internet and other users in the data center (for user-defined networks) can improve the security of those application components that don't have to be expose to the public. Example: databases are typically connected just to other application components in the data center and not exposed on the public internet.

What are the default networks for my instance?

• Docker

  • Defaults to your default fabric network
  • Can specify one or more different fabric networks when docker runing the container
  • NICs and networks can be added and removed after the instance is started²
  • Can get an interface and IP on the operator-defined "public" network by using the -p argument to docker run...

• Infrastructure containers and VMs

  • Defaults to the operator-defined shared private network
  • Can get one or more user-defined fabric networks at start time
  • NICs and networks can be added and removed after the instance is started²
  • Gets an interface and IP on the operator-defined "public" network by default

Triton user-defined networks (also called fabrics and overlay networks) are built using VXLAN and 802.1Q industry standards. Check out the docs.

Every account in Triton starts with a private user-defined network named "default", which is the default network for Docker containers and an optional network for other instances. To list the networks available, go to my.Joyent → Networks or use the Triton CLI command triton networks.

Your container may also be connected to a public network, reachable over the internet. The IP address the public network is given varies based on the data center. By default, all containers and VM instances are given public VNICs. Docker containers do not have a public VNIC unless you request it with the -p or -P argument to docker run....

How do get a public IP address?

Docker containers on Triton only get interfaces and IP addresses on the public internet if you request one with the -p or -P argument to docker run....

Infrastructure containers and hardware virtual machines get public IP addresses by default.

Use the instructions above to find the IP address(es) for your instances.

What if I don't want a public IP address?

Applications often have many components or services, only a small portion of which should be exposed on the public internet. You want certain components such as a load balancer and the front-end design to be easily seen by the user. However, databases and certain back-end components should most often be hidden from the public for the safety of your application.

Public IP addresses are optional in Triton. They're on by default for infrastructure containers and hardware VMs, but you can create containers without them if you want. For Docker containers, they're off by default, and you have to explicitly ask for a public IP address using the -p or -P argument in your docker run....

Can I firewall my instance?

Firewalls can help protect your instances from network attacks by blocking (or allowing) traffic based on a set of rules you can define. This can be especially valuable for protecting instances on public or shared networks. Triton Cloud Firewall makes firewall management easy. In some cases, it's even automatic!

Triton Cloud Firewall can automatically apply firewall rules based on instance tags or Docker labels, making it easy to apply or change firewall policies.

And, for Docker instances, Triton Cloud Firewall will automatically set rules that block traffic to all the ports on a public network except those specified in the -p argument in your docker run....

You can modify these rules in your terminal with triton fwrule or in my.joyent.com → Network → Firewall.

How can I get a consistent address for instances as I change them?

As you scale your application or replace or upgrade the instances, the IP addresses that you use to find it on the internet will change (don't worry, IP addresses won't change on a running instance, but as you'll get new IP addresses with each new instance). In traditional systems, you'll have to update your DNS information to point the DNS name to the correct IP addresses for your app.

Automating infrastructure without automating DNS is a pain, however, so Triton offers Container Name Service (CNS). CNS is an automated DNS to solve this exact problem. See the docs for an example of how to use it for global DNS and how to use it with:

• Triton CLI
  • Add -t triton.cns.services= to triton instance create or triton instance tag set -w triton.cns.services= to change it after creating the instance (works for Docker containers too)
• Docker:
  • Add a --label triton.cns.services= to the docker run...
• my.Joyent.com Triton Cloud portal
  • See and change the DNS settings in the instance details page and when creating an instance