‫All right, so now that we've gone through secrets and the features, and how it works and all that,
‫let's actually look at some practicals.
‫So, what I have here is, I've got our 3-node swarm set up like before.
‫I'm in a secrets
‫sample 1 directory that you'll see in the repo.
‫And, all I’ve got in there is one text file. And in that text file is just a simple username, not even actually
‫a password.
‫There's two ways we can actually create a secret inside of Swarm.
‫And one of them is to give it a file, and another one is to pass a value at the command line.
‫So, let's use the file first. docker secret create. And then I need to give it a name in the secret database.
‫And I'll call it psql user.
‫It doesn't have to be the same name as the file, obviously. But I'm just going to call it that.
‫And then... It spits back the ID, like it does for other objects. And lets create another one. Let’s actually
‫put the password in.
‫And this time we're actually going to echo it from the command line.
‫If you see what I'm doing, I'm actually typing out a password in the command line with echo, and echoing
‫it in into the creation command.
‫And notice the dash on the end, because that's telling the command to read from the standard input. Which
‫is what we're giving it with the echo command.
‫Now, I should say that both of these have drawbacks.
‫The first one, you're actually storing the password on the hard drive of the server on the host.
‫And we really wouldn't want to do that.
‫So, maybe you would be using the remote API from that local command line on your machine. And then pass
‫in the files that way.
‫And, in the second one, it's actually going into the history of our Bash file for our root user.
‫So then technically, if someone were able to get into root, they could actually get this password out.
‫When you're dealing with your own production systems, you'll need to look at various ways to get around
‫these two potential security concerns.
‫So, what we have here is...now, if I do a docker secrets ls, you can see that I have both of them in there.
‫Now, I can actually inspect them, but I'm not going to ever see the passwords or the actual secret.
‫So, let me just do the user.
‫It's not going to give us the information, right. Because if it was this easy to get the information it
‫wouldn't really be that secret.
‫Right?
‫So, the goal here, is that once you put the secret in the system, it's stored in the database. And the only
‫thing that's going to have access to the decrypted secrets are going to be the containers and services
‫we assign it to.
‫So let's do that now.
‫I'm going to create a service manually.
‫docker service create. I’ll call it psql. And we're going to map the secret to it. Basically, we're telling this
‫create command take this secret called this particular name...
‫I can also use the ID of the secret... and assign it to this service, so that all containers in this service
‫will see this secret.
‫All right.
‫And then put the user in there, and then I’ve got to do it again for password.
‫Okay.
‫So this maps the secrets to the service, so that they show up as files inside the container.
‫But it doesn't tell the postgres database that we're creating from this image
‫how to use those secrets.
‫So, usually, we need to do something with the configuration of the image.
‫And in this case, the official images from Docker Hub have settled on a standard where you use environment
‫variables. But, instead of passing in maybe something like postgres password, that would be hard to use
‫with a file.
‫We'd have to actually, like, cat out the file into the environment variable and that's a little bit of
‫a pain.
‫So, they have the standard where, if you specify a file...and this would be the path...so it would be run secrets,
‫and then the name, right? So psql pass, the name of the secret.
‫If I do that, that's actually in the startup of the image that will look for this environment variable
‫being filled out.
‫And if it is, it will then pull that file in, and store it in the environment variable. The actual contents
‫of that file.
‫This is this is a really easy way to consume these secrets that are in the files.
‫But it does mean that the images you use need to have this standard in place.
‫We can also do the same thing for the user.
‫...
‫Hopefully, this makes sense to you. When I create the service
‫it's going to do the typical thing it does when it issues a scheduling request for a new container.
‫It's going to create one Postgres database and it's going to pass it
‫the environment variables for the locations of those two secrets.
‫And then it's going to map, in a tempfs, it's actually going to map in what look like files.
‫But again, it's really just a RAM file system or a tmpfs.
‫Let's go see what we can see in there.
‫So, I do a docker service ps psql, and that should tell us what node it's running on.
‫Okay, it's running on this node.
‫Let's do an exec to see what we can see inside the container.
‫docker exec -it.
‫And then the specific container name for that service, and then bash.
‫All right.
‫Now we should be able to do an ls on run secrets, and you'll see we get the two files there.
‫And if I do a cat on psql user, we see the value. It worked.
‫And if we look at the logs of that psql, we actually know it works. Because if it didn’t...if it
‫didn't have those files, the actual database would keep recreating itself, and not be able to work because
‫it didn't have a password and a user name to create the database.
‫If you did docker service ps again, what you would see if it wasn't working correctly in a database
‫scenario, is the database would actually be failing. And it would keep restarting and you would see new
‫containers being created here.
‫So now that we've actually assigned it to there, we can actually use a docker service update to remove
‫the secret. So, docker service update --secret-rm.
‫There's also secret-add. But if I removed one of these secrets what would actually happen is, it
‫would redeploy the container. Because secrets are a part of the immutable design of services.
‫If anything in the container has to change for the service, the service will not go in and change something
‫inside the container. It will actually stop the container and redeploy a new one.
‫Obviously, that's not ideal for databases. So we're going to have to come up with a different plan for
‫how we would update database passwords.
‫And that's something we can talk about later.
‫For now, I just want you to know that you can remove them and add additional ones to an existing service.
‫It's just going to recreate the container when you do it.