‫Now that you understand the basics of creating a multi-node swarm and creating overlay networks and
‫Docker services, we're going to cover the next really cool thing about Swarm, which is stacks. Not stacks of
‫pancakes, but stacks of services. In 1.13, Docker added this really great feature that adds another
‫layer of abstraction on top of stacks. Basically it's Compose files for production of Swarm. Now
‫stacks accept Compose files.
‫Inside there is what we would call a declarative definition, where we're stating this is what I want
‫the end result to be.
‫And it's the swarm's job to figure all that out. Now it's not just services; it's networks and volumes
‫as well.
‫And a little sneak peek.
‫It's actually going to include secrets, which we'll talk about in the next few lectures.
‫We get to use a new command, which is docker stack deploy to import this Compose file and run the command
‫that we put in it.
‫The stack manages all of this.
‫It doesn't need us to go and first create networks, or first create volumes, but we can totally do that.
‫We can use something called External in our Compose file to say hey, these are already things that exist
‫in my swarm. Go ahead and use those, don't bother creating them.
‫But usually you end up having your stacks just doing it all for you because it's easier that way.
‫We're going to get some new features in our Compose file, so we're going to start with the ones that
‫look very similar to what we had before. But we're going to get this new deployed key in there, or dictionary,
‫that allows us to specify the things that are specific to Swarm.
‫How many replicas do we want?
‫What do we want to do when we failover? How do we want to do rolling updates, and all those sorts of
‫things that we wouldn't care about on our local development machine.
‫But that comes at a price, which is, that we can't do the build command yet. That may be something
‫that will never happen in Swarm because the mindset here is that building shouldn't happen on your production
‫swarm. Building is something that your CI system should do.
‫Maybe Jenkins or something else like Codeship.
‫Once you built your images and put them in your repository, this stack will actually be the one
‫to pull down those images and deploy them with the deploy options.
‫The good news there, though, is that they actually get along.
‫On your local machine, Compose will actually ignore when you run the docker-compose command.
‫It will actually
‫ignore any of the deploy information. It will actually say 'hey, you've got deploy information in here.
‫I can't really use it so I'm going to ignore it.'
‫Likewise, when you're on Swarm and you're deploying a new stack or an update to a stack, it'll actually say
‫'hey, you've got build commands in here.
‫I don't do builds so I'm going to ignore them and keep going.'
‫The nice thing is you don't have to change your file. We'll see later how we can actually have
‫a single Compose file that does everything that we need it to do on the development side and on the
‫production deployment side.
‫It's pretty cool.
‫Finally, you don't actually need the Docker Compose CLI, the binary. That doesn't need to be in
‫your swarm. Because again compose, the actual command, is not a production tool.
‫It wasn't designed to be production.
‫It was designed to be a developer and sysadmin helper tool.
‫It's really best for local work on our machines.
‫The swarm, which is basically the Docker Engine. The Docker Engine now can accept Compose files using
‫that stack command. It reads the Compose files without needing Docker Compose anywhere on the server.
‫Let's review real quick when we look back at our services.
‫This is what our service would look like.
‫We would create a service...
‫let's say it's Nginx. And let's say we specified three replicas of it.
‫So, it would then go and create three tasks in the orchestrator, and those tasks would find certain servers,
‫or nodes, to put them on and they would create containers.
‫In the new stacks, we're talking about multiple services, one or more, right. You can have dozens of
‫services in there. In that single YAML file.
‫They act just like the services that we had before, only now we get to do volumes and overlay networks
‫in that Compose file. And that results
‫in what we would call a stack. A stack controls all those things.
‫And it actually will put its name properly on all the objects so that you can easily tell which ones
‫are related to which stack. It'll actually put labels in there as well, which we'll cover later, which is
‫more metadata for you to be able to determine what stack this particular thing came from.
‫So this is really great.
‫We now get to use a YAML file to actually do all those things we didn't want to have to type in the
‫service commands. Because the service commands were already kind of getting unwieldy and long. And then
‫we ended up making Bash scripts in order to run those commands, and then it just got tedious, right.
‫So, now that we've had Swarm around for eight months, we now get this stack feature that manages
‫those services.
‫Notice that the stack is only for one swarm.
‫Right? It can't do many swarms.
‫It's only going to be running on one swarm so that it can control all the nodes and deploy all these
‫services, networks and volumes.
‫I should say that this diagram can actually have one more thing in it, which is secrets, because the
‫stack can control those as well. We'll see that in a later lecture in this section. OK.
‫Let's look at the stacks and how they work.
‫I'm back in my 3-node swarm that we built earlier. I'm going to maximize the window on node1
‫because I don't really need the other two nodes.
‫At least I don't need their ssh command line.
‫We're going to use the voting app example we did in previous lectures for this section.
‫If you remember our design for that, it was five different services, and they all had dependencies on
‫each other.
‫And it ultimately gave us two different websites.
‫You went through and I'm sure you crafted the best services list with all the values and options that
‫it needed and it was perfect, right?
‫I'm here to tell you that now, that is no longer needed.
‫It was really important for us to use them and not everything is going to need a stack file.
‫But now I have a stack file.
‫Let's just take a peek at it real quick because you'll notice that it looks very much like a Compose
‫file because it is. The only real key thing you have to change as it has to be at least version 3 or
‫higher.
‫The latest version right now is version 3.1, but I'm sure that will change as it continues
‫to change and mature.
‫But you need version 3 in order to use stacks.
‫You'll notice that we have our redis, and our db, and our vote, and all these things that are probably
‫very similar to you from your own work. You're probably very familiar with those and the images they
‫need, and the ports they need open and all that.
‫But in this case, you'll notice deploy.
‫Deploy here is a new option. You'll see here that I was specifying how many replicas I want, which is how many
‫copies of that image that need to run at a time.
‫And what happens when I do an update.
‫So when I do an actual stack update, which will then do service updates.
‫How do I want that to roll out?
‫Right?
‫Do I want to all go down at the same time? Do I only want one at a time?
‫How much delay between them?
‫There's all sorts of options here.
‫We're just kind of scratching the surface, but you can see like I have a restart policy here that if
‫the container fails, automatically restart it.
‫You can see down here under the database,
‫I've actually had constraints put in to make sure that it's on a specific node.
‫We haven't talked really a lot about constraints yet, but there are ways for us to label objects, that
‫is, containers or images or really anything that we can create or destroy in Swarm or in Docker itself.
‫We can actually assign labels to any of those, including nodes, and a node that is a manager gets its
‫own labels.
‫This is very easy for us to do to just say, hey, this container has to run on a node that has this
‫particular role.
‫Great example there. As we scroll down we've got some parallelism options which we've seen before.
‫This delay option is pretty cool. If you have sort of a warm up time when you have containers that spin
‫up. Maybe they've started but they don't actually go live for maybe 60 seconds or something.
‫You can add in delays there. We'll actually look at those later during production
‫blue-green deployments. For now, you can see those are all pretty standard.
‫We've actually got even more options down here. You can actually see that I assign this a specific label.
‫I have a window and a max attempt for restart policy.
‫So if it tries to restart, and it continues to fail, it's not going to try more than three times.
‫Let's check it out.
‫All I've got to do is do a docker stack deploy -c for compose. So I'm going to use a Compose file.
‫Now I'm going to call it voteapp. And there we go. It didn't actually create everything and spin it up
‫that fast.
‫All it did was create those objects in the scheduler, which will then go through the process of creating
‫the services, which then create the tasks, which then create the containers.
‫It also has to create the networks as you'll see here. Remember we had the frontend and the backend
‫so it created those, as well as a default network, which that particular stack file that I had was using
‫a default network.
‫And then you'll see this option for visualizer which is a new one we did not use before.
‫We'll see that in a minute.
‫So let's take a look at the docker stack command a little more.
‫You'll see that we can deploy. We've done that already.
‫Then we have an
‫ls, a ps, an rm, and services.
‫So this command doesn't have a whole lot of features to it.
‫It's pretty simple because all of the functionality is really in the Compose file and really in the
‫objects it's creating.
‫Since we've done all that already, we can do things like ls, which just shows us all of our stacks.
‫It's a pretty basic command. We only have the one. Then if I do a ps, it actually shows me...oops
‫I've got to specify the name.
‫vote.
‫It's called voteapp.
‫Got to get that right.
‫OK.
‫Let me back that up so that you can see that a little better. Right there.
‫These are the actual tasks. Then you can see which node they're running on.
‫It's not actually the containers. It's actually the task that we're seeing here. Because if it was the
‫actual container, we would see a big, long name. Because if you remember, the services we created earlier, they
‫had these really long names
‫if we actually went and did it docker ps. Right? If I did a docker container
‫ls, or a docker ps, you get these really long names. And that's because they all get a GUID, because every
‫container's got to be uniquely named.
‫So that's how they guarantee that they're always unique and never collide.
‫Then the last one here is docker stack
‫services voteapp.
‫I like this one the best, actually, because it shows me my replicas.
‫It's kind of like doing a service
‫ls. It shows me how many replicas I have started so I know whether I've got the proper number of containers
‫already started. Then if I want to dive deeper, then I could do a docker stack
‫ps. We actually get the task names here and we see what nodes they're running on.
‫These two together actually give you a complete picture of how this entire application is running.
‫If I wanted to dive into the networking, I could do a docker network
‫ls just like we normally would do.
‫And you can see these three new overlay networks that were created for this app. And notice that the
‫app name is always at the beginning. The stack always precedes the name of the service.
‫So each stack will make sure that it's name is at the front.
‫And then let's go check it out.
‫Let me bring up my browser.
‫All right.
‫We can see them on port 5000.
‫I've got the voting site running.
‫I go to 5001.
‫I've got the results site so I can hit this and then see the result.
‫Then this new one we have is called a Visualizer.
‫It's on 8080. The Visualizer is actually a pretty neat tool for demonstration purposes.
‫That's actually made...all this is made by Docker, by the way, and these are all an open source repo that
‫you can see in the Resources section of this section.
‫So we've got different colors for each service.
‫The voteapp result is a green.
‫And then the redis is kind of a mustardy, and the vote is a pink. You can see there's two votes and there's two
‫redises.
‫It's pretty great to kind of show what happens as things move around the swarm.
‫If I actually went into my file and did a change.
‫Let's go to the voting app and let's say we want to change the replicas to five.
‫We could go and update the service. But that's kind of an AntiPattern. If we go in and type manually,
‫commands into the service, like docker service update,
‫that would mean that the next time I reapply this YAML file, it's going to overwrite those changes.
‫If you've ever done a cloud formation in AWS or any other configuration management, you know that
‫once you're using a config file like this to manage your infrastructure, you really want to always use
‫this file because it's going to be the source of truth.
‫So it probably, in production, would be some sort of file that you keep in a Git Repository that you have
‫version control on, and you control changes, and that way you can roll back changes.
‫In this case, I'm just going to change that file real quick, and we're going to run the same command, docker stack
‫deploy.
‫Notice we don't have an update. Because we're going to deploy to the same stack and it's going to recognize
‫that it's existing, and that we're going to update it based on these changes.
‫In order to update it, we've got to make sure we use the right name.
‫So it's voteapp. And then notice that it's saying updating services, but recognizes that it needs to change them.
‫Then if we go over to our visualizer, you can see that we've already got it.
‫We're just too slow today, aren't we.
‫We're not able to keep up with the swarm. We've got now five of these voting apps already running.
‫If they took a while to run and launch, we would actually see their states change in here as they came
‫online.
‫But it's a simple web app, so it's going to start up pretty quickly.
‫Okay.
‫That's stacks.
‫Now let's add on the secrets to our stacks.