‫So that little bit of magic wasn't actually magic. It was the Routing Mesh. The Routing Mesh is
‫an incoming or ingress network that distributes packets for our service to the tasks for that service,
‫because we can have more than one task.
‫This actually spans all the nodes, and it's using Kernel primitives that have been around a while
‫actually called IPVS.
‫...
‫So we're not talking about some fancy new service. We're really just talking about the core features
‫of the Linux Kernel. What it's really doing here is it's load balancing across all the nodes and
‫listening on all the nodes for traffic.
‫There's a couple of ways we can talk about how this works.
‫The first example is from one container to another.
‫If our backend system, like say the databases, were increased to two replicas, the frontends talking
‫to the backends,
‫wouldn't actually talk directly to their IP address.
‫They would actually talk to something called a VIP, or a Virtual IP, that Swarm puts in front of all
‫services.
‫This is a private IP inside the virtual networking of Swarm, and it ensures that the load is distributed
‫amongst all the tasks for a service.
‫So if you can imagine if you had a worker role in your application, and it had 10 different containers,
‫you don't have to put a load balancer in front of that.
‫This does that for you.
‫When you're talking about traffic from one service inside your virtual network talking to another service
‫inside your virtual network.
‫And the second example of how the routing mesh works is external traffic coming into your swarm can
‫actually choose to hit any of the nodes in your swarm.
‫Any of the worker nodes are going to have that published port open and listening for that container's
‫traffic, and then it will reroute that traffic to the proper container based on its load balancing.
‫What this means is when you're deploying containers in a swarm, you're not supposed to have to care about
‫what server it's on because that might move, right?
‫If a container fails, and the task is recreated by the swarm, it might put that on a different node. And
‫you certainly don't want to have to change your firewall around or your DNS settings to make that container
‫work again.
‫The routing mesh solves a lot of those problems by allowing our Drupal website on port 80 to be
‫accessible from any node in the swarm. And in the background, it's taking those packets from that server
‫and then routing them to the container. If it's on a different node, in it'll route it over the virtual
‫networks.
‫If it's on the same node, it'll just reroute it to the port of that container.
‫And we didn't have to do anything to enable this.
‫This was all out of the box.
‫Let's see a diagram of how this might work.
‫If I created a newsform service, and I told it to have three replicas. And it created three tasks, with
‫three containers, on three nodes. Inside that overlay network, it's actually creating a virtual IP that's
‫mapped to the DNS name of the service, right? And the service, by default, the DNS name, is the name of the
‫service.
‫In this case, I created a service called my-web, and any other containers I have in my overlay
‫networks that need to talk to that service inside the swarm,
‫they only have to worry about using the my web DNS. The virtual IP properly load bounces the traffic
‫amongst all the tasks in that service.
‫This isn't actually DNS Round Robin. That's actually a slightly different configuration. We could
‫enable that if we wanted to. There's actually an option to use DNS Round Robin.
‫The benefits of VIPs over Round Robin is that a lot of times our DNS caches inside our apps prevent
‫us from properly distributing the load.
‫Rather than fight with our DNS clients in DNS configuration, we're just relying on the VIP, which is
‫kind of like what you would have if you bought a dedicated hardware load balancer.
‫In the second example, this is actually showing what it would be like with external traffic coming
‫in.
‫This is similar to what we just did with Drupal, where when I created those yellow boxes, by creating
‫one service, called my web, and it created two tasks, and applied them to two different nodes, each one of
‫those nodes has a built-in load balancer on the external IP address. For me, because I'm using DigitalOcean,
‫that IP address is the one that DigitalOcean gave me. When I use the -p and published
‫it on a port, in this example it's using port 80:80, any traffic that comes in to any of these three nodes
‫hits that load balancer on port 80:80. The load balancer decides which container should get the traffic
‫and whether or not that traffic is on the local node, or it needs to send the traffic over the
‫network to a different node.
‫Again, this actually all happens in the background without any special effort on our part.
‫All right. Let's see this Routing Mesh in action.
‫We already saw the example with Drupal and how it listens on all three nodes.
‫But what if we had multiple tasks that see that load balancer working.
‫If we do a docker service create,
‫what we're going to do is, we're going to use an Elasticsearch container. We're going to call it search and
‫give it three replicas. And want to publish it on port 9200, which is its default port.
‫In this case, we definitely want the :2 in there because it's the easiest version to deploy
‫right now. While that's creating,
‫I'll just mention that Elasticsearch is actually a search database that's accessible via a JSON web
‫API.
‫So it's really easy to hit with curl and give us good examples of how this works.
‫I do a docker service ps search, we can see that it's smartly created each task on a different node.
‫If I just do a curl on my localhost, on node one on port 9200 because I published that port,
‫I'll get back the Elasticsearch basic information. Part of that is it will actually create a random
‫name.
‫That's just a feature out of Elasticsearch.
‫If I curl this multiple times, you'll see on this one it's Patch, the Patch server, and then a third
‫time,
‫Jane Foster, and then it'll start repeating itself like such.
‫That's actually the virtual IP acting as a load balancer and distributing my load across the three
‫tasks.
‫A few more notes on the routing mesh. In 17.03, which is the release that I'm showing you this on, the
‫routing mesh and the load balancing are currently a stateless load balancer.
‫If you've ever dealt with State inside of maybe Amazon's classic load balancer, or other load balancer
‫technologies, you know what this is about.
‫This is basically saying that if you have to use session cookies on your application, or it expects a
‫consistent container to be talking to a consistent client, then you may need to add some other things
‫to help solve that problem.
‫Out of the box, every time you hit a service with multiple tasks, it's going to give you potentially
‫a different result.
‫Also, if you get into the details of this, it's actually a layer-3 load balancer, and that actually
‫operates at the IP and port layer.
‫It doesn't actually operate at the DNS layer.
‫If you've ever run multiple websites on the same port, on the same server, this isn't going to do that
‫yet.
‫You're still going to need another piece of the puzzle
‫on top of that if you're actually wanting to run multiple websites on the same port, on the same swarm.
‫Luckily, that's a pretty common request, and there's several options you can do to solve both of these
‫problems.
‫One of them is to use Nginx or HAProxy, which there are pretty good examples out there of containers
‫that will sit in front with your routing mesh, and actually act as a stateful load balancer or a layer
‫for load balancer, that can also do caching and lots of other things. If you need that, you might want
‫to check some of those out in the resources of this section.
‫I should also mention that if you were to pay for a subscription of Docker Enterprise edition, with
‫it comes something called UCP or Docker Data Center, which is a web interface. But I should mention that
‫Docker Enterprise edition, if you get a subscription to that for your swarm nodes, it actually comes with
‫a built-in layer for web proxy that allows you to just throw DNS names in the web config of your swarm
‫services and everything just works.