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