‫One of the big promises of containers is that we can easily deploy our apps like we were a platform
‫service, you know, like Heroku or something. We can do that on anyone's hardware, whether it's on our
‫hardware, it's a cloud provider, whether it's virtual or physical. With Docker, our apps can run
‫the same whether they're an Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud or whatever. Without
‫all those platform features, how do we easily deploy and maintain our dozens, or hundreds, or even thousands
‫of containers across many servers or instances? Or nodes or droplets or whatever.
‫That brings to bear some really new problems that weren't previously problems for small organizations.
‫We all know about Netflix and big organizations like that that scale to thousands and thousands
‫of nodes, and tens of thousands of nodes, and they've got lots of engineers.
‫But, if you have just a couple of people on your team, or if you're just a solo developer, how do you take
‫your containers and scale them and deal with their entire life cycle? From deploying them, to starting
‫them, to restarting them, to recreating them, to deleting them and updating them and all that.
‫We start to ask questions around how exactly does Docker do that or does it even do that at all?
‫Some of the questions we ask ourselves are things like, how do we scale out? How do we scale up? How do
‫we ensure that our containers restart if they fail?
‫How do we replace those containers when we actually have an update for them? Which is something called
‫blue green deploy nowadays, which means that you have zero downtime and you take servers out of the pool
‫in order to bring new ones in. You end up with always something available so that you're never really
‫down when you update. How do we know if we've got dozens of nodes or even just three nodes where we
‫started those containers? Which node is our container on? How do we talk across those different nodes
‫or servers with our networking inside the containers?
‫When it comes to security, how do we be sure that our containers are only running on the machines
‫that we intended for them to run on?
‫Now that we're moving things around and deploying them dynamically on the fly, how do we store the
‫private information we need for our containers, like secrets or passwords?
‫So this brings us to a major evolution in the scope of what Docker tries to solve.
‫When people talk to me and they think that Docker is just a container runtime, that's when I actually
‫just mention Swarm Mode, which is a brand new feature in 2016 that brings together years of understanding
‫the needs of containers and how to actually run them live in production.
‫So at its core, Swarm is actually a server clustering solution that brings together different operating
‫systems or hosts,
‫or nodes, or whatever you want to call them, into a single manageable unit that you can then orchestrate the lifecycle
‫of your containers in. Just to be clear, we're not actually talking about Swarm, which I'm going to
‫call Swarm Classic, which was an add-on component to Docker before 1.12 came out. It was really a container
‫that would run inside of Docker,
‫that really just took your Docker run commands and repeated them out to multiple servers.
‫It did solve a few problems, but it wasn't really at the scale that we needed to truly solve 80%
‫of the cases for how you're going to run your containers.
‫In the summer of 2016,
‫at dockercon 2016, actually Docker announced Swarm Kit, which was a set of libraries or a tool kit related
‫around a whole bunch of new Swarm features.
‫Then they stuck that right in the Docker server. All along in this course, you've actually had the
‫features available to you in the CLI and on your server.
‫Now we finally get to dive into them.
‫In January of 2017, 1.13 came out, and of course because Swarm Mode was new
‫in 2016, they're going to continue to make it better in the years to come.
‫In January, they added additional features called Stacks and Secrets, as well as other bonuses
‫we'll talk about later. It's important to note that Swarm is not actually enabled out of the box.
‫In fact, on your machine, you couldn't use these commands listed here right now. That would actually give
‫you an error because Swarm has to be enabled.
‫That was one of the design goals was that none of the Swarm code would affect the existing Docker
‫daemon, and that all the tools and systems out there that were already relying on Docker, or maybe they
‫had their own orchestration on top of Docker, would continue to function and not be interfered with by
‫Swarm
‫now being a part of Docker. Some really basic concepts before we start diving in, is that these blue
‫boxes you see over the top are what we call Manager Nodes, and they actually have a database locally
‫on them known as the Raft Database.
‫It stores their configuration and gives them all the information they need to have to be the authority
‫inside a swarm.
‫So what we have here is three different managers that have all been added to the swarm, and they
‫all keep a copy of that database and encrypt their traffic in order to ensure integrity and guarantee
‫the trust that they're able to manage this swarm securely.
‫Below in the green, we actually have worker notes. Now you can see in the concept of Swarm, we
‫have now managers and workers.
‫Each one of these would be a virtual machine, or a physical host, running some distribution of Linux or
‫Windows server.
‫This is showing how they're actually all communicating over what we call the Control Plane, which is
‫how orders get sent around the swarm, partaking actions. In a little bit more complicated view,
‫we have this Raft consensus database I mentioned, that is replicated again amongst all the nodes.
‫They issue orders down to the workers.
‫The managers themselves can also be workers. Of course, you can demote and promote workers and
‫managers into the two different roles.
‫When you think of a manager, typically think of a worker with permissions to control the swarm.
‫Again, the only requirements for each one of these servers is that they're running the same Docker
‫that you're already using now. With this concept of a swarm, and these managers, we now have new concepts
‫of what our containers look like.
‫So, with the Docker run command, we could only really deploy one container.
‫It would just create a container.
‫It was always on whatever machine the Docker CLI was talking to.
‫That's usually your local machine, or maybe a server they are logged into. That Docker run command didn't
‫have concepts around how to scale out or scale up.
‫So we needed new commands to deal with that.
‫That's where the Docker service command comes from. In a swarm,
‫it replaces the Docker run command, and allows us to add extra features to our container when we run
‫it, such as replicas to tell us how many of those it wants to run.
‫Those are known as tasks.
‫A single service can have multiple tasks, and each one of those tasks will launch a container.
‫In this example, we've created a service using docker service create to spin up an Nginx service
‫using the Nginx image like we've done several times before.
‫But we've told it that we'd like three replicas.
‫So it will use the manager nodes to decide where in the swarm to place those. By default, it tries
‫to spread them out.
‫Each node would get its own copy of the Nginx container up to the three replicas that we told
‫it we needed.
‫This is a quick and basic understanding of how the managers work and what they're doing in the background.
‫All these features are new.
‫It's not simply just taking your command and running it on an API like we would experience with a Docker
‫run command.
‫There's actually a totally new Swarm API here that has a bunch of background services, such as the scheduler,
‫and the dispatcher, and the allocator and orchestrator, that help make decisions around what the workers
‫should be executing at any given moment.
‫So the workers are constantly reporting in to the managers and asking for new work.
‫The managers are constantly doling out new work and evaluating what you've told them to do against what
‫they're actually doing.
‫Then if there's any reconciliation to happen, they will make those changes, such as maybe you told it
‫to spin up three more replicate tasks in that service.
‫So the orchestrator will realize that and then issue orders down to the workers and so on.
‫With this Swarm Mode, we actually get a feature-packed set of capabilities out of the box that allow
‫us to already use the existing Docker skills we have in order to deploy our containers to the Internet
‫in a reliable fashion, and solve a lot of problems that we would have
‫once we go production.