‫...
‫Now that we've seen secrets with services, let's look at secrets with stacks. In this directory, I'm in
‫secrets sample two, and
‫in this directory, I have a Compose file and then two secrets stored in text files.
‫So it's the similar password and user names that we had in the previous lecture, but now we've defined
‫all this in a Compose file. We have several things different here.
‫The first thing is the version of your Compose file now has to be 3.1. In order to have secrets,
‫we have to be at the .1 release of 3.
‫So we needed to have 3 in order to use stacks, but to use stacks with secrets we need it to be 3.1 or
‫newer.
‫The second thing we'll notice is that down here at the bottom we have this root secrets key now and
‫it's where we define our secrets.
‫The two ways you can do secrets in a Compose file are either using a file for each secret, or have
‫the secrets pre-created.
‫Here we actually are just using files,
‫but what we could do is create those secrets on our own in some other method either through the CLI,
‫like you've seen, or maybe through the API directly. Then we would just instead of the file:
‫underneath it, it would just say external: and it would be the name of the secret inside the secrets
‫list.
‫We need to tell the Compose file about our secrets and where they are, and then we actually assign them
‫to the services that need them.
‫That's key because what we're really saying here is that only the container that wants our secret
‫gets our secret. If this was a complicated Compose file where we had multiple services, we may have different
‫secrets for different services.
‫We would first define all of them down the bottom and then we would assign them specifically at each
‫service.
‫I will say that this is actually considered the short form or the easy way to do the secrets under
‫a service.
‫There's actually a long form that allows you to define things like the permissions and the users that
‫are allowed to access that using standard Linux mode and user ID syntaxes.
‫So if you were running applications as a non-root user, you'd want to target these secrets to only that
‫user being able to access them.
‫But for simplicity's sake in this first example, we're just using the short form.
‫All I need to do is use that file in a standard stack deploy command. So, deploy docker-compose, and
‫we'll call this mydb. You'll see, just like before, it actually created the network first.
‫In this case, it actually created the secrets first and then created the service.
‫If I went and did a Docker secret look-up, then you'll see that the two are in there and it follows the
‫same naming convention as all other stack components, where it's always the stack name and then the name
‫of the object.
‫Just like in the previous lecture, if I jumped on the SQL server and actually looked for those files,
‫they would be there just like they were before; only now, they're managed inside our stack file.
‫The nice thing here is if I removed my stack, it also cleans up the secrets and gets rid of them. In the
‫previous example,
‫if we wanted to remove our secrets, we would have had to do a docker secret rm to actually remove each
‫one. Just as a last reminder,
‫in these examples we've been using text files on this server, and that we're talking about 3-node
‫swarm here.
‫But if you're in a production environment or really anything that's not on your local machine, you should
‫not be keeping the secrets in files or in the bash history file or any place that could possibly be
‫on that host.
‫That's kind of defeating the purpose of having the secrets in the first place. Whatever your process
‫is for getting secrets into the Swarm,
‫just know that you may need cleanup once you're done there so that you don't leave residual secrets
‫around that are easy for people to get.