‫All right.
‫Wherever you're running your Docker from, we can actually create a single node swarm for our own testing
‫purposes.
‫The way I can tell whether Swarm is on or not, I can just do a docker info and you'll notice Swarm
‫inactive.
‫So we know that Swarm hasn't been enabled here. Again, by default, Docker does not enable any of the Swarm
‫features.
‫I can run a docker swarm init for initialize. That took about a half a second and we're done.
‫What we have now is a single node swarm with all the features and functionality that we get out of the
‫box.
‫So that was probably the shortest demo of this entire course.
‫I mean, what just happened? We typed one command and magic. Wasn't actually any magic.
‫It was a lot of very quick and efficient things in the Go programming of Docker, but essentially, right
‫out of the box,
‫it does a bunch of PKI and security stuff. It creates a root certificate for the swarm that it
‫will use to establish trust and sign certificates for all nodes and all managers. It will create
‫a special certificate for this first manager node because it's a manager versus a worker.
‫Then it creates these tokens that we can actually use on other nodes to join this swarm.
‫Then a bunch of other things in the background where it enables the swarm API and creates something
‫called the Raft Consensus Database, which we'll talk about later in a production part of the course.
‫Just so you know, Raft is a protocol that actually ensures consistency across multiple nodes, and it's
‫ideal for using in the Cloud where we can't guarantee that any one thing will be available for any moment
‫in time.
‫It creates that database on disk. It stores the configuration of the swarm,
‫and that first manager, and it actually encrypts it.
‫Assuming you're on Version 1.13 or newer. Then it will wait for any other nodes before it starts actually
‫replicating the database over to them.
‫Again, all of this traffic that it would be doing once we create other nodes is all going to be encrypted.
‫One of the key components of Swarm that differentiated it when it first came out was that we didn't
‫need an additional key value storage system or some database architecture to be the backend configuration
‫management of our swarm.
‫If you've been around the industry for years or decades even, there is this concept typically of
‫the config db, which is this separate database system that you usually need to make redundant that will
‫store all the information about your orchestration and automation system. Swarm has actually built that
‫straight into Docker right into the daemon and handles it for us.
‫We never really need to do anything. There's no passwords to worry about. There's no special services
‫to start up or anything like that.
‫So, back to the command line.
‫You'll notice here that it talks about...if I want to add a worker to the swarm,
‫I just really need to cut and paste this onto the other servers I would add.
‫Later, we're actually going to build a multi node swarm, but for now, we're just going to keep this
‫at a single node. Let's take a look at a couple of the commands will get out of it.
‫First thing is we can do docker node ls. In this case, we're just seeing the one manager node
‫that we've created.
‫You'll notice it's marked as leader, and there can only be one leader at a time amongst all managers.
‫Again, since we only got one, then obviously it's the leader. We can look at help see what other
‫options we have here. Really, the nodes commands used for bringing your servers in and out of the
‫swarm, or promoting them from workers to managers, or demoting them from managers back down to workers.
‫If you go back the dockers swarm command for a little bit, we'll notice that it actually is a very narrow
‫scope to command.
‫It really is just to initialize, either join or leave.
‫The new unlock command, which we can talk about in a later lecture.
‫For now, let's focus on the exciting new Docker service command.
‫Again, service in a swarm replaces the Docker run.
‫I don't know for a fact, but I really think that this was centered around the idea that we didn't
‫want to break existing Docker run functionality, but Docker run was always built from the ground up
‫as a single host solution.
‫It's whole idea was to focus on local containers on the system that it's talking to. Whereas, when we
‫start talking about a cluster, we don't care so much about individual nodes.
‫We don't actually probably name them. We treat them like cattle, if you've ever heard of the pets
‫versus cattle analogy where they're just a number.
‫We don't really individually go to each node and start up an individual container.
‫We really just throw requirements at the swarm in the form of services and then it will orchestrate
‫how it needs to lay all that out, on which nodes they need to be,
‫and we just know that it's got our back. docker service create
‫is how we give it some new orders. Let's do something really simple.
‫Let's just actually have it start the Alpine image. Then we're going to have the Alpine image just
‫use ping to hit 8.8.8.8, which is actually a Google DNS server, but we really just want to give it something
‫to do while we investigate what happens.
‫Then you'll see like docker run, it spits back an ID, only that's not the container ID. That's actually
‫the service ID.
‫You'll see that we now have one service listed. Just like with our docker run command, since we didn't
‫name it,
‫it gave it a random name. We can see that it's actually already spun up.
‫The one of one. When you're looking at services, you're always going to see this number with a /
‫in the middle. That represents the one on the left is how many are actually running.
‫And the one on the right is how many you've specified for it to run.
‫The goal of the orchestrator is to make these numbers match, whatever that takes.
‫But this again doesn't actually show us the real container.
‫This is really just showing us a list of our services, so we can drill down a little farther.
‫We do a docker service ps, and then we give it the name or the ID of the service, and that will
‫actually show us the tasks or containers for this service. You'll see that it's similar to the docker
‫container ls command, but it actually has now this node component because when you're dealing with multi servers
‫scenarios, we might need to know which server it's actually running on. You'll notice that it actually gave
‫it a name of an increment on the service name.
‫If we went back to the docker container ls command, that still works.
‫In this case, the orchestration of Swarm is actually adding some information to the names and to the
‫actual images that are running. We'll cover some of those subtle differences later as well.
‫For now, let's actually take that service and let's scale it up. For that, we use the docker service update,
‫and then the name of our service, or the ID in this case, I'll do the ID. And I want to change an attribute
‫about the service.
‫In this case, I want to change the number of replicas.
‫So if we do a docker service ls again, we now see three of three. If we do a docker service ps,
‫we actually now see three tasks. You'll notice that two were just created seconds ago.
‫If we were fast enough, and if we were deploying something big enough, we could actually run the service
‫ls and actually see it show us zero of three. One of three.
‫It'll actually increment as things start up. It just so happens that Alpine was already on this machine,
‫in terms of its image, and it didn't take very long to start up a ping command.
‫We just couldn't be that fast.
‫What's interesting about that update command is that you can imagine the difference between the
‫Docker run command that you might use on a single dev or test server or on your local machine, and the
‫production concerns of always keeping something available
‫as much as possible.
‫That's one of the design goals of Swarm. That command that we actually haven't used yet is the Docker
‫update command. That was a command for the Docker run containers that allowed us to update certain
‫variables on our running container without having to kill it and restart it.
‫Almost all of those options are related to limiting and controlling resource usage for that container.
‫Because that's one of the typical things that you see when you're running a long term application is
‫that you need to change its resources maybe because the databases have gotten bigger and need more RAM.
‫Or maybe you have an out of control process that's eating up too much CPU and you need to limit it.
‫If we do a help on the docker service update command, you'll see that we have a lot more options.
‫Because the goal of a Swarm service is that it's able to replace containers and update changes in the
‫service without taking the entire thing down.
‫If you had a service with three containers in it, you could technically take down one at a time to
‫make a change and do sort of a rolling update, which is the blue green pattern we talked about. That's
‫why we see a lot more options here is because we can change these options that may require a container
‫restart, but the swarm will intelligently make sure that the way we update them is in a pattern that
‫ensures consistent availability.
‫So back to our docker container list real quick. You'll notice that we have these three now, and what if
‫I went in and, sort of as a rogue, did a docker container rm, and I specified one of these containers, and
‫I forced it...let's say I beat the first one and just take it out.
‫All right.
‫Now I do a docker service ls, and you see how it shows two of three?
‫Because I went in behind the back of Swarm and I actually took away a running container,
‫it's going to identify that and it's going to launch a new one within seconds to replace the one that
‫went down.
‫So if I did a docker service ps on frosty, you'll see that it actually shows the history of the
‫first task here in the list is that it had one that failed and it started a new one 24 seconds ago.
‫This is one of the responsibilities of a container orchestration system is to make sure that the
‫services you specified are always running,
‫and if they fail, it recovers from that failure. Which is way different than docker run, right? docker run would
‫never recreate a container.
‫So that's why whenever we do any of these Docker service commands, we're not actually speaking directly
‫to an action like create a container.
‫We're actually telling an orchestration system, hey put this job in your queue.
‫When you can get to it, please perform the actions on the swarm that I've asked here. That's a
‫big difference.
‫It's subtle in the command line, but it's a big difference because it means that there's rollback possibilities.
‫There's failure mitigation and a lot of intelligence built into that.
‫In this case, if I actually wanted to remove all these containers,
‫I'd have to remove the service. I'd have to do docker service rm.
‫And then the frosty.
‫If we do a docker service ls, we see nothing. If we do a docker container
‫ls, we see three containers.
‫Oh and there we go.
‫That shows right there the automation happening on the backend.
‫We were able to quickly show that we deleted the service, but the orchestration system hadn't gone through
‫all of its processes of cleaning up the service and the task behind it. These concepts should be pretty
‫easy to understand because they're just really expanding on the Docker run concepts that we've had earlier
‫in this course.
‫Next let's actually build a multi node swarm and start scaling our containers out.