1 00:00:05,090 --> 00:00:05,420 ‫... 2 00:00:05,420 --> 00:00:12,800 ‫Now that we've seen secrets with services, let's look at secrets with stacks. In this directory, I'm in 3 00:00:12,810 --> 00:00:14,300 ‫secrets sample two, and 4 00:00:14,420 --> 00:00:21,650 ‫in this directory, I have a Compose file and then two secrets stored in text files. 5 00:00:21,680 --> 00:00:27,110 ‫So it's the similar password and user names that we had in the previous lecture, but now we've defined 6 00:00:27,110 --> 00:00:31,670 ‫all this in a Compose file. We have several things different here. 7 00:00:31,690 --> 00:00:37,630 ‫The first thing is the version of your Compose file now has to be 3.1. In order to have secrets, 8 00:00:37,690 --> 00:00:40,790 ‫we have to be at the .1 release of 3. 9 00:00:40,990 --> 00:00:47,170 ‫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 10 00:00:47,170 --> 00:00:48,240 ‫newer. 11 00:00:48,250 --> 00:00:54,520 ‫The second thing we'll notice is that down here at the bottom we have this root secrets key now and 12 00:00:54,640 --> 00:00:56,350 ‫it's where we define our secrets. 13 00:00:56,350 --> 00:01:04,930 ‫The two ways you can do secrets in a Compose file are either using a file for each secret, or have 14 00:01:04,930 --> 00:01:08,140 ‫the secrets pre-created. 15 00:01:08,210 --> 00:01:10,870 ‫Here we actually are just using files, 16 00:01:10,970 --> 00:01:16,280 ‫but what we could do is create those secrets on our own in some other method either through the CLI, 17 00:01:16,280 --> 00:01:22,190 ‫like you've seen, or maybe through the API directly. Then we would just instead of the file: 18 00:01:22,250 --> 00:01:29,300 ‫underneath it, it would just say external: and it would be the name of the secret inside the secrets 19 00:01:29,300 --> 00:01:29,960 ‫list. 20 00:01:30,230 --> 00:01:35,720 ‫We need to tell the Compose file about our secrets and where they are, and then we actually assign them 21 00:01:35,810 --> 00:01:37,480 ‫to the services that need them. 22 00:01:37,520 --> 00:01:43,040 ‫That's key because what we're really saying here is that only the container that wants our secret 23 00:01:43,040 --> 00:01:48,650 ‫gets our secret. If this was a complicated Compose file where we had multiple services, we may have different 24 00:01:48,650 --> 00:01:49,970 ‫secrets for different services. 25 00:01:49,970 --> 00:01:54,380 ‫We would first define all of them down the bottom and then we would assign them specifically at each 26 00:01:54,440 --> 00:01:55,520 ‫service. 27 00:01:55,520 --> 00:01:59,960 ‫I will say that this is actually considered the short form or the easy way to do the secrets under 28 00:01:59,960 --> 00:02:00,650 ‫a service. 29 00:02:00,650 --> 00:02:07,100 ‫There's actually a long form that allows you to define things like the permissions and the users that 30 00:02:07,100 --> 00:02:12,820 ‫are allowed to access that using standard Linux mode and user ID syntaxes. 31 00:02:13,010 --> 00:02:18,980 ‫So if you were running applications as a non-root user, you'd want to target these secrets to only that 32 00:02:19,010 --> 00:02:20,840 ‫user being able to access them. 33 00:02:20,870 --> 00:02:24,450 ‫But for simplicity's sake in this first example, we're just using the short form. 34 00:02:24,530 --> 00:02:33,890 ‫All I need to do is use that file in a standard stack deploy command. So, deploy docker-compose, and 35 00:02:33,890 --> 00:02:40,790 ‫we'll call this mydb. You'll see, just like before, it actually created the network first. 36 00:02:40,830 --> 00:02:45,020 ‫In this case, it actually created the secrets first and then created the service. 37 00:02:45,060 --> 00:02:50,910 ‫If I went and did a Docker secret look-up, then you'll see that the two are in there and it follows the 38 00:02:50,910 --> 00:02:56,070 ‫same naming convention as all other stack components, where it's always the stack name and then the name 39 00:02:56,070 --> 00:02:57,160 ‫of the object. 40 00:02:57,330 --> 00:03:01,290 ‫Just like in the previous lecture, if I jumped on the SQL server and actually looked for those files, 41 00:03:01,290 --> 00:03:07,520 ‫they would be there just like they were before; only now, they're managed inside our stack file. 42 00:03:07,590 --> 00:03:12,810 ‫The nice thing here is if I removed my stack, it also cleans up the secrets and gets rid of them. In the 43 00:03:12,810 --> 00:03:13,980 ‫previous example, 44 00:03:14,010 --> 00:03:19,230 ‫if we wanted to remove our secrets, we would have had to do a docker secret rm to actually remove each 45 00:03:19,230 --> 00:03:21,440 ‫one. Just as a last reminder, 46 00:03:21,490 --> 00:03:25,570 ‫in these examples we've been using text files on this server, and that we're talking about 3-node 47 00:03:25,570 --> 00:03:26,240 ‫swarm here. 48 00:03:26,370 --> 00:03:31,320 ‫But if you're in a production environment or really anything that's not on your local machine, you should 49 00:03:31,320 --> 00:03:37,290 ‫not be keeping the secrets in files or in the bash history file or any place that could possibly be 50 00:03:37,290 --> 00:03:38,160 ‫on that host. 51 00:03:38,160 --> 00:03:42,240 ‫That's kind of defeating the purpose of having the secrets in the first place. Whatever your process 52 00:03:42,240 --> 00:03:44,360 ‫is for getting secrets into the Swarm, 53 00:03:44,430 --> 00:03:49,470 ‫just know that you may need cleanup once you're done there so that you don't leave residual secrets 54 00:03:49,470 --> 00:03:51,270 ‫around that are easy for people to get.