0 1 00:00:00,640 --> 00:00:04,150 This video is my talk from DockerCon 2017. 1 2 00:00:04,150 --> 00:00:09,700 I actually did it twice once in the US once in Europe at both DockerCons and a lot of this stuff still 2 3 00:00:09,700 --> 00:00:14,530 is relevant today in fact there's very little of it that would change if I did it again right now. 3 4 00:00:14,620 --> 00:00:20,920 So this details the best practices starting from hardware decisions all the way up through the OS into 4 5 00:00:20,920 --> 00:00:27,430 darker versions into your images and then building out swarm clusters and how you design those and how 5 6 00:00:27,430 --> 00:00:32,070 big should they be and what should be managers versus workers and all the details in between. 6 7 00:00:32,080 --> 00:00:39,430 So I hope you enjoy this is the last session of the day and we've got the most excellently awesome Bret 7 8 00:00:39,530 --> 00:00:41,590 Fisher who is also a captain. 8 9 00:00:41,630 --> 00:00:46,490 He was one of the first cohort captains so he's got years of experience of Docker in production. 9 10 00:00:46,490 --> 00:00:51,470 He consults and helps to get to production and this session is about what you need to know but also 10 11 00:00:51,470 --> 00:00:52,280 what you need to decide. 11 12 00:00:52,280 --> 00:00:54,260 So is this decision you need to make to. 12 13 00:00:54,500 --> 00:00:58,640 If any of you are into light or if you're old if there are old geeks in the audience. 13 14 00:00:58,640 --> 00:01:03,050 I don't mean in a nasty way because I am one real real old and real geek than you. 14 15 00:01:03,100 --> 00:01:04,880 You will enjoy the theme of this session. 15 16 00:01:04,910 --> 00:01:06,760 So take it away from me. 16 17 00:01:06,980 --> 00:01:07,310 Thank you. 17 18 00:01:13,100 --> 00:01:20,450 I get the honor of having the graveyard shift so thanks for coming and we're almost too happy hour. 18 19 00:01:20,450 --> 00:01:23,190 So why are we here. 19 20 00:01:23,210 --> 00:01:29,780 He lighted up very succinctly but we are here because you probably want Docker and production. 20 21 00:01:29,780 --> 00:01:32,420 I'm not here to convince you that Docker production is a good idea. 21 22 00:01:32,420 --> 00:01:34,320 You probably already decided that. 22 23 00:01:34,490 --> 00:01:40,490 So this is about the lessons learned with consulting and with Docker and a lot of their best practices 23 24 00:01:40,490 --> 00:01:44,090 about a lot of the decisions you need to make before you get into production. 24 25 00:01:44,090 --> 00:01:51,350 Also you might be a old video game fan a retro videogame fan so I'm going to keep you a little bit entertained 25 26 00:01:51,350 --> 00:01:53,980 with some trivia and I'm going to ask you for. 26 27 00:01:53,990 --> 00:01:58,850 I'm going to give you some music and screenshots from classic games that were my favorites as a kid 27 28 00:01:59,180 --> 00:02:01,330 and I wanted to yell it out if you recognize it. 28 29 00:02:01,330 --> 00:02:02,020 So this is a little bit. 29 30 00:02:02,030 --> 00:02:05,060 Audience participation and let's get started. 30 31 00:02:05,840 --> 00:02:10,980 So if you haven't figured it out yet I'm a geek and I have been since the 5th grade when I got a tier 31 32 00:02:11,020 --> 00:02:17,620 S.A.T. and I mostly do sysadmin stuff although I am a pretend developer as well. 32 33 00:02:17,630 --> 00:02:21,700 For a long time now and the here's the list. 33 34 00:02:21,710 --> 00:02:23,030 This is my resumé. 34 35 00:02:23,090 --> 00:02:28,220 This is a list of all the video game platforms I had as a child up until like the early nineteen nineties 35 36 00:02:28,880 --> 00:02:30,630 and we're gonna have some trivia. 36 37 00:02:30,640 --> 00:02:31,340 So let's have some fun. 37 38 00:02:34,080 --> 00:02:36,620 One street fighter. 38 39 00:02:36,620 --> 00:02:37,130 That was good. 39 40 00:02:37,210 --> 00:02:39,250 He's fast. 40 41 00:02:39,560 --> 00:02:45,460 OK so this is this is me making poor analogies about HD video games and how that relates to Ducker. 41 42 00:02:45,500 --> 00:02:52,400 So in the 90s I was actually a navy a school and in the military in the military we were learning mainframes 42 43 00:02:52,430 --> 00:02:56,080 as well as pieces at the same time because let's just do both. 43 44 00:02:56,120 --> 00:03:01,460 We had original hybrid computing and the cool thing about this game was when you were actually in school 44 45 00:03:01,460 --> 00:03:07,100 you could actually get all your friends to bring it to you inside the room and play eight game players 45 46 00:03:07,100 --> 00:03:12,440 at a time in a big tournament battle and we would declare the winning the crowned champion for the week 46 47 00:03:12,830 --> 00:03:17,810 and then we would go back to studying our piece in pieces and mainframes and so it was a great time. 47 48 00:03:17,810 --> 00:03:23,840 So I'm here to actually give you Super Street Fighter turbo advice on your project and maybe help you 48 49 00:03:23,840 --> 00:03:24,940 make some decisions. 49 50 00:03:25,020 --> 00:03:30,730 And that first problem is limiting your simultaneous innovation limiting your simultaneous innovation. 50 51 00:03:30,800 --> 00:03:34,260 So this is my fancy way of saying scope creep scope creep. 51 52 00:03:34,520 --> 00:03:36,730 So we all know about scope creep and I.T. projects. 52 53 00:03:36,740 --> 00:03:39,280 Everybody wants everything in the first release. 53 54 00:03:39,440 --> 00:03:41,560 And this is the same with your infrastructure. 54 55 00:03:41,600 --> 00:03:45,870 So there's common problems that I see when I'm starting off with projects. 55 56 00:03:45,890 --> 00:03:52,150 Usually I come in at the point when the client once Docker they've heard about orchestration. 56 57 00:03:52,310 --> 00:03:56,900 They want all the things in this fancy orchestration because they spent 20 years building up their VM 57 58 00:03:56,900 --> 00:04:01,880 infrastructure for 15 years and they want that exact same thing in the first version of their first 58 59 00:04:01,880 --> 00:04:03,380 container and production. 59 60 00:04:03,380 --> 00:04:08,450 So I'm going to give you some excuses for things that maybe you don't need. 60 61 00:04:08,450 --> 00:04:15,120 The very first time you deploy production containers and one of those things is the ICD. 61 62 00:04:15,140 --> 00:04:20,240 Even though if you have that today you probably don't have to do a lot to get it to work with containers. 62 63 00:04:20,240 --> 00:04:21,580 It's not that big of a deal. 63 64 00:04:21,590 --> 00:04:24,930 All of the CIA platforms now kind of support support containers. 64 65 00:04:25,100 --> 00:04:26,790 So you're good. 65 66 00:04:26,810 --> 00:04:32,030 But if you don't have CIC today you don't have to have that for your first container project or even 66 67 00:04:32,030 --> 00:04:33,110 your second container project. 67 68 00:04:33,110 --> 00:04:38,150 Don't make that a requirement and have to build up that infrastructure dynamic performance scaling is 68 69 00:04:38,150 --> 00:04:43,040 another big one where people just assume that as soon as you get orchestration this magically causes 69 70 00:04:43,070 --> 00:04:48,860 all of your nodes in your containers to magically scale up and down that's not built in. 70 71 00:04:48,890 --> 00:04:53,270 And that's probably shouldn't be the very first thing you do because you're gonna learn a lot and you 71 72 00:04:53,270 --> 00:04:58,850 need to have those learnings before you start trying to automatically scale this infrastructure. 72 73 00:04:58,850 --> 00:05:02,050 And starting with persistent data is a really big one. 73 74 00:05:02,970 --> 00:05:07,450 Don't make your databases the first thing that you put in a swarm cluster. 74 75 00:05:07,460 --> 00:05:12,660 It's not that it's a bad thing it's just it's a little harder persistent data is a harder thing to deal 75 76 00:05:12,660 --> 00:05:13,220 with. 76 77 00:05:13,440 --> 00:05:16,590 And it's also probably not your most agile infrastructure right. 77 78 00:05:16,590 --> 00:05:20,970 You're probably not upgrading your databases to a new version every month but you're probably deploying 78 79 00:05:20,970 --> 00:05:26,310 new code every week or every day or and so you're going to get a lot more benefit out of your application 79 80 00:05:26,310 --> 00:05:32,470 code anyway instead of your persistent data so legacy apps as we've been saying all week and all year 80 81 00:05:32,470 --> 00:05:35,600 the MTA program legacy apps still work too. 81 82 00:05:35,620 --> 00:05:42,180 One of my goals whenever we're working on a project with applications is to not change any code I would 82 83 00:05:42,180 --> 00:05:48,510 say that the probably the most common change we make an application code is when there's assumed environment 83 84 00:05:49,170 --> 00:05:52,500 pieces hardcoded into the app like IP addresses and code. 84 85 00:05:52,500 --> 00:05:58,440 Obviously we probably know that that's wrong but in older apps you know like really old apps 10 year 85 86 00:05:58,440 --> 00:05:58,880 old apps. 86 87 00:05:58,890 --> 00:06:03,990 I see a lot of assumptions around specific IP or host names or certain environment variables that need 87 88 00:06:03,990 --> 00:06:08,190 to be there and we usually have to pull those out and get those into environment variables. 88 89 00:06:08,190 --> 00:06:10,730 That's really the only code we usually have to change. 89 90 00:06:10,780 --> 00:06:11,450 Factor. 90 91 00:06:11,460 --> 00:06:16,530 We all love you probably heard of twelve factor it's sort of an ideal solution it doesn't need to be 91 92 00:06:16,530 --> 00:06:21,990 there for you to implement containers or even orchestration it's I don't look at it as it's done. 92 93 00:06:21,990 --> 00:06:23,850 I look at it more as a horizon. 93 94 00:06:23,850 --> 00:06:29,250 So your goal should be to learn distributed computing best practices and implement those over time not 94 95 00:06:29,250 --> 00:06:34,980 necessarily all at once before you go to production and the I don't like that stuff delay you because 95 96 00:06:35,250 --> 00:06:41,490 you're going to learn lots on the first day of production you're learn more there than the last two 96 97 00:06:41,490 --> 00:06:48,440 months of the project of going production right. 97 98 00:06:48,840 --> 00:06:49,290 Yes. 98 99 00:06:50,310 --> 00:06:52,800 So this is the NHS and eighty five. 99 100 00:06:52,800 --> 00:06:54,050 That was a long time ago. 100 101 00:06:54,060 --> 00:07:01,770 But that game Super Mario Brothers held the title of the best selling game on a platform for 30 years. 101 102 00:07:01,920 --> 00:07:08,700 That title and it was a big part of my life was my first console that actually had two controllers that 102 103 00:07:08,700 --> 00:07:10,040 we could play a game at the same time. 103 104 00:07:10,050 --> 00:07:14,640 So that was me learning how to be competitive in gaming before that a lot of the games are usually just 104 105 00:07:14,880 --> 00:07:16,130 one player at a time. 105 106 00:07:16,260 --> 00:07:19,910 And it also had a co-op mode that was really cool for learning what co-ops about. 106 107 00:07:20,400 --> 00:07:25,500 So let's talk about some default power ups and how you might make your doctor files better and ready 107 108 00:07:25,500 --> 00:07:26,160 for production. 108 109 00:07:27,030 --> 00:07:30,180 So I always tell everyone focus on Doctor files first. 109 110 00:07:30,270 --> 00:07:35,910 I'd rather you have those doctor files be really well tuned then some fancy orchestration features or 110 111 00:07:35,910 --> 00:07:41,040 fully automated C ICD those doctor files are your new bill documentation. 111 112 00:07:41,040 --> 00:07:48,480 So you're going to need to move maybe you have code and animal salt stack puppet whatever you need. 112 113 00:07:48,480 --> 00:07:53,060 Shell scripts that stuff that you had before for building your servers that's in your doctor file now 113 114 00:07:53,300 --> 00:07:57,180 and you're gonna need to comment it and put lots of documentation in that file and you're gonna need 114 115 00:07:57,180 --> 00:08:03,960 to tune that file and in fact I call this the doc or maturity model of how you might go about starting 115 116 00:08:03,960 --> 00:08:09,120 from day one of a doctor file to the production ready Doctor file because a lot of things obviously 116 117 00:08:09,120 --> 00:08:14,610 just work in dev and not in production and with containers that's our goal right is that the things 117 118 00:08:14,610 --> 00:08:18,090 that work in dev work exactly the same in production that was our whole go goal. 118 119 00:08:18,090 --> 00:08:25,080 So we start with just getting your app to work and not crash which doesn't always work the first day. 119 120 00:08:25,080 --> 00:08:29,310 So as you start this project and you starting your doctor files and you're basing it on official images 120 121 00:08:29,310 --> 00:08:34,920 hopefully you're gonna get it to start and stay starting and stay working then you're going to focus 121 122 00:08:34,920 --> 00:08:39,330 on your logs like getting the logs out of that container not putting them into log files. 122 123 00:08:39,330 --> 00:08:40,720 That's an anti pattern. 123 124 00:08:40,720 --> 00:08:42,860 And I see a lot people still doing that. 124 125 00:08:42,990 --> 00:08:47,820 You need to be putting it in FTD air and ICD out and let Docker handle your logs let your offer your 125 126 00:08:47,820 --> 00:08:53,100 orchestration handle your logs for you Please don't keep them in the app and also removes requirements 126 127 00:08:53,100 --> 00:08:58,470 because a lot of apps have sub modules that are doing this fancy logging for them and now you can kind 127 128 00:08:58,470 --> 00:09:03,150 of pull that out of your app and make that a part of your infrastructure then documenting is a big thing 128 129 00:09:03,150 --> 00:09:03,780 to do next. 129 130 00:09:03,780 --> 00:09:08,490 Maybe someone who's working on the doctor file for the team and you're going to need to give this to 130 131 00:09:08,520 --> 00:09:11,220 someone else in the team to have them tested run it. 131 132 00:09:11,220 --> 00:09:14,820 I recommend you have documentation in there about each area of the docker file. 132 133 00:09:14,820 --> 00:09:19,200 Obviously those lines are pulled out before build time so it's not going to slow down your builds it's 133 134 00:09:19,200 --> 00:09:24,210 not going to affect production of all the documentation in there and then making it lean and making 134 135 00:09:24,210 --> 00:09:25,110 it scale. 135 136 00:09:25,110 --> 00:09:27,850 So a lot of people focus on lean first. 136 137 00:09:27,960 --> 00:09:32,520 They worry about the size of the image and I'm here to tell you your image size is not your number one 137 138 00:09:32,520 --> 00:09:33,720 or number two problem. 138 139 00:09:33,720 --> 00:09:40,050 I don't care how big your images because you're you're gonna probably want to use the official images 139 140 00:09:40,050 --> 00:09:41,040 that you're used to. 140 141 00:09:41,220 --> 00:09:48,510 If your service today are Ubuntu or S.O.S or whatever you're running make those that default images 141 142 00:09:49,260 --> 00:09:50,590 on your first project. 142 143 00:09:50,640 --> 00:09:55,770 Now eventually you can get to some super lean Alpine images that are fat Meg with only the binaries 143 144 00:09:55,770 --> 00:09:59,550 that you built in go and that's all wonderful but you don't need that on day one. 144 145 00:09:59,580 --> 00:10:01,480 You don't need that in your first container project. 145 146 00:10:01,500 --> 00:10:07,440 I have production clients that don't have that yet because that image is single instant storage on those 146 147 00:10:07,440 --> 00:10:11,900 host each image assuming it's a single Virgin is only stored once. 147 148 00:10:11,970 --> 00:10:16,350 Even if you're running five containers from it and so it's not a big deal if you have a five hundred 148 149 00:10:16,350 --> 00:10:19,250 Meg you know image or a 300 meg image. 149 150 00:10:19,350 --> 00:10:24,840 So I wouldn't sweat the small stuff like the image size I would sweat more about the quality of the 150 151 00:10:24,840 --> 00:10:27,480 docker file and then reducing the change rate. 151 152 00:10:27,480 --> 00:10:33,810 So if you're build documentation is all based on apt get you don't want to move necessarily on your 152 153 00:10:33,810 --> 00:10:37,920 very first Docker file to a completely different package manager in Alpine. 153 154 00:10:38,070 --> 00:10:42,720 You would rather use the same build documentation had today it will work in the doctor file without 154 155 00:10:42,750 --> 00:10:47,490 getting a dog or file and take that to production and learn all the lessons you're gonna learn there 155 156 00:10:47,580 --> 00:10:53,280 and then make a sub a separate project later to maybe change to have something like Alpine like a reduced 156 157 00:10:53,310 --> 00:10:58,200 image of reduced footprint for maybe for security or just friendliness of the image. 157 158 00:10:58,200 --> 00:10:59,790 So and then make a scale right. 158 159 00:10:59,810 --> 00:11:04,860 And taking that application and running it in multiple containers at the same time assuming it can if 159 160 00:11:04,860 --> 00:11:09,420 it's a database probably needs has something like replication and all that stuff in the database layer. 160 161 00:11:09,510 --> 00:11:14,640 But if we talk about Web apps or worker apps and stuff like that I'll make sure that it can scale out 161 162 00:11:15,480 --> 00:11:18,840 because it doesn't always mean that just because it runs in one container that it will work well in 162 163 00:11:18,840 --> 00:11:21,650 a orchestrator automatically with five containers. 163 164 00:11:21,660 --> 00:11:21,920 Right. 164 165 00:11:21,930 --> 00:11:25,830 There might be session state you're dealing with other issues with parallel 165 166 00:11:30,910 --> 00:11:31,750 Sonic the Hedgehog. 166 167 00:11:31,970 --> 00:11:32,540 OK. 167 168 00:11:32,650 --> 00:11:35,050 So who remembers the 16 bit console wars. 168 169 00:11:35,120 --> 00:11:39,850 Remember the 8 bit with a 16 bit it was a big deal and there was this fight between super and Tendo 169 170 00:11:39,850 --> 00:11:41,750 and Sega Genesis and who's going to win. 170 171 00:11:41,920 --> 00:11:47,200 And you know now we're on the 128 bit warriors or I don't know what we're at now but so Sonic the Hedgehog 171 172 00:11:47,200 --> 00:11:54,970 was such a big deal for me as a kid that I actually when I.R.S. and I mean c everyone remember I see 172 173 00:11:54,970 --> 00:11:56,870 queue chat from the 90s. 173 174 00:11:56,950 --> 00:11:58,200 Yeah so. 174 175 00:11:58,240 --> 00:12:01,650 So I had to come up with a handle right we all if we all got on line you're like Oh I'm not supposed 175 176 00:12:01,660 --> 00:12:03,010 to use my real name I don't have a handle. 176 177 00:12:03,010 --> 00:12:07,960 So I ended up with Sonics various variations on Sonic the Hedgehog because that was my favorite game 177 178 00:12:07,960 --> 00:12:10,110 at the time and he was really cool. 178 179 00:12:10,120 --> 00:12:13,690 He actually it was so cool he had this feature where he would roll up into a ball and scream around 179 180 00:12:13,690 --> 00:12:16,440 the screen loop de loops all over the screen. 180 181 00:12:16,450 --> 00:12:20,920 And what happened was that you the player because I was probably like three frames a second or something 181 182 00:12:21,010 --> 00:12:26,310 crazy slow at the time you as a player were no longer aware of what was going on the screen. 182 183 00:12:26,320 --> 00:12:30,320 You were really just following anti patterns and you were trying to prevent this. 183 184 00:12:30,520 --> 00:12:33,760 You were trying to prevent from hitting spikes or dangers in the road ahead. 184 185 00:12:33,760 --> 00:12:39,740 So the only job you had was to make sure that you didn't hit stuff you were an anti pattern thing. 185 186 00:12:39,760 --> 00:12:41,530 You were just that's all you were observing. 186 187 00:12:41,560 --> 00:12:45,340 So this is my horrible analogy of how we're going to look at darker darker file into patterns for a 187 188 00:12:45,340 --> 00:12:51,420 second and we're gonna hammer through these pretty quick and the first one I see is pretty obvious. 188 189 00:12:51,460 --> 00:12:52,890 We probably all know about volumes now. 189 190 00:12:52,930 --> 00:12:58,420 That's a new if not a new feature it came out a while back couple of years and I see people that accidentally 190 191 00:12:58,420 --> 00:13:07,010 forget to add extra dark volumes for maybe their debug logs or air dump logs or something like that 191 192 00:13:07,010 --> 00:13:12,710 that they forgot to put the FTD out or maybe they have a static file uploads from users or some sort 192 193 00:13:12,710 --> 00:13:17,180 of caching files that they want to keep between loads of the app or something. 193 194 00:13:17,180 --> 00:13:20,900 So you want to make sure that those are in volumes if you're using official images all the persistent 194 195 00:13:20,900 --> 00:13:28,160 data stuff in there already has volumes for you taking care of if you're using latest please stop just 195 196 00:13:28,160 --> 00:13:29,800 don't ever y. 196 197 00:13:29,810 --> 00:13:36,140 Just never again ever type that word latest just don't do it do a version just if you're gonna make 197 198 00:13:36,140 --> 00:13:40,720 a docker file even for testing just get in the habit of typing versions because it's muscle memory. 198 199 00:13:40,880 --> 00:13:44,990 So when you get to the muscle memory of knowing the version that you're on right now and just typing 199 200 00:13:44,990 --> 00:13:50,840 that in the front lines you'll see here that example on the top the PDP official one uses version no 200 201 00:13:50,840 --> 00:13:52,220 similar right. 201 202 00:13:52,280 --> 00:13:55,140 The second one there from your boot to it. 202 203 00:13:55,240 --> 00:13:59,380 It's got us technically as assembler because it's on sixteen 0 4 but it's date based. 203 204 00:13:59,420 --> 00:14:03,610 So you know that the packet the app get packages in there when they were actually put in. 204 205 00:14:03,620 --> 00:14:05,070 So it gives you an idea. 205 206 00:14:05,090 --> 00:14:08,780 These are also two examples by the way of when you're building your own images you don't have to do 206 207 00:14:08,780 --> 00:14:12,920 similar of your own images you might do date based or commit ideas based. 207 208 00:14:12,920 --> 00:14:19,280 But what I really focus on here is that the top example is showing the versions of the different apps 208 209 00:14:19,280 --> 00:14:24,530 that I'm putting in that Docker file and I'm setting up environment variables at the very top so that 209 210 00:14:24,530 --> 00:14:30,830 when someone or anyone of my team looks at this Docker file they can immediately know what actual versions 210 211 00:14:30,830 --> 00:14:35,000 of those apps are installed they want to scroll through what could be hundreds of lines of Docker file 211 212 00:14:35,000 --> 00:14:38,690 to figure out what version of node that we put in here. 212 213 00:14:38,690 --> 00:14:42,840 I mean obviously you have things like packet package Jason and composer and stuff like that. 213 214 00:14:43,010 --> 00:14:46,820 That's a little bit separate because that's in the app but this is all about those at those parts of 214 215 00:14:46,820 --> 00:14:51,800 the app that are there just so your code runs and they tend to get lost in the docker file and you forget 215 216 00:14:51,800 --> 00:14:52,880 to update them. 216 217 00:14:52,880 --> 00:14:57,650 So in the second one you can see I'm pinning actually pinning isn't the right word for app get but I 217 218 00:14:57,650 --> 00:15:04,210 am specifying the correct the right update version for some of my app get packages. 218 219 00:15:04,250 --> 00:15:09,790 Most people don't do this when I when I first get into the project and I it's not hard to do. 219 220 00:15:09,800 --> 00:15:14,180 You actually just can install the versions that you think you need or just install whatever's latest 220 221 00:15:14,210 --> 00:15:18,140 and then find out the versions pretty easily with APP get and then just put those in your doctor file 221 222 00:15:18,170 --> 00:15:19,160 not for everything. 222 223 00:15:19,160 --> 00:15:24,320 Probably not for curl or other utilities you might need but for the ones that are particular to your 223 224 00:15:24,320 --> 00:15:29,570 app and PSP is one of the harder ones because it usually has a lot of app get dependencies for your 224 225 00:15:29,570 --> 00:15:36,140 PSP app so pin those versions because you don't deploy random versions of code so why deploy random 225 226 00:15:36,140 --> 00:15:38,600 versions of the code dependencies. 226 227 00:15:38,600 --> 00:15:43,910 This Docker file could be built daily every time you do a code commit which means you could end up with 227 228 00:15:43,910 --> 00:15:49,760 random image versions of the of the of the dependencies and then if you're doing start to get the full 228 229 00:15:50,000 --> 00:15:55,400 autopsy ICD you start having random little quirks like the Mongo database driver gets updated and suddenly 229 230 00:15:55,400 --> 00:15:59,960 doesn't support your version of Mongo but you didn't know it cause your testing doesn't maybe test on 230 231 00:15:59,960 --> 00:16:00,680 that version of Mongo. 231 232 00:16:00,710 --> 00:16:07,090 So anyway I'm not bitter it happen to me I'm just saying pin your versions you can learn from me. 232 233 00:16:08,650 --> 00:16:16,650 Default config is in apps like Pete well really all ask for PSP my sequel postgrad Mongo. 233 234 00:16:16,720 --> 00:16:18,460 Java is a pretty good one. 234 235 00:16:18,640 --> 00:16:25,660 A lot of people will not realize or conceptualize the idea that there this is infrastructure building 235 236 00:16:25,660 --> 00:16:31,660 in the docker file and maybe before you were depending upon another team to set up your Java memory 236 237 00:16:31,660 --> 00:16:37,740 limits or set up the proper my sequel config file those are now a responsibility of the docker file 237 238 00:16:37,750 --> 00:16:38,550 or this they should be. 238 239 00:16:39,010 --> 00:16:43,010 So this is a pretty good example of what you might do. 239 240 00:16:43,210 --> 00:16:47,830 A better example is if you use the entry point script not gonna get into entry point scripts today or 240 241 00:16:47,830 --> 00:16:53,310 how they work but they allow you to run a command before you do your CFD. 241 242 00:16:53,560 --> 00:16:59,350 That could be a script that sets up your config files on the fly and if you actually go look at the 242 243 00:16:59,350 --> 00:17:03,530 official images for my sequel or Postgres to name a few. 243 244 00:17:03,640 --> 00:17:07,680 Those have entry points scripts in them that do all sorts of stuff before the database starts. 244 245 00:17:07,690 --> 00:17:12,250 They create the default database they add the default admin password they set up a custom user for your 245 246 00:17:12,250 --> 00:17:17,320 database they do all that and then the database restarts into the command. 246 247 00:17:17,320 --> 00:17:23,890 And this is a way that you can solve a lot of these problems around not hard coding environments settings 247 248 00:17:24,010 --> 00:17:25,660 into the docker build. 248 249 00:17:25,660 --> 00:17:32,090 You really want to keep those out and in the actual runtime configuration. 249 250 00:17:32,090 --> 00:17:38,270 And so this is something I saw in a project where they were building the same image over and over different 250 251 00:17:40,250 --> 00:17:42,890 technically images for different environments. 251 252 00:17:42,890 --> 00:17:49,130 So then they would just change the docker file to use a different Jason and then build a different image. 252 253 00:17:49,130 --> 00:17:54,410 This is definitely an anti pattern because now you've got all these different images one per environment 253 254 00:17:54,470 --> 00:18:00,200 and if if you've been in this industry long enough you know environments are infinite right especially 254 255 00:18:00,200 --> 00:18:05,480 now that we have virtualization it's you know whatever you have in environments tomorrow it'll be in 255 256 00:18:05,480 --> 00:18:10,490 plus one and so you'll be keeping all these different images and you don't want that. 256 257 00:18:10,520 --> 00:18:14,540 So you're going to constantly try to be pulling out all those environments settings setting an ideal 257 258 00:18:14,540 --> 00:18:16,270 environment of a docker file. 258 259 00:18:16,280 --> 00:18:21,320 I prefer doing it in the docker file than having it in other files that later get imported because it 259 260 00:18:21,320 --> 00:18:22,750 increases visibility. 260 261 00:18:22,850 --> 00:18:27,620 So I always try to get as many of those environments settings right there in the docker file as defaults 261 262 00:18:27,680 --> 00:18:33,050 and then I set them at runtime so that anyone who's looking at the docker file knows what the defaults 262 263 00:18:33,050 --> 00:18:33,170 are. 263 264 00:18:33,170 --> 00:18:37,730 They don't have to go digging around in some other repo or some other system for whatever that config 264 265 00:18:37,730 --> 00:18:46,220 file might be for that application is a little tougher when we're gonna get more advanced dragon slayer. 265 266 00:18:46,220 --> 00:18:48,620 Yes this is a pretty cool one. 266 267 00:18:48,650 --> 00:18:54,860 In fact it was the first laser disc game and it was an eighty three Nova man when he was a laser disc 267 268 00:18:54,890 --> 00:18:58,540 but it was basically a big city a very big city the size of a record. 268 269 00:18:58,670 --> 00:19:01,490 And this is hand drawn art. 269 270 00:19:01,490 --> 00:19:05,020 This is actually a game that was playing a movie while you were watching it. 270 271 00:19:05,030 --> 00:19:08,900 In fact for me it mostly mostly looked like that because I was constantly dying. 271 272 00:19:08,900 --> 00:19:13,250 It was a hard game to play and there was no cheat you couldn't look up cheats on the internet back then 272 273 00:19:13,280 --> 00:19:17,440 so you couldn't figure out what the right moves were. 273 274 00:19:17,570 --> 00:19:18,550 So dragon slayer. 274 275 00:19:18,740 --> 00:19:24,350 It was it was actually a 50 cent game when the world was on twenty five cents per game. 275 276 00:19:24,350 --> 00:19:29,060 They were like the one that they'd started this evolution of dollar games and two dollar chains and 276 277 00:19:29,060 --> 00:19:33,260 all this crazy stuff now and we would all just stand around and watch it because it was like watching 277 278 00:19:33,260 --> 00:19:41,630 a cartoon and it actually I think it was probably the one of most grossing games in a ten minute period. 278 279 00:19:41,630 --> 00:19:45,440 I would basically lose a paycheck in ten minutes on this game because you would die every 30 seconds 279 280 00:19:45,470 --> 00:19:46,980 and it was one life for 50 cents. 280 281 00:19:47,000 --> 00:19:49,390 So it was pretty tough. 281 282 00:19:49,490 --> 00:19:52,520 By the way if it was thirty five years later this game still looks fantastic. 282 283 00:19:52,520 --> 00:19:55,330 You can actually play on your phone now and looks great. 283 284 00:19:55,700 --> 00:19:57,990 So let's play some infrastructure dragons. 284 285 00:19:58,100 --> 00:20:03,260 Let's let's talk about three big decisions that you probably to make if you're an ops team about your 285 286 00:20:03,260 --> 00:20:07,430 infrastructure it's probably some of the most common questions I get on a start of a project. 286 287 00:20:07,430 --> 00:20:11,440 And the first one is VMs or hardware like various VMs or bare metal. 287 288 00:20:11,810 --> 00:20:13,210 And I say both. 288 289 00:20:13,280 --> 00:20:15,410 I say do what you're good at. 289 290 00:20:15,410 --> 00:20:16,790 Stick with what you're good at. 290 291 00:20:16,970 --> 00:20:22,160 And then maybe an hour later project you do some sleep performance testing on bare metal. 291 292 00:20:22,190 --> 00:20:27,380 You're probably better unless you're a few of us that really need the raw power of our metal you're 292 293 00:20:27,380 --> 00:20:33,080 probably better at VMS today than you are using bare metal and dynamically deploying bare metal. 293 294 00:20:33,140 --> 00:20:38,930 So if you're if you're on VM I would say later do some performance testing on bare metal at scale on 294 295 00:20:38,930 --> 00:20:43,700 that not necessarily a multiple servers but on that server itself scaling up the number of containers 295 296 00:20:43,730 --> 00:20:46,520 on that bare metal and seeing what the performance looks like. 296 297 00:20:46,520 --> 00:20:51,170 You can do some really simple stuff with some really simple open source tools doesn't have to be complicated 297 298 00:20:51,180 --> 00:20:53,630 or some tool you purchase. 298 299 00:20:53,630 --> 00:20:59,100 In fact the beginning of the year it's a it's probably still relevant because as you know this is a 299 300 00:20:59,150 --> 00:21:02,160 world the containers at the beginning of this year on 112. 300 301 00:21:02,210 --> 00:21:08,380 I worked with HP and docker on we created a white paper and there's other white paper as well. 301 302 00:21:08,420 --> 00:21:14,150 On that link there's two of them that talk about and actually show some basic performance testing that 302 303 00:21:14,150 --> 00:21:20,900 we did and comparisons of workloads in victims workloads in containers and victims and then workloads 303 304 00:21:21,020 --> 00:21:22,580 in containers on bare metal. 304 305 00:21:22,670 --> 00:21:28,310 And it's not a tweet I can't just give you a one liner that says this is what you should do because 305 306 00:21:28,310 --> 00:21:29,290 it's complex right. 306 307 00:21:29,300 --> 00:21:34,550 It changes your IO patterns it changes your kernel scheduling so you're going to probably as you increase 307 308 00:21:34,550 --> 00:21:39,590 density the number of containers in a VM you're going to have to care a little more about things like 308 309 00:21:39,860 --> 00:21:45,020 kernel scheduling and kernel settings and network settings because you're gonna be loading up that OS 309 310 00:21:45,020 --> 00:21:49,780 where maybe before you had one app in one OS and then one app and one OS. 310 311 00:21:49,880 --> 00:21:55,890 So it changes changes the pattern so you have to learn a little bit as you grow the next one is about 311 312 00:21:55,890 --> 00:21:57,890 your OS and the distribution. 312 313 00:21:57,900 --> 00:21:59,130 So we're talking about Linux right now. 313 314 00:21:59,130 --> 00:22:02,300 Obviously from wind if you're into Windows containers you get one choice. 314 315 00:22:02,500 --> 00:22:03,840 That's a nice easy choice. 315 316 00:22:03,840 --> 00:22:09,180 But if you're on Linux your distribution doesn't matter as much as your kernel. 316 317 00:22:09,180 --> 00:22:13,380 The innovations and fixes that I mean Docker is a little over four years old now. 317 318 00:22:13,380 --> 00:22:21,150 Containers have actually been affecting the future of the kernel and how the Linux kernel and the operating 318 319 00:22:21,150 --> 00:22:23,760 system is created and deployed and all that stuff. 319 320 00:22:24,090 --> 00:22:30,540 So you don't want to be running a five year old kernel version 3.0 10 is the minimum of Docker and just 320 321 00:22:30,540 --> 00:22:34,280 because it's the minimum and it works doesn't mean it's the one you should be using. 321 322 00:22:34,380 --> 00:22:34,800 Right. 322 323 00:22:34,830 --> 00:22:41,070 I recommend a 4.0 X kernel and there's actually still a couple of distributions out there where if you 323 324 00:22:41,070 --> 00:22:44,130 install the latest version you might get a 3.0 something kernel. 324 325 00:22:44,220 --> 00:22:46,770 So you need to care about that more than you used to. 325 326 00:22:46,770 --> 00:22:51,120 I mean Apache works the same way pretty much on every different distribution Docker does not. 326 327 00:22:51,180 --> 00:22:52,380 Containers do not. 327 328 00:22:52,410 --> 00:22:52,710 Right. 328 329 00:22:52,740 --> 00:22:58,320 So I would say if you don't have an opinion just try Ubuntu. 329 330 00:22:58,320 --> 00:23:04,860 I'm not playing favorites here but the thing about Ubuntu if you're not someone who's particularly passionate 330 331 00:23:04,860 --> 00:23:10,950 about a particular distribution is that it comes with a 4.0 something kernel out of the box it has that 331 332 00:23:11,040 --> 00:23:13,100 nice long term support lifecycle. 332 333 00:23:13,170 --> 00:23:20,070 It's well documented on the Internet Docker tests that heavily it's one of the official Docker supported 333 334 00:23:20,100 --> 00:23:24,330 distributions in the docker store or maybe try and vacate and Linux kit. 334 335 00:23:24,330 --> 00:23:31,620 Now this one is a caveat because this one will delay your project if you are new to this type of building 335 336 00:23:31,620 --> 00:23:36,110 your own distribution and deploying with Linux with infected if you not where it live. 336 337 00:23:36,150 --> 00:23:42,540 Intricate those are extra additive things so I'm warning you now that that will not be the fastest choice 337 338 00:23:42,600 --> 00:23:45,020 but it will maybe be cool. 338 339 00:23:45,150 --> 00:23:47,370 So that will affect the length of your product. 339 340 00:23:47,410 --> 00:23:50,100 It will delay it a little bit as you learn how Linux kit works. 340 341 00:23:50,100 --> 00:23:54,660 There's been sessions this week on Linux kit and there'll be more tomorrow I'm sure at maybe summit. 341 342 00:23:54,780 --> 00:23:59,400 Lastly there make sure that you get your distribution from the store. 342 343 00:23:59,730 --> 00:24:04,650 The default distribution of Docker in your like an app get young all those. 343 344 00:24:04,650 --> 00:24:06,250 That's not gonna be the right version for you. 344 345 00:24:06,340 --> 00:24:10,740 I'm going gonna guarantee that because that's partly gonna be 113. 345 346 00:24:10,790 --> 00:24:13,260 You know that's eight months old now 10 months old. 346 347 00:24:13,260 --> 00:24:19,350 So you want the latest versions of Docker that you can get the latest stable is 17 0 9 from last month 347 348 00:24:19,740 --> 00:24:25,580 and you're gonna get that through the store which ensures that Dr. built it and that it's not actually 348 349 00:24:25,580 --> 00:24:26,980 different than what Doctor intended. 349 350 00:24:26,990 --> 00:24:31,760 Which is actually the case with some older distributions in the other package managers. 350 351 00:24:31,970 --> 00:24:33,830 Last one here is your container. 351 352 00:24:33,830 --> 00:24:38,210 And we talked about this your container from image we talked about this your base image a lot of teams 352 353 00:24:38,240 --> 00:24:41,250 end up having an intermediate image is what I call it. 353 354 00:24:41,270 --> 00:24:45,260 So you have your base from the store or from a Docker Hub. 354 355 00:24:45,260 --> 00:24:49,370 You have your intermediate that's maybe your standard for the team for no JSF. 355 356 00:24:49,420 --> 00:24:53,570 You know picking your own standard of of that version and you're going to have some of that and then 356 357 00:24:53,570 --> 00:24:58,070 you maybe have another image that you build on top of that you don't have to do it that way. 357 358 00:24:58,220 --> 00:25:02,660 But if you're more than a few people in the team you probably want to set some standards going along. 358 359 00:25:02,660 --> 00:25:05,570 It's kind of like the old golden image idea of a VM. 359 360 00:25:05,660 --> 00:25:11,660 That's what you're gonna maybe do with an intermediate but I would say make it based on not the image 360 361 00:25:11,660 --> 00:25:11,960 size. 361 362 00:25:11,960 --> 00:25:16,990 Like I said earlier definitely based on what your VMs are if you're used to a particular distribution. 362 363 00:25:17,030 --> 00:25:19,310 Just start with that distribution in your image. 363 364 00:25:19,400 --> 00:25:23,990 It'll work it'll be great and then you won't have to change everything about your build documentation 364 365 00:25:23,990 --> 00:25:26,600 when you convert over to your Docker file. 365 366 00:25:27,390 --> 00:25:32,780 Yeah matching existing process and then maybe later again consider Alpine it is becoming a very popular 366 367 00:25:32,780 --> 00:25:37,400 choice because of its 5 Meg size for the image which is pretty sweet 367 368 00:25:44,050 --> 00:25:44,990 job's done. 368 369 00:25:45,110 --> 00:25:47,240 Famous lines like jobs done right. 369 370 00:25:47,240 --> 00:25:52,760 This is actually my intro into blizzard and my 20 year love affair with Blizzard started with that game. 370 371 00:25:52,850 --> 00:25:55,520 I was actually lucky enough to be in the beta of the very first version. 371 372 00:25:55,550 --> 00:26:01,170 This was so long ago that you had to buy a sound card and put it in your P.C. to get it to play. 372 373 00:26:01,180 --> 00:26:06,800 Like to actually enjoy it and that would that video the original piece that was not designed to play 373 374 00:26:06,800 --> 00:26:11,010 video games I guess or not have at least anything other than a little crappy piece speaker. 374 375 00:26:11,040 --> 00:26:14,240 So I think I've bought every Blazer game since then. 375 376 00:26:14,240 --> 00:26:16,560 So yeah that worked. 376 377 00:26:16,610 --> 00:26:21,770 Let's talk about swarm architectures now and this is really about the swarm layer the swarm architecture. 377 378 00:26:21,780 --> 00:26:22,870 So we now know the OS. 378 379 00:26:22,880 --> 00:26:24,420 We now know our images. 379 380 00:26:24,440 --> 00:26:29,010 Let's talk about how we're gonna build that swarm out and I'm going to give you some very basic designs. 380 381 00:26:29,060 --> 00:26:33,980 If you're not if you haven't gone to some of the other swarm stuff you've you haven't read up on swarm 381 382 00:26:33,980 --> 00:26:35,030 and how it works. 382 383 00:26:35,030 --> 00:26:38,030 I'm not gonna go deep dive obviously into a swarm. 383 384 00:26:38,120 --> 00:26:40,130 We had a great workshop on Monday. 384 385 00:26:40,130 --> 00:26:45,080 There's a session actually before this with Laura Frank that talks about swarm and the internals of 385 386 00:26:45,080 --> 00:26:46,910 raft and how consensus works. 386 387 00:26:46,970 --> 00:26:51,710 So I'm just gonna give you some basic design starting with baby swarm and baby swarm. 387 388 00:26:51,710 --> 00:26:56,040 As one note you can build a swarm on one node which can be your laptop. 388 389 00:26:56,060 --> 00:26:57,650 It's just one liner. 389 390 00:26:57,650 --> 00:26:58,000 Right. 390 391 00:26:58,010 --> 00:27:01,650 We probably have all seen these demos we probably tried these demos. 391 392 00:27:01,790 --> 00:27:04,470 It's a real thing and I want to talk about it for a second. 392 393 00:27:04,520 --> 00:27:05,690 It's okay. 393 394 00:27:05,690 --> 00:27:06,800 You have infrastructure today. 394 395 00:27:06,800 --> 00:27:11,390 I'm sure that every one of you there is one system in your environment that is not highly available 395 396 00:27:11,720 --> 00:27:16,350 that if it went down you would get a phone call write something somewhere. 396 397 00:27:16,380 --> 00:27:18,320 It may it may be SGI system. 397 398 00:27:18,420 --> 00:27:23,370 It may be just like some notification system for your ticket system or something else something that's 398 399 00:27:23,370 --> 00:27:26,510 not critical to your business but you have that somewhere. 399 400 00:27:26,610 --> 00:27:28,240 So run it on swarm. 400 401 00:27:28,380 --> 00:27:29,280 Run it on. 401 402 00:27:29,280 --> 00:27:30,710 Just do Ducker swarming it. 402 403 00:27:30,930 --> 00:27:37,350 You get new features out of the box with it you get secrets you get config as you get services that 403 404 00:27:37,350 --> 00:27:43,460 automatically are declarative so they automatically will replace themselves if they have a problem. 404 405 00:27:43,470 --> 00:27:45,830 They can use health checks to make sure that they're available. 405 406 00:27:45,900 --> 00:27:51,280 Those things you don't get with doctor run so out of the box we're fine let's do it. 406 407 00:27:51,330 --> 00:27:54,300 The next option you might have is a three notes form. 407 408 00:27:54,300 --> 00:27:58,200 Don't do even numbers not two notes forms don't do that. 408 409 00:27:58,200 --> 00:28:02,340 At least for managers we're talking about the managers and if you're not super familiar with swarm there's 409 410 00:28:02,340 --> 00:28:07,140 two types of machines there's workers which get the job done and there's managers that have the raft 410 411 00:28:07,140 --> 00:28:10,120 consensus database kind of like an NCD server. 411 412 00:28:10,230 --> 00:28:16,140 And in this case you're a very small project that's maybe a hobby project or a test project. 412 413 00:28:16,140 --> 00:28:21,180 All the machines are doing work but they're also all managers so there also have a little bit more of 413 414 00:28:21,180 --> 00:28:26,340 a security risk profile because they're storing the RAF database that has all of the control over your 414 415 00:28:26,340 --> 00:28:32,040 swarm and that's the very minimum that will actually provide a fault tolerance and your managers the 415 416 00:28:32,040 --> 00:28:34,340 next size up might be five. 416 417 00:28:34,350 --> 00:28:38,980 This is what I would call the big swarm because this is what I recommend to small little scrappy startup 417 418 00:28:39,000 --> 00:28:44,220 companies that they just want the minimum infrastructure for high availability and they don't and they 418 419 00:28:44,220 --> 00:28:48,870 don't really they're not so concerned yet about security and providing boundaries around their managers 419 420 00:28:49,200 --> 00:28:51,110 and they just want high availability. 420 421 00:28:51,120 --> 00:28:56,130 So I recommend this because this allows you to take one node down for maintenance and still have a fall 421 422 00:28:56,130 --> 00:28:59,530 tolerance because in this one you can lose two rights. 422 423 00:28:59,540 --> 00:29:03,010 We got to have always a majority of manager nodes have to be up. 423 424 00:29:03,150 --> 00:29:04,920 So that would be five. 424 425 00:29:04,950 --> 00:29:08,150 From there we're just going to kind of make it up as we go. 425 426 00:29:08,160 --> 00:29:14,280 And by the way on these boxes if you're an ADA yes person ignore the fact that says T or C to that the 426 427 00:29:14,280 --> 00:29:19,820 instant size doesn't matter it was just that the graphic program I was using gave me those graphics. 427 428 00:29:19,950 --> 00:29:23,200 So in this case I've actually split them out. 428 429 00:29:23,210 --> 00:29:30,740 I now have my managers on sort of a secure enclave a different VLAN or a security group so that they 429 430 00:29:30,740 --> 00:29:35,750 can all talk amongst themselves and control the swarm and then I can just make as many worker nodes 430 431 00:29:35,750 --> 00:29:37,070 as I need to have. 431 432 00:29:37,110 --> 00:29:37,430 OK. 432 433 00:29:37,490 --> 00:29:42,320 And those worker nodes can be lots of different things they can in one single swarm I can have different 433 434 00:29:42,320 --> 00:29:46,390 hardware profiles and different network segments different availability zones. 434 435 00:29:46,400 --> 00:29:50,960 I can do all that stuff with those worker nodes and use constraints. 435 436 00:29:51,020 --> 00:29:54,980 If you're not familiar with those it's basically metadata that allows you to tell a service that you're 436 437 00:29:54,980 --> 00:30:01,550 creating for Docker that it needs to be over here with a SSD SSD or maybe there's a security profile 437 438 00:30:01,760 --> 00:30:06,190 scanner you run on a particular server for PCI compliance or whatever. 438 439 00:30:06,230 --> 00:30:06,490 Right. 439 440 00:30:06,500 --> 00:30:12,020 You make it up VPN INS maybe something over a VPN you want to assign labels to those nodes and then 440 441 00:30:12,020 --> 00:30:18,470 you constraint your work with that stuff with the constraints so we can scale this up all the way to 441 442 00:30:18,470 --> 00:30:20,420 hundred nodes and it doesn't change a whole lot. 442 443 00:30:20,450 --> 00:30:21,790 It doesn't it doesn't really change. 443 444 00:30:21,860 --> 00:30:25,750 It's just more worker nodes and more places with more diverse profiles. 444 445 00:30:25,760 --> 00:30:27,380 You're still using the same habits. 445 446 00:30:27,380 --> 00:30:31,970 Maybe the instance sizes are bigger and you will have to scale your managers because your managers are 446 447 00:30:31,970 --> 00:30:34,190 storing that RAF database in memory. 447 448 00:30:34,190 --> 00:30:38,890 So as the work gets bigger and there's more work to be had that RAF database will grow and you're your 448 449 00:30:38,890 --> 00:30:43,480 RAM MCP profiles on those managers may need to increase but they're very easy to replace. 449 450 00:30:43,480 --> 00:30:46,080 You can bring one and take one out with a couple of lines. 450 451 00:30:46,220 --> 00:30:47,390 The doctor files. 451 452 00:30:47,390 --> 00:30:51,980 I'm going to give you a quick little warning on a soap box that please don't make your cattle pets. 452 453 00:30:52,160 --> 00:30:57,320 A lot of people that are moving to agile infrastructure and I hate to use that word because Agile is 453 454 00:30:57,320 --> 00:31:02,820 always overused but your your infrastructure with Docker has the capability of being agile. 454 455 00:31:02,930 --> 00:31:10,280 If you don't make it pets if you don't start like downloading get you know get repositories onto the 455 456 00:31:10,280 --> 00:31:12,890 host and you don't start doing special stuff on the host. 456 457 00:31:13,040 --> 00:31:20,240 It can maintain if it's just build a server install Docker add it to the swarm and then deploy containers. 457 458 00:31:20,240 --> 00:31:26,450 If you just keep it at that and you do everything either remotely through the docker API or maybe some 458 459 00:31:26,690 --> 00:31:31,340 fancy shell stuff where you do stuff over SSD age but you don't actually store stuff on the harddrive 459 460 00:31:31,580 --> 00:31:34,690 then that node is not special and doesn't have to be. 460 461 00:31:34,970 --> 00:31:38,600 But I see a lot people that end up making like one of the manager nodes their box that they do all this 461 462 00:31:38,600 --> 00:31:42,830 stuff on they have all these tools and then they install things with that get on the host and it's a 462 463 00:31:42,830 --> 00:31:43,600 bad habit. 463 464 00:31:43,630 --> 00:31:45,290 It's a habit we've had for decades. 464 465 00:31:45,290 --> 00:31:48,680 It's just I haven't you got to get out of doing you can do all your troubleshooting and all your testing 465 466 00:31:48,680 --> 00:31:54,920 in containers and in that swarm and that's great it keeps it out of being on the host so reasons you 466 467 00:31:54,920 --> 00:31:58,070 might have multiple swarms. 467 468 00:31:58,070 --> 00:32:01,960 This is a common question actually was also asked and dance session before. 468 469 00:32:02,150 --> 00:32:08,160 These are bad reasons for multiple swarms you can do a lot in a single swarm there is no hard set limits. 469 470 00:32:08,240 --> 00:32:13,590 We've tested thousands of nodes Docker I think has tested tens or 10000 or something I'm not sure what 470 471 00:32:13,600 --> 00:32:20,600 their their top number is but these are all things that actually you don't need a reason you don't need 471 472 00:32:20,600 --> 00:32:22,150 that reason to create multiple swarms. 472 473 00:32:22,160 --> 00:32:29,060 Now if you have some of these reasons you you would have to create potentially multiple swarms like 473 474 00:32:30,360 --> 00:32:31,430 I'm an ops person. 474 475 00:32:31,430 --> 00:32:38,480 So I love the idea of giving the ops team the chance to fail before production so give that give the 475 476 00:32:38,480 --> 00:32:44,300 opportunity for the ops team to have a real swarm that other people care about like maybe the CIA platform 476 477 00:32:44,330 --> 00:32:50,600 or the testing infrastructure give the ops person or the team a chance to have that so that they can 477 478 00:32:50,600 --> 00:32:56,060 learn they can make mistakes on swarm and accidently delete the database off the swarm or whatever you 478 479 00:32:56,060 --> 00:33:01,190 know that people do before they get all the way to production because if this is your first product 479 480 00:33:01,190 --> 00:33:05,810 and this is your first swarm you're gonna learn lots you're gonna make mistakes so it's great when you 480 481 00:33:05,810 --> 00:33:12,830 can make them not in production right management boundaries the docker API out of the box is an all 481 482 00:33:12,830 --> 00:33:17,570 or nothing thing and you've probably if you've used Docker a while even before swarm you know that it 482 483 00:33:17,570 --> 00:33:22,370 doesn't have our back built in it doesn't do that role based access control out of the box you can do 483 484 00:33:22,370 --> 00:33:28,130 that with Docker e there's other third party tools there's actually a plugin model that you can create 484 485 00:33:28,160 --> 00:33:32,500 off on top of it but unless you add that layer it is an all or nothing thing. 485 486 00:33:32,510 --> 00:33:38,450 So if you have a team that needs that sort of thing maybe you just decide you know that New York office 486 487 00:33:38,450 --> 00:33:44,110 is gonna have a swarm and the DC office is gonna have a swarm because of management boundaries so I'm 487 488 00:33:44,110 --> 00:33:48,540 going to throw real quick slide in about Windows Server 2016 because that is a really new cool thing 488 489 00:33:48,540 --> 00:33:55,210 and swarm where you can have a hybrid swarm of different OS and I will windows this year right. 489 490 00:33:55,260 --> 00:34:00,990 This is the year that as Server 2016 that's made this possible and it's innovating quickly so every 490 491 00:34:00,990 --> 00:34:06,750 couple of months we get a nice new set of features and windows that expand the capability of it and 491 492 00:34:06,750 --> 00:34:08,680 swarm and and docker in general. 492 493 00:34:08,940 --> 00:34:16,260 So I will say that if you want to make a pure Windows Server 2016 swarm you there may be some potential 493 494 00:34:16,260 --> 00:34:20,860 negatives of that just because we've had four years of innovation in containers. 494 495 00:34:20,940 --> 00:34:24,870 There's all these open source projects on monitoring and logging and but a lot of that stuff is Linux 495 496 00:34:24,870 --> 00:34:25,670 only. 496 497 00:34:25,710 --> 00:34:31,560 So if you're a Windows shop I would encourage you to consider at least some Linux and your swarm so 497 498 00:34:31,560 --> 00:34:36,630 that you can innovate with some of those neat tools out there in the ecosystem that maybe aren't ready 498 499 00:34:36,630 --> 00:34:37,360 for windows there. 499 500 00:34:37,400 --> 00:34:40,250 They're catching up to Windows right. 500 501 00:34:40,320 --> 00:34:46,590 Also if you're I'm always license sensitive on windows and if your swarm managers are just being swarm 501 502 00:34:46,590 --> 00:34:49,810 managers and that's all they're doing then maybe make those Linux. 502 503 00:34:49,920 --> 00:34:54,710 And then you'd use windows for your windows workloads and you don't sort of spend a license on windows 503 504 00:34:54,720 --> 00:34:57,930 just to be a manager sitting there making decisions. 504 505 00:34:57,990 --> 00:34:58,920 So. 505 506 00:34:59,310 --> 00:35:02,960 But you know obviously I could do that this is another hard one. 506 507 00:35:09,060 --> 00:35:12,720 Explain as little user of music right. 507 508 00:35:12,810 --> 00:35:18,600 Explain was a nineteen ninety three dos game and it was probably one of the first games that you needed 508 509 00:35:18,600 --> 00:35:21,560 a mouse for like Wolfenstein 3D was around this time and all that. 509 510 00:35:21,750 --> 00:35:24,250 It was the actual flight simulator in space. 510 511 00:35:24,390 --> 00:35:24,870 It had. 511 512 00:35:24,870 --> 00:35:28,660 You could fly every Star Wars craft eventually because they had lots of hazards. 512 513 00:35:28,680 --> 00:35:34,110 This game was an addiction for me for at least a year to the point that I actually got my first store 513 514 00:35:34,110 --> 00:35:42,810 credit at the Navy any X which is like the Navy Wal-Mart and bought Bose speakers to play the fantastic 514 515 00:35:42,810 --> 00:35:47,360 soundtrack and I bought a stick of a controller for flights flight stick. 515 516 00:35:47,370 --> 00:35:51,480 I basically spent way too much money that couldn't even afford it and I got a store credit so yay consumer 516 517 00:35:51,480 --> 00:35:53,280 debt and that was the fault of that game. 517 518 00:35:54,210 --> 00:35:58,890 So let's talk about outsourcing some parts of your swarm. 518 519 00:35:58,900 --> 00:36:02,050 Maybe you don't need to do everything in-house. 519 520 00:36:02,100 --> 00:36:06,360 Maybe you don't need to innovate everything so I'm gonna say like yeah. 520 521 00:36:06,360 --> 00:36:10,410 Beware of the not implemented here syndrome. 521 522 00:36:10,410 --> 00:36:14,160 Basically there is products out there for a certain part. 522 523 00:36:14,170 --> 00:36:16,990 There's I mean obviously there's commercial products for everything. 523 524 00:36:16,990 --> 00:36:18,460 You could just outsource all of this. 524 525 00:36:18,470 --> 00:36:19,120 Right. 525 526 00:36:19,160 --> 00:36:19,750 We have the cloud. 526 527 00:36:19,760 --> 00:36:21,290 We have commercial companies. 527 528 00:36:21,290 --> 00:36:23,800 But if you're going to do this yourself if you want to do it form yourself. 528 529 00:36:23,870 --> 00:36:31,580 Dr. see then maybe there's some good parts out there that you can use that are easy to outsource easy 529 530 00:36:31,580 --> 00:36:32,940 to exchange. 530 531 00:36:32,960 --> 00:36:39,710 When I say outsource I mean like either a SAS or a some commercial product and image registries is a 531 532 00:36:39,710 --> 00:36:40,470 really great comment. 532 533 00:36:40,470 --> 00:36:42,150 That market is well-defined right. 533 534 00:36:42,170 --> 00:36:47,570 There's good players out there they've been there for years log centralizing your logging and centralizing 534 535 00:36:47,570 --> 00:36:48,590 your monitoring. 535 536 00:36:48,590 --> 00:36:51,250 Those are all obvious to me those are obvious ways. 536 537 00:36:51,290 --> 00:36:56,120 You don't have to go use all the open source tools because typically with open source even though it's 537 538 00:36:56,120 --> 00:37:00,250 awesome you're usually trading free for convenience right. 538 539 00:37:00,260 --> 00:37:02,630 So there is no truly free. 539 540 00:37:02,630 --> 00:37:08,720 So these will accelerate your project if you need to cut timeline out of your container project for 540 541 00:37:08,720 --> 00:37:09,740 grain production. 541 542 00:37:09,740 --> 00:37:15,530 Look at these areas and there's also by the way a great URL for the CMC F. Foundation. 542 543 00:37:15,590 --> 00:37:20,510 They have a pretty cool sort of like a visual diagram of the ecosystem so if you're not familiar with 543 544 00:37:20,510 --> 00:37:25,010 all the logging players and containers there's a nice graphic there that'll give you their logos and 544 545 00:37:25,010 --> 00:37:29,190 you can figure out maybe what things you need to consider their all right. 545 546 00:37:29,220 --> 00:37:30,820 So really quick. 546 547 00:37:30,990 --> 00:37:34,310 We're going to talk about tech stacks and that's why I don't want to call it. 547 548 00:37:34,320 --> 00:37:39,000 But you know this is the building up from the bottom up. 548 549 00:37:39,000 --> 00:37:43,430 What it might look like for you today and now obviously in six months we might have companies. 549 550 00:37:43,460 --> 00:37:45,510 We will we'll have Cuban 80s as an option. 550 551 00:37:45,540 --> 00:37:48,710 So these slides aren't Cuban ideas ready because I'm talking about today. 551 552 00:37:48,780 --> 00:37:50,240 Right this is what you can do now. 552 553 00:37:50,280 --> 00:37:56,340 So maybe at the very bottom you're deploying your infrastructure with for Kit and terraform wrong button 553 554 00:37:57,000 --> 00:37:58,940 and then you're younger your runtime here is darker. 554 555 00:37:58,950 --> 00:38:04,140 Obviously if you're using swarm your orchestration is Docker swarm your networking is the built in overlaying 555 556 00:38:04,140 --> 00:38:09,690 of Docker swarm your storage maybe you're using Rex Ray which is a open source project that orchestrates 556 557 00:38:09,690 --> 00:38:12,280 your your shared storage amongst your hosts. 557 558 00:38:12,300 --> 00:38:15,200 That's a pretty cool project from Dell EMC Jenkins. 558 559 00:38:15,400 --> 00:38:16,730 I mean just storing it is in there. 559 560 00:38:16,770 --> 00:38:22,350 This idea of this stack here though is this is all the open source is pure open source everything yourself 560 561 00:38:22,380 --> 00:38:27,000 on your own system or on a cloud system that you're deploying no SAS here. 561 562 00:38:27,660 --> 00:38:34,650 Docker distribution plus Portis Portis is in a gooey on top of the free registry from Docker so register 562 563 00:38:34,680 --> 00:38:39,150 if you just do Dr. Paul registry that's Dockers official registry maybe you don't want to use hub or 563 564 00:38:39,150 --> 00:38:44,460 anything else you just want your own registry that's what that would be for your layer 7 proxy and if 564 565 00:38:44,460 --> 00:38:48,770 you didn't know you're going to need one probably if you're into Web's web stuff at all you're going 565 566 00:38:48,770 --> 00:38:53,820 to need to share port eighty and four for three amongst many containers that's going to need mean you 566 567 00:38:53,820 --> 00:39:00,000 need a reverse proxy or layer 7 proxy same thing and flow proxy actually from one of the other captains 567 568 00:39:00,000 --> 00:39:06,180 Victor is a really cool project that uses HK proxy and then traffic I think maybe uses engine X that's 568 569 00:39:06,180 --> 00:39:07,060 another popular one. 569 570 00:39:08,140 --> 00:39:13,100 E okay maybe for your love centralized logging I'm most you've probably heard of that. 570 571 00:39:13,230 --> 00:39:18,780 That's another one that works with swarm centralized monitoring maybe Prometheus and Griffon Prometheus 571 572 00:39:18,780 --> 00:39:21,110 actually controls the monitoring Griffon. 572 573 00:39:21,140 --> 00:39:23,860 Is that gooey on top that gives you nice graphs. 573 574 00:39:24,240 --> 00:39:30,000 And then finally up here partner would maybe be a gooey on top of swarm. 574 575 00:39:30,420 --> 00:39:35,790 And one last little thing I thought I'd also throw in if you're into functions as a service open FAS 575 576 00:39:36,240 --> 00:39:41,820 is here this week Alex is talking about you'll see open fire shirts that runs on top us form so you 576 577 00:39:41,820 --> 00:39:45,530 can do your own functions as a service on top of that. 577 578 00:39:45,600 --> 00:39:50,010 Now what I'm going to do is I'm gonna quickly show you what that might look like if you did some of 578 579 00:39:50,010 --> 00:39:55,720 these SAS products on top and the bold items are the items that would change. 579 580 00:39:55,920 --> 00:40:01,470 Notice here Docker for AWOL us and docker for Azure I didn't talk about those but those are Dockers 580 581 00:40:01,560 --> 00:40:07,380 opinions of how you should best run a swarm in those clouds and they give you templates. 581 582 00:40:07,380 --> 00:40:12,510 The Google Cloud ones in beta right now you can sign up I believe Tucker's Web site but the bold ones 582 583 00:40:12,510 --> 00:40:16,740 there are maybe choices you could make for commercial products that would accelerate your deployment 583 584 00:40:16,770 --> 00:40:20,840 by solving problems that you would otherwise have to solve yourself. 584 585 00:40:20,840 --> 00:40:23,530 Lastly here Dr. Enterprise Edition. 585 586 00:40:23,540 --> 00:40:30,620 This is what would change if you did Docker e on top of Docker for Azure or AWP s so Docker for Azure 586 587 00:40:30,620 --> 00:40:32,770 native U.S. or free from Docker. 587 588 00:40:32,780 --> 00:40:36,740 I mean obviously I pay for the infrastructure but there are templates are free and on top of that if 588 589 00:40:36,740 --> 00:40:42,560 you did Docker e your runtime changes to the official supported E version your layered your layer 7 589 590 00:40:42,560 --> 00:40:47,060 proxy and your registries and your gooey is taking care of for you so you can see how that stack is 590 591 00:40:47,060 --> 00:40:52,190 getting very very Docker centric and focused and so the fastest deployment honestly is just to deploy 591 592 00:40:52,190 --> 00:40:55,150 Docker e on Azure a w w with their templates. 592 593 00:40:55,310 --> 00:41:00,220 So if you needed speed if you didn't know also Docker e also gives you lots of other things right. 593 594 00:41:00,230 --> 00:41:04,490 You had the image scanning the role based access control image promotion we've all seen those demos 594 595 00:41:04,490 --> 00:41:09,660 in the keynote and the content trust. 595 596 00:41:09,730 --> 00:41:13,480 Garlic remember no life lessons. 596 597 00:41:13,480 --> 00:41:15,010 Don't shoot your food. 597 598 00:41:15,070 --> 00:41:16,420 This is nineteen eighty five. 598 599 00:41:16,480 --> 00:41:23,620 This is a hack and slash arcade game that the boom that gave you up to four players. 599 600 00:41:23,620 --> 00:41:24,120 Right. 600 601 00:41:24,130 --> 00:41:26,190 I'm not talking about this Ready Player One by the way. 601 602 00:41:26,230 --> 00:41:30,130 You need to watch that movie next year but you've got to read the book or listen to the audio book by 602 603 00:41:30,130 --> 00:41:31,600 Wil Wheaton before that. 603 604 00:41:31,600 --> 00:41:33,520 It's a great trip too through through the 80s. 604 605 00:41:33,520 --> 00:41:34,790 If you're an 80s fan at all. 605 606 00:41:34,830 --> 00:41:35,630 I agree. 606 607 00:41:35,680 --> 00:41:42,670 Your life is running so the cool thing about this game you could play this is for players or one player 607 608 00:41:42,700 --> 00:41:43,870 and it still was fun. 608 609 00:41:44,380 --> 00:41:50,080 OK so just because your friends run around you couldn't co-op together on this game doesn't mean you 609 610 00:41:50,080 --> 00:41:51,990 can't play it and it wouldn't and you wouldn't have fun. 610 611 00:41:52,000 --> 00:41:54,120 So the same thing with your orchestrator. 611 612 00:41:54,340 --> 00:42:00,080 Maybe I don't know what it's like throw all that out and say maybe you need to get containers and a 612 613 00:42:00,220 --> 00:42:04,750 production because the holiday season is coming and you promised your boss containers by Christmas. 613 614 00:42:04,750 --> 00:42:10,660 So what if you can't do container orchestration before then and maybe you have infrastructure that's 614 615 00:42:10,780 --> 00:42:11,680 fully automated. 615 616 00:42:11,680 --> 00:42:18,000 Maybe you use ESD and Amazon where you're auto scaling your VM and you put your apps in the victims. 616 617 00:42:18,070 --> 00:42:24,880 So I'm just gonna argue my own argument and say maybe you like the boundaries of a VM so do 1 v 1 container 617 618 00:42:24,880 --> 00:42:25,730 per VM. 618 619 00:42:25,960 --> 00:42:30,990 We don't talk about that really in the industry because it's not the coolest thing but it totally works. 619 620 00:42:31,000 --> 00:42:37,120 You could do this and change less of your infrastructure but it has lots of benefits. 620 621 00:42:37,120 --> 00:42:39,430 It means you can learn how to use Docker files. 621 622 00:42:39,430 --> 00:42:44,530 It means that you learn how to manage Docker in production and this is one container on that one VM. 622 623 00:42:44,530 --> 00:42:48,940 Obviously you're not getting scale out of out of your containers like all these containers in a single 623 624 00:42:48,940 --> 00:42:50,310 VM but your doorway. 624 625 00:42:50,320 --> 00:42:52,690 If you're not doing containers today then you're already doing this. 625 626 00:42:52,690 --> 00:42:53,920 So this is not worse. 626 627 00:42:53,920 --> 00:42:55,480 This is getting you better right. 627 628 00:42:55,480 --> 00:42:58,220 It's just not the full on orchestration. 628 629 00:42:58,480 --> 00:43:00,040 So this actually is happening right now. 629 630 00:43:00,040 --> 00:43:01,610 This is not a new thing. 630 631 00:43:01,720 --> 00:43:06,670 Windows is doing this with hyper v hyper v containers are basically one container in a VM. 631 632 00:43:06,670 --> 00:43:10,840 Linux is doing this with the until until clear containers initiative. 632 633 00:43:10,840 --> 00:43:14,850 That's a cool project where they're making making very minimal Linux OSX. 633 634 00:43:14,920 --> 00:43:18,880 This is also coming with the Linux kit. 634 635 00:43:18,910 --> 00:43:22,990 Well Linux hit does this today but this is actually coming with Linux containers on Windows which is 635 636 00:43:23,030 --> 00:43:27,760 alcohol is the sort way of saying that this is how you're gonna be able to run Linux on windows with 636 637 00:43:27,760 --> 00:43:29,080 very minimal OS is. 637 638 00:43:29,140 --> 00:43:30,810 That's just one container in one VM. 638 639 00:43:30,910 --> 00:43:32,160 So this is happening now. 639 640 00:43:32,170 --> 00:43:36,340 I'm giving you permission in your projects to say this is a legitimate architecture decision. 640 641 00:43:36,340 --> 00:43:39,520 You can just deploy that one container on that one VM All right. 641 642 00:43:39,520 --> 00:43:42,040 Last one this is a really hard one. 642 643 00:43:42,980 --> 00:43:46,410 Nineteen eighty three doesn't even have sound. 643 644 00:43:46,560 --> 00:43:48,370 All right dungeons of dragon breath. 644 645 00:43:48,550 --> 00:43:54,490 This is actually a 1982 game runs on a tier 80 and it was one of the first 3D games. 645 646 00:43:54,490 --> 00:43:54,840 It was. 646 647 00:43:54,970 --> 00:43:55,760 I mean look at that thing. 647 648 00:43:55,840 --> 00:43:58,390 That was a I was a decade before Wolfenstein 3D. 648 649 00:43:58,390 --> 00:44:00,070 They did not invent 3D gaming. 649 650 00:44:00,080 --> 00:44:03,680 In fact a decade before this was that there was actually a game that was very similar to that called 650 651 00:44:03,680 --> 00:44:05,510 the Maze war 3D. 651 652 00:44:05,680 --> 00:44:07,630 So anyway this was my intro to being a nerd. 652 653 00:44:07,630 --> 00:44:12,370 This was where I learned BASIC you had to learn basic by typing it in every time you boot the computer 653 654 00:44:12,370 --> 00:44:16,420 because there was no way to save it back then so you didn't have it look at a tape cassette that was 654 655 00:44:16,420 --> 00:44:18,360 actually a way you could save it. 655 656 00:44:18,370 --> 00:44:24,400 So anyway the summary here is trim the optional requirements from your project be judicious about getting 656 657 00:44:24,460 --> 00:44:29,560 your project tiny the first couple of projects focus on your Docker files if you're doing swarm then 657 658 00:44:29,560 --> 00:44:31,880 focus on your compose files as well. 658 659 00:44:31,900 --> 00:44:37,840 Watch out for your A.I. patterns and your Docker files so that they are clean as well as working well 659 660 00:44:38,230 --> 00:44:44,440 and then stick with the familiar OS and from images that you know grow your swarm as you grow in the 660 661 00:44:44,440 --> 00:44:44,980 project. 661 662 00:44:44,980 --> 00:44:50,020 You don't have to replace swarms you can just keep growing them and lastly find ways to outsource your 662 663 00:44:50,020 --> 00:44:51,490 plumbing or just not less. 663 664 00:44:51,520 --> 00:44:57,370 I lied and then realized parts of your tech stack may need to change because this is agile infrastructure 664 665 00:44:57,610 --> 00:45:00,350 so your best your first choice may not be your best choice. 665 666 00:45:00,400 --> 00:45:01,180 That's fine. 666 667 00:45:01,180 --> 00:45:08,140 Be okay with that and be willing to change things along the way and give me feedback on such an app 667 668 00:45:08,150 --> 00:45:09,150 and thanks for coming.