‫This video is my talk from DockerCon 2017.
‫I actually did it twice once in the US once in Europe at both DockerCons and a lot of this stuff still
‫is relevant today in fact there's very little of it that would change if I did it again right now.
‫So this details the best practices starting from hardware decisions all the way up through the OS into
‫darker versions into your images and then building out swarm clusters and how you design those and how
‫big should they be and what should be managers versus workers and all the details in between.
‫So I hope you enjoy this is the last session of the day and we've got the most excellently awesome Bret
‫Fisher who is also a captain.
‫He was one of the first cohort captains so he's got years of experience of Docker in production.
‫He consults and helps to get to production and this session is about what you need to know but also
‫what you need to decide.
‫So is this decision you need to make to.
‫If any of you are into light or if you're old if there are old geeks in the audience.
‫I don't mean in a nasty way because I am one real real old and real geek than you.
‫You will enjoy the theme of this session.
‫So take it away from me.
‫Thank you.
‫I get the honor of having the graveyard shift so thanks for coming and we're almost too happy hour.
‫So why are we here.
‫He lighted up very succinctly but we are here because you probably want Docker and production.
‫I'm not here to convince you that Docker production is a good idea.
‫You probably already decided that.
‫So this is about the lessons learned with consulting and with Docker and a lot of their best practices
‫about a lot of the decisions you need to make before you get into production.
‫Also you might be a old video game fan a retro videogame fan so I'm going to keep you a little bit entertained
‫with some trivia and I'm going to ask you for.
‫I'm going to give you some music and screenshots from classic games that were my favorites as a kid
‫and I wanted to yell it out if you recognize it.
‫So this is a little bit.
‫Audience participation and let's get started.
‫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
‫S.A.T. and I mostly do sysadmin stuff although I am a pretend developer as well.
‫For a long time now and the here's the list.
‫This is my resumé.
‫This is a list of all the video game platforms I had as a child up until like the early nineteen nineties
‫and we're gonna have some trivia.
‫So let's have some fun.
‫One street fighter.
‫That was good.
‫He's fast.
‫OK so this is this is me making poor analogies about HD video games and how that relates to Ducker.
‫So in the 90s I was actually a navy a school and in the military in the military we were learning mainframes
‫as well as pieces at the same time because let's just do both.
‫We had original hybrid computing and the cool thing about this game was when you were actually in school
‫you could actually get all your friends to bring it to you inside the room and play eight game players
‫at a time in a big tournament battle and we would declare the winning the crowned champion for the week
‫and then we would go back to studying our piece in pieces and mainframes and so it was a great time.
‫So I'm here to actually give you Super Street Fighter turbo advice on your project and maybe help you
‫make some decisions.
‫And that first problem is limiting your simultaneous innovation limiting your simultaneous innovation.
‫So this is my fancy way of saying scope creep scope creep.
‫So we all know about scope creep and I.T. projects.
‫Everybody wants everything in the first release.
‫And this is the same with your infrastructure.
‫So there's common problems that I see when I'm starting off with projects.
‫Usually I come in at the point when the client once Docker they've heard about orchestration.
‫They want all the things in this fancy orchestration because they spent 20 years building up their VM
‫infrastructure for 15 years and they want that exact same thing in the first version of their first
‫container and production.
‫So I'm going to give you some excuses for things that maybe you don't need.
‫The very first time you deploy production containers and one of those things is the ICD.
‫Even though if you have that today you probably don't have to do a lot to get it to work with containers.
‫It's not that big of a deal.
‫All of the CIA platforms now kind of support support containers.
‫So you're good.
‫But if you don't have CIC today you don't have to have that for your first container project or even
‫your second container project.
‫Don't make that a requirement and have to build up that infrastructure dynamic performance scaling is
‫another big one where people just assume that as soon as you get orchestration this magically causes
‫all of your nodes in your containers to magically scale up and down that's not built in.
‫And that's probably shouldn't be the very first thing you do because you're gonna learn a lot and you
‫need to have those learnings before you start trying to automatically scale this infrastructure.
‫And starting with persistent data is a really big one.
‫Don't make your databases the first thing that you put in a swarm cluster.
‫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
‫with.
‫And it's also probably not your most agile infrastructure right.
‫You're probably not upgrading your databases to a new version every month but you're probably deploying
‫new code every week or every day or and so you're going to get a lot more benefit out of your application
‫code anyway instead of your persistent data so legacy apps as we've been saying all week and all year
‫the MTA program legacy apps still work too.
‫One of my goals whenever we're working on a project with applications is to not change any code I would
‫say that the probably the most common change we make an application code is when there's assumed environment
‫pieces hardcoded into the app like IP addresses and code.
‫Obviously we probably know that that's wrong but in older apps you know like really old apps 10 year
‫old apps.
‫I see a lot of assumptions around specific IP or host names or certain environment variables that need
‫to be there and we usually have to pull those out and get those into environment variables.
‫That's really the only code we usually have to change.
‫Factor.
‫We all love you probably heard of twelve factor it's sort of an ideal solution it doesn't need to be
‫there for you to implement containers or even orchestration it's I don't look at it as it's done.
‫I look at it more as a horizon.
‫So your goal should be to learn distributed computing best practices and implement those over time not
‫necessarily all at once before you go to production and the I don't like that stuff delay you because
‫you're going to learn lots on the first day of production you're learn more there than the last two
‫months of the project of going production right.
‫Yes.
‫So this is the NHS and eighty five.
‫That was a long time ago.
‫But that game Super Mario Brothers held the title of the best selling game on a platform for 30 years.
‫That title and it was a big part of my life was my first console that actually had two controllers that
‫we could play a game at the same time.
‫So that was me learning how to be competitive in gaming before that a lot of the games are usually just
‫one player at a time.
‫And it also had a co-op mode that was really cool for learning what co-ops about.
‫So let's talk about some default power ups and how you might make your doctor files better and ready
‫for production.
‫So I always tell everyone focus on Doctor files first.
‫I'd rather you have those doctor files be really well tuned then some fancy orchestration features or
‫fully automated C ICD those doctor files are your new bill documentation.
‫So you're going to need to move maybe you have code and animal salt stack puppet whatever you need.
‫Shell scripts that stuff that you had before for building your servers that's in your doctor file now
‫and you're gonna need to comment it and put lots of documentation in that file and you're gonna need
‫to tune that file and in fact I call this the doc or maturity model of how you might go about starting
‫from day one of a doctor file to the production ready Doctor file because a lot of things obviously
‫just work in dev and not in production and with containers that's our goal right is that the things
‫that work in dev work exactly the same in production that was our whole go goal.
‫So we start with just getting your app to work and not crash which doesn't always work the first day.
‫So as you start this project and you starting your doctor files and you're basing it on official images
‫hopefully you're gonna get it to start and stay starting and stay working then you're going to focus
‫on your logs like getting the logs out of that container not putting them into log files.
‫That's an anti pattern.
‫And I see a lot people still doing that.
‫You need to be putting it in FTD air and ICD out and let Docker handle your logs let your offer your
‫orchestration handle your logs for you Please don't keep them in the app and also removes requirements
‫because a lot of apps have sub modules that are doing this fancy logging for them and now you can kind
‫of pull that out of your app and make that a part of your infrastructure then documenting is a big thing
‫to do next.
‫Maybe someone who's working on the doctor file for the team and you're going to need to give this to
‫someone else in the team to have them tested run it.
‫I recommend you have documentation in there about each area of the docker file.
‫Obviously those lines are pulled out before build time so it's not going to slow down your builds it's
‫not going to affect production of all the documentation in there and then making it lean and making
‫it scale.
‫So a lot of people focus on lean first.
‫They worry about the size of the image and I'm here to tell you your image size is not your number one
‫or number two problem.
‫I don't care how big your images because you're you're gonna probably want to use the official images
‫that you're used to.
‫If your service today are Ubuntu or S.O.S or whatever you're running make those that default images
‫on your first project.
‫Now eventually you can get to some super lean Alpine images that are fat Meg with only the binaries
‫that you built in go and that's all wonderful but you don't need that on day one.
‫You don't need that in your first container project.
‫I have production clients that don't have that yet because that image is single instant storage on those
‫host each image assuming it's a single Virgin is only stored once.
‫Even if you're running five containers from it and so it's not a big deal if you have a five hundred
‫Meg you know image or a 300 meg image.
‫So I wouldn't sweat the small stuff like the image size I would sweat more about the quality of the
‫docker file and then reducing the change rate.
‫So if you're build documentation is all based on apt get you don't want to move necessarily on your
‫very first Docker file to a completely different package manager in Alpine.
‫You would rather use the same build documentation had today it will work in the doctor file without
‫getting a dog or file and take that to production and learn all the lessons you're gonna learn there
‫and then make a sub a separate project later to maybe change to have something like Alpine like a reduced
‫image of reduced footprint for maybe for security or just friendliness of the image.
‫So and then make a scale right.
‫And taking that application and running it in multiple containers at the same time assuming it can if
‫it's a database probably needs has something like replication and all that stuff in the database layer.
‫But if we talk about Web apps or worker apps and stuff like that I'll make sure that it can scale out
‫because it doesn't always mean that just because it runs in one container that it will work well in
‫a orchestrator automatically with five containers.
‫Right.
‫There might be session state you're dealing with other issues with parallel
‫Sonic the Hedgehog.
‫OK.
‫So who remembers the 16 bit console wars.
‫Remember the 8 bit with a 16 bit it was a big deal and there was this fight between super and Tendo
‫and Sega Genesis and who's going to win.
‫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
‫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
‫queue chat from the 90s.
‫Yeah so.
‫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
‫to use my real name I don't have a handle.
‫So I ended up with Sonics various variations on Sonic the Hedgehog because that was my favorite game
‫at the time and he was really cool.
‫He actually it was so cool he had this feature where he would roll up into a ball and scream around
‫the screen loop de loops all over the screen.
‫And what happened was that you the player because I was probably like three frames a second or something
‫crazy slow at the time you as a player were no longer aware of what was going on the screen.
‫You were really just following anti patterns and you were trying to prevent this.
‫You were trying to prevent from hitting spikes or dangers in the road ahead.
‫So the only job you had was to make sure that you didn't hit stuff you were an anti pattern thing.
‫You were just that's all you were observing.
‫So this is my horrible analogy of how we're going to look at darker darker file into patterns for a
‫second and we're gonna hammer through these pretty quick and the first one I see is pretty obvious.
‫We probably all know about volumes now.
‫That's a new if not a new feature it came out a while back couple of years and I see people that accidentally
‫forget to add extra dark volumes for maybe their debug logs or air dump logs or something like that
‫that they forgot to put the FTD out or maybe they have a static file uploads from users or some sort
‫of caching files that they want to keep between loads of the app or something.
‫So you want to make sure that those are in volumes if you're using official images all the persistent
‫data stuff in there already has volumes for you taking care of if you're using latest please stop just
‫don't ever y.
‫Just never again ever type that word latest just don't do it do a version just if you're gonna make
‫a docker file even for testing just get in the habit of typing versions because it's muscle memory.
‫So when you get to the muscle memory of knowing the version that you're on right now and just typing
‫that in the front lines you'll see here that example on the top the PDP official one uses version no
‫similar right.
‫The second one there from your boot to it.
‫It's got us technically as assembler because it's on sixteen 0 4 but it's date based.
‫So you know that the packet the app get packages in there when they were actually put in.
‫So it gives you an idea.
‫These are also two examples by the way of when you're building your own images you don't have to do
‫similar of your own images you might do date based or commit ideas based.
‫But what I really focus on here is that the top example is showing the versions of the different apps
‫that I'm putting in that Docker file and I'm setting up environment variables at the very top so that
‫when someone or anyone of my team looks at this Docker file they can immediately know what actual versions
‫of those apps are installed they want to scroll through what could be hundreds of lines of Docker file
‫to figure out what version of node that we put in here.
‫I mean obviously you have things like packet package Jason and composer and stuff like that.
‫That's a little bit separate because that's in the app but this is all about those at those parts of
‫the app that are there just so your code runs and they tend to get lost in the docker file and you forget
‫to update them.
‫So in the second one you can see I'm pinning actually pinning isn't the right word for app get but I
‫am specifying the correct the right update version for some of my app get packages.
‫Most people don't do this when I when I first get into the project and I it's not hard to do.
‫You actually just can install the versions that you think you need or just install whatever's latest
‫and then find out the versions pretty easily with APP get and then just put those in your doctor file
‫not for everything.
‫Probably not for curl or other utilities you might need but for the ones that are particular to your
‫app and PSP is one of the harder ones because it usually has a lot of app get dependencies for your
‫PSP app so pin those versions because you don't deploy random versions of code so why deploy random
‫versions of the code dependencies.
‫This Docker file could be built daily every time you do a code commit which means you could end up with
‫random image versions of the of the of the dependencies and then if you're doing start to get the full
‫autopsy ICD you start having random little quirks like the Mongo database driver gets updated and suddenly
‫doesn't support your version of Mongo but you didn't know it cause your testing doesn't maybe test on
‫that version of Mongo.
‫So anyway I'm not bitter it happen to me I'm just saying pin your versions you can learn from me.
‫Default config is in apps like Pete well really all ask for PSP my sequel postgrad Mongo.
‫Java is a pretty good one.
‫A lot of people will not realize or conceptualize the idea that there this is infrastructure building
‫in the docker file and maybe before you were depending upon another team to set up your Java memory
‫limits or set up the proper my sequel config file those are now a responsibility of the docker file
‫or this they should be.
‫So this is a pretty good example of what you might do.
‫A better example is if you use the entry point script not gonna get into entry point scripts today or
‫how they work but they allow you to run a command before you do your CFD.
‫That could be a script that sets up your config files on the fly and if you actually go look at the
‫official images for my sequel or Postgres to name a few.
‫Those have entry points scripts in them that do all sorts of stuff before the database starts.
‫They create the default database they add the default admin password they set up a custom user for your
‫database they do all that and then the database restarts into the command.
‫And this is a way that you can solve a lot of these problems around not hard coding environments settings
‫into the docker build.
‫You really want to keep those out and in the actual runtime configuration.
‫And so this is something I saw in a project where they were building the same image over and over different
‫technically images for different environments.
‫So then they would just change the docker file to use a different Jason and then build a different image.
‫This is definitely an anti pattern because now you've got all these different images one per environment
‫and if if you've been in this industry long enough you know environments are infinite right especially
‫now that we have virtualization it's you know whatever you have in environments tomorrow it'll be in
‫plus one and so you'll be keeping all these different images and you don't want that.
‫So you're going to constantly try to be pulling out all those environments settings setting an ideal
‫environment of a docker file.
‫I prefer doing it in the docker file than having it in other files that later get imported because it
‫increases visibility.
‫So I always try to get as many of those environments settings right there in the docker file as defaults
‫and then I set them at runtime so that anyone who's looking at the docker file knows what the defaults
‫are.
‫They don't have to go digging around in some other repo or some other system for whatever that config
‫file might be for that application is a little tougher when we're gonna get more advanced dragon slayer.
‫Yes this is a pretty cool one.
‫In fact it was the first laser disc game and it was an eighty three Nova man when he was a laser disc
‫but it was basically a big city a very big city the size of a record.
‫And this is hand drawn art.
‫This is actually a game that was playing a movie while you were watching it.
‫In fact for me it mostly mostly looked like that because I was constantly dying.
‫It was a hard game to play and there was no cheat you couldn't look up cheats on the internet back then
‫so you couldn't figure out what the right moves were.
‫So dragon slayer.
‫It was it was actually a 50 cent game when the world was on twenty five cents per game.
‫They were like the one that they'd started this evolution of dollar games and two dollar chains and
‫all this crazy stuff now and we would all just stand around and watch it because it was like watching
‫a cartoon and it actually I think it was probably the one of most grossing games in a ten minute period.
‫I would basically lose a paycheck in ten minutes on this game because you would die every 30 seconds
‫and it was one life for 50 cents.
‫So it was pretty tough.
‫By the way if it was thirty five years later this game still looks fantastic.
‫You can actually play on your phone now and looks great.
‫So let's play some infrastructure dragons.
‫Let's let's talk about three big decisions that you probably to make if you're an ops team about your
‫infrastructure it's probably some of the most common questions I get on a start of a project.
‫And the first one is VMs or hardware like various VMs or bare metal.
‫And I say both.
‫I say do what you're good at.
‫Stick with what you're good at.
‫And then maybe an hour later project you do some sleep performance testing on bare metal.
‫You're probably better unless you're a few of us that really need the raw power of our metal you're
‫probably better at VMS today than you are using bare metal and dynamically deploying bare metal.
‫So if you're if you're on VM I would say later do some performance testing on bare metal at scale on
‫that not necessarily a multiple servers but on that server itself scaling up the number of containers
‫on that bare metal and seeing what the performance looks like.
‫You can do some really simple stuff with some really simple open source tools doesn't have to be complicated
‫or some tool you purchase.
‫In fact the beginning of the year it's a it's probably still relevant because as you know this is a
‫world the containers at the beginning of this year on 112.
‫I worked with HP and docker on we created a white paper and there's other white paper as well.
‫On that link there's two of them that talk about and actually show some basic performance testing that
‫we did and comparisons of workloads in victims workloads in containers and victims and then workloads
‫in containers on bare metal.
‫And it's not a tweet I can't just give you a one liner that says this is what you should do because
‫it's complex right.
‫It changes your IO patterns it changes your kernel scheduling so you're going to probably as you increase
‫density the number of containers in a VM you're going to have to care a little more about things like
‫kernel scheduling and kernel settings and network settings because you're gonna be loading up that OS
‫where maybe before you had one app in one OS and then one app and one OS.
‫So it changes changes the pattern so you have to learn a little bit as you grow the next one is about
‫your OS and the distribution.
‫So we're talking about Linux right now.
‫Obviously from wind if you're into Windows containers you get one choice.
‫That's a nice easy choice.
‫But if you're on Linux your distribution doesn't matter as much as your kernel.
‫The innovations and fixes that I mean Docker is a little over four years old now.
‫Containers have actually been affecting the future of the kernel and how the Linux kernel and the operating
‫system is created and deployed and all that stuff.
‫So you don't want to be running a five year old kernel version 3.0 10 is the minimum of Docker and just
‫because it's the minimum and it works doesn't mean it's the one you should be using.
‫Right.
‫I recommend a 4.0 X kernel and there's actually still a couple of distributions out there where if you
‫install the latest version you might get a 3.0 something kernel.
‫So you need to care about that more than you used to.
‫I mean Apache works the same way pretty much on every different distribution Docker does not.
‫Containers do not.
‫Right.
‫So I would say if you don't have an opinion just try Ubuntu.
‫I'm not playing favorites here but the thing about Ubuntu if you're not someone who's particularly passionate
‫about a particular distribution is that it comes with a 4.0 something kernel out of the box it has that
‫nice long term support lifecycle.
‫It's well documented on the Internet Docker tests that heavily it's one of the official Docker supported
‫distributions in the docker store or maybe try and vacate and Linux kit.
‫Now this one is a caveat because this one will delay your project if you are new to this type of building
‫your own distribution and deploying with Linux with infected if you not where it live.
‫Intricate those are extra additive things so I'm warning you now that that will not be the fastest choice
‫but it will maybe be cool.
‫So that will affect the length of your product.
‫It will delay it a little bit as you learn how Linux kit works.
‫There's been sessions this week on Linux kit and there'll be more tomorrow I'm sure at maybe summit.
‫Lastly there make sure that you get your distribution from the store.
‫The default distribution of Docker in your like an app get young all those.
‫That's not gonna be the right version for you.
‫I'm going gonna guarantee that because that's partly gonna be 113.
‫You know that's eight months old now 10 months old.
‫So you want the latest versions of Docker that you can get the latest stable is 17 0 9 from last month
‫and you're gonna get that through the store which ensures that Dr. built it and that it's not actually
‫different than what Doctor intended.
‫Which is actually the case with some older distributions in the other package managers.
‫Last one here is your container.
‫And we talked about this your container from image we talked about this your base image a lot of teams
‫end up having an intermediate image is what I call it.
‫So you have your base from the store or from a Docker Hub.
‫You have your intermediate that's maybe your standard for the team for no JSF.
‫You know picking your own standard of of that version and you're going to have some of that and then
‫you maybe have another image that you build on top of that you don't have to do it that way.
‫But if you're more than a few people in the team you probably want to set some standards going along.
‫It's kind of like the old golden image idea of a VM.
‫That's what you're gonna maybe do with an intermediate but I would say make it based on not the image
‫size.
‫Like I said earlier definitely based on what your VMs are if you're used to a particular distribution.
‫Just start with that distribution in your image.
‫It'll work it'll be great and then you won't have to change everything about your build documentation
‫when you convert over to your Docker file.
‫Yeah matching existing process and then maybe later again consider Alpine it is becoming a very popular
‫choice because of its 5 Meg size for the image which is pretty sweet
‫job's done.
‫Famous lines like jobs done right.
‫This is actually my intro into blizzard and my 20 year love affair with Blizzard started with that game.
‫I was actually lucky enough to be in the beta of the very first version.
‫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.
‫Like to actually enjoy it and that would that video the original piece that was not designed to play
‫video games I guess or not have at least anything other than a little crappy piece speaker.
‫So I think I've bought every Blazer game since then.
‫So yeah that worked.
‫Let's talk about swarm architectures now and this is really about the swarm layer the swarm architecture.
‫So we now know the OS.
‫We now know our images.
‫Let's talk about how we're gonna build that swarm out and I'm going to give you some very basic designs.
‫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
‫and how it works.
‫I'm not gonna go deep dive obviously into a swarm.
‫We had a great workshop on Monday.
‫There's a session actually before this with Laura Frank that talks about swarm and the internals of
‫raft and how consensus works.
‫So I'm just gonna give you some basic design starting with baby swarm and baby swarm.
‫As one note you can build a swarm on one node which can be your laptop.
‫It's just one liner.
‫Right.
‫We probably have all seen these demos we probably tried these demos.
‫It's a real thing and I want to talk about it for a second.
‫It's okay.
‫You have infrastructure today.
‫I'm sure that every one of you there is one system in your environment that is not highly available
‫that if it went down you would get a phone call write something somewhere.
‫It may it may be SGI system.
‫It may be just like some notification system for your ticket system or something else something that's
‫not critical to your business but you have that somewhere.
‫So run it on swarm.
‫Run it on.
‫Just do Ducker swarming it.
‫You get new features out of the box with it you get secrets you get config as you get services that
‫automatically are declarative so they automatically will replace themselves if they have a problem.
‫They can use health checks to make sure that they're available.
‫Those things you don't get with doctor run so out of the box we're fine let's do it.
‫The next option you might have is a three notes form.
‫Don't do even numbers not two notes forms don't do that.
‫At least for managers we're talking about the managers and if you're not super familiar with swarm there's
‫two types of machines there's workers which get the job done and there's managers that have the raft
‫consensus database kind of like an NCD server.
‫And in this case you're a very small project that's maybe a hobby project or a test project.
‫All the machines are doing work but they're also all managers so there also have a little bit more of
‫a security risk profile because they're storing the RAF database that has all of the control over your
‫swarm and that's the very minimum that will actually provide a fault tolerance and your managers the
‫next size up might be five.
‫This is what I would call the big swarm because this is what I recommend to small little scrappy startup
‫companies that they just want the minimum infrastructure for high availability and they don't and they
‫don't really they're not so concerned yet about security and providing boundaries around their managers
‫and they just want high availability.
‫So I recommend this because this allows you to take one node down for maintenance and still have a fall
‫tolerance because in this one you can lose two rights.
‫We got to have always a majority of manager nodes have to be up.
‫So that would be five.
‫From there we're just going to kind of make it up as we go.
‫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
‫instant size doesn't matter it was just that the graphic program I was using gave me those graphics.
‫So in this case I've actually split them out.
‫I now have my managers on sort of a secure enclave a different VLAN or a security group so that they
‫can all talk amongst themselves and control the swarm and then I can just make as many worker nodes
‫as I need to have.
‫OK.
‫And those worker nodes can be lots of different things they can in one single swarm I can have different
‫hardware profiles and different network segments different availability zones.
‫I can do all that stuff with those worker nodes and use constraints.
‫If you're not familiar with those it's basically metadata that allows you to tell a service that you're
‫creating for Docker that it needs to be over here with a SSD SSD or maybe there's a security profile
‫scanner you run on a particular server for PCI compliance or whatever.
‫Right.
‫You make it up VPN INS maybe something over a VPN you want to assign labels to those nodes and then
‫you constraint your work with that stuff with the constraints so we can scale this up all the way to
‫hundred nodes and it doesn't change a whole lot.
‫It doesn't it doesn't really change.
‫It's just more worker nodes and more places with more diverse profiles.
‫You're still using the same habits.
‫Maybe the instance sizes are bigger and you will have to scale your managers because your managers are
‫storing that RAF database in memory.
‫So as the work gets bigger and there's more work to be had that RAF database will grow and you're your
‫RAM MCP profiles on those managers may need to increase but they're very easy to replace.
‫You can bring one and take one out with a couple of lines.
‫The doctor files.
‫I'm going to give you a quick little warning on a soap box that please don't make your cattle pets.
‫A lot of people that are moving to agile infrastructure and I hate to use that word because Agile is
‫always overused but your your infrastructure with Docker has the capability of being agile.
‫If you don't make it pets if you don't start like downloading get you know get repositories onto the
‫host and you don't start doing special stuff on the host.
‫It can maintain if it's just build a server install Docker add it to the swarm and then deploy containers.
‫If you just keep it at that and you do everything either remotely through the docker API or maybe some
‫fancy shell stuff where you do stuff over SSD age but you don't actually store stuff on the harddrive
‫then that node is not special and doesn't have to be.
‫But I see a lot people that end up making like one of the manager nodes their box that they do all this
‫stuff on they have all these tools and then they install things with that get on the host and it's a
‫bad habit.
‫It's a habit we've had for decades.
‫It's just I haven't you got to get out of doing you can do all your troubleshooting and all your testing
‫in containers and in that swarm and that's great it keeps it out of being on the host so reasons you
‫might have multiple swarms.
‫This is a common question actually was also asked and dance session before.
‫These are bad reasons for multiple swarms you can do a lot in a single swarm there is no hard set limits.
‫We've tested thousands of nodes Docker I think has tested tens or 10000 or something I'm not sure what
‫their their top number is but these are all things that actually you don't need a reason you don't need
‫that reason to create multiple swarms.
‫Now if you have some of these reasons you you would have to create potentially multiple swarms like
‫I'm an ops person.
‫So I love the idea of giving the ops team the chance to fail before production so give that give the
‫opportunity for the ops team to have a real swarm that other people care about like maybe the CIA platform
‫or the testing infrastructure give the ops person or the team a chance to have that so that they can
‫learn they can make mistakes on swarm and accidently delete the database off the swarm or whatever you
‫know that people do before they get all the way to production because if this is your first product
‫and this is your first swarm you're gonna learn lots you're gonna make mistakes so it's great when you
‫can make them not in production right management boundaries the docker API out of the box is an all
‫or nothing thing and you've probably if you've used Docker a while even before swarm you know that it
‫doesn't have our back built in it doesn't do that role based access control out of the box you can do
‫that with Docker e there's other third party tools there's actually a plugin model that you can create
‫off on top of it but unless you add that layer it is an all or nothing thing.
‫So if you have a team that needs that sort of thing maybe you just decide you know that New York office
‫is gonna have a swarm and the DC office is gonna have a swarm because of management boundaries so I'm
‫going to throw real quick slide in about Windows Server 2016 because that is a really new cool thing
‫and swarm where you can have a hybrid swarm of different OS and I will windows this year right.
‫This is the year that as Server 2016 that's made this possible and it's innovating quickly so every
‫couple of months we get a nice new set of features and windows that expand the capability of it and
‫swarm and and docker in general.
‫So I will say that if you want to make a pure Windows Server 2016 swarm you there may be some potential
‫negatives of that just because we've had four years of innovation in containers.
‫There's all these open source projects on monitoring and logging and but a lot of that stuff is Linux
‫only.
‫So if you're a Windows shop I would encourage you to consider at least some Linux and your swarm so
‫that you can innovate with some of those neat tools out there in the ecosystem that maybe aren't ready
‫for windows there.
‫They're catching up to Windows right.
‫Also if you're I'm always license sensitive on windows and if your swarm managers are just being swarm
‫managers and that's all they're doing then maybe make those Linux.
‫And then you'd use windows for your windows workloads and you don't sort of spend a license on windows
‫just to be a manager sitting there making decisions.
‫So.
‫But you know obviously I could do that this is another hard one.
‫Explain as little user of music right.
‫Explain was a nineteen ninety three dos game and it was probably one of the first games that you needed
‫a mouse for like Wolfenstein 3D was around this time and all that.
‫It was the actual flight simulator in space.
‫It had.
‫You could fly every Star Wars craft eventually because they had lots of hazards.
‫This game was an addiction for me for at least a year to the point that I actually got my first store
‫credit at the Navy any X which is like the Navy Wal-Mart and bought Bose speakers to play the fantastic
‫soundtrack and I bought a stick of a controller for flights flight stick.
‫I basically spent way too much money that couldn't even afford it and I got a store credit so yay consumer
‫debt and that was the fault of that game.
‫So let's talk about outsourcing some parts of your swarm.
‫Maybe you don't need to do everything in-house.
‫Maybe you don't need to innovate everything so I'm gonna say like yeah.
‫Beware of the not implemented here syndrome.
‫Basically there is products out there for a certain part.
‫There's I mean obviously there's commercial products for everything.
‫You could just outsource all of this.
‫Right.
‫We have the cloud.
‫We have commercial companies.
‫But if you're going to do this yourself if you want to do it form yourself.
‫Dr. see then maybe there's some good parts out there that you can use that are easy to outsource easy
‫to exchange.
‫When I say outsource I mean like either a SAS or a some commercial product and image registries is a
‫really great comment.
‫That market is well-defined right.
‫There's good players out there they've been there for years log centralizing your logging and centralizing
‫your monitoring.
‫Those are all obvious to me those are obvious ways.
‫You don't have to go use all the open source tools because typically with open source even though it's
‫awesome you're usually trading free for convenience right.
‫So there is no truly free.
‫So these will accelerate your project if you need to cut timeline out of your container project for
‫grain production.
‫Look at these areas and there's also by the way a great URL for the CMC F. Foundation.
‫They have a pretty cool sort of like a visual diagram of the ecosystem so if you're not familiar with
‫all the logging players and containers there's a nice graphic there that'll give you their logos and
‫you can figure out maybe what things you need to consider their all right.
‫So really quick.
‫We're going to talk about tech stacks and that's why I don't want to call it.
‫But you know this is the building up from the bottom up.
‫What it might look like for you today and now obviously in six months we might have companies.
‫We will we'll have Cuban 80s as an option.
‫So these slides aren't Cuban ideas ready because I'm talking about today.
‫Right this is what you can do now.
‫So maybe at the very bottom you're deploying your infrastructure with for Kit and terraform wrong button
‫and then you're younger your runtime here is darker.
‫Obviously if you're using swarm your orchestration is Docker swarm your networking is the built in overlaying
‫of Docker swarm your storage maybe you're using Rex Ray which is a open source project that orchestrates
‫your your shared storage amongst your hosts.
‫That's a pretty cool project from Dell EMC Jenkins.
‫I mean just storing it is in there.
‫This idea of this stack here though is this is all the open source is pure open source everything yourself
‫on your own system or on a cloud system that you're deploying no SAS here.
‫Docker distribution plus Portis Portis is in a gooey on top of the free registry from Docker so register
‫if you just do Dr. Paul registry that's Dockers official registry maybe you don't want to use hub or
‫anything else you just want your own registry that's what that would be for your layer 7 proxy and if
‫you didn't know you're going to need one probably if you're into Web's web stuff at all you're going
‫to need to share port eighty and four for three amongst many containers that's going to need mean you
‫need a reverse proxy or layer 7 proxy same thing and flow proxy actually from one of the other captains
‫Victor is a really cool project that uses HK proxy and then traffic I think maybe uses engine X that's
‫another popular one.
‫E okay maybe for your love centralized logging I'm most you've probably heard of that.
‫That's another one that works with swarm centralized monitoring maybe Prometheus and Griffon Prometheus
‫actually controls the monitoring Griffon.
‫Is that gooey on top that gives you nice graphs.
‫And then finally up here partner would maybe be a gooey on top of swarm.
‫And one last little thing I thought I'd also throw in if you're into functions as a service open FAS
‫is here this week Alex is talking about you'll see open fire shirts that runs on top us form so you
‫can do your own functions as a service on top of that.
‫Now what I'm going to do is I'm gonna quickly show you what that might look like if you did some of
‫these SAS products on top and the bold items are the items that would change.
‫Notice here Docker for AWOL us and docker for Azure I didn't talk about those but those are Dockers
‫opinions of how you should best run a swarm in those clouds and they give you templates.
‫The Google Cloud ones in beta right now you can sign up I believe Tucker's Web site but the bold ones
‫there are maybe choices you could make for commercial products that would accelerate your deployment
‫by solving problems that you would otherwise have to solve yourself.
‫Lastly here Dr. Enterprise Edition.
‫This is what would change if you did Docker e on top of Docker for Azure or AWP s so Docker for Azure
‫native U.S. or free from Docker.
‫I mean obviously I pay for the infrastructure but there are templates are free and on top of that if
‫you did Docker e your runtime changes to the official supported E version your layered your layer 7
‫proxy and your registries and your gooey is taking care of for you so you can see how that stack is
‫getting very very Docker centric and focused and so the fastest deployment honestly is just to deploy
‫Docker e on Azure a w w with their templates.
‫So if you needed speed if you didn't know also Docker e also gives you lots of other things right.
‫You had the image scanning the role based access control image promotion we've all seen those demos
‫in the keynote and the content trust.
‫Garlic remember no life lessons.
‫Don't shoot your food.
‫This is nineteen eighty five.
‫This is a hack and slash arcade game that the boom that gave you up to four players.
‫Right.
‫I'm not talking about this Ready Player One by the way.
‫You need to watch that movie next year but you've got to read the book or listen to the audio book by
‫Wil Wheaton before that.
‫It's a great trip too through through the 80s.
‫If you're an 80s fan at all.
‫I agree.
‫Your life is running so the cool thing about this game you could play this is for players or one player
‫and it still was fun.
‫OK so just because your friends run around you couldn't co-op together on this game doesn't mean you
‫can't play it and it wouldn't and you wouldn't have fun.
‫So the same thing with your orchestrator.
‫Maybe I don't know what it's like throw all that out and say maybe you need to get containers and a
‫production because the holiday season is coming and you promised your boss containers by Christmas.
‫So what if you can't do container orchestration before then and maybe you have infrastructure that's
‫fully automated.
‫Maybe you use ESD and Amazon where you're auto scaling your VM and you put your apps in the victims.
‫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
‫per VM.
‫We don't talk about that really in the industry because it's not the coolest thing but it totally works.
‫You could do this and change less of your infrastructure but it has lots of benefits.
‫It means you can learn how to use Docker files.
‫It means that you learn how to manage Docker in production and this is one container on that one VM.
‫Obviously you're not getting scale out of out of your containers like all these containers in a single
‫VM but your doorway.
‫If you're not doing containers today then you're already doing this.
‫So this is not worse.
‫This is getting you better right.
‫It's just not the full on orchestration.
‫So this actually is happening right now.
‫This is not a new thing.
‫Windows is doing this with hyper v hyper v containers are basically one container in a VM.
‫Linux is doing this with the until until clear containers initiative.
‫That's a cool project where they're making making very minimal Linux OSX.
‫This is also coming with the Linux kit.
‫Well Linux hit does this today but this is actually coming with Linux containers on Windows which is
‫alcohol is the sort way of saying that this is how you're gonna be able to run Linux on windows with
‫very minimal OS is.
‫That's just one container in one VM.
‫So this is happening now.
‫I'm giving you permission in your projects to say this is a legitimate architecture decision.
‫You can just deploy that one container on that one VM All right.
‫Last one this is a really hard one.
‫Nineteen eighty three doesn't even have sound.
‫All right dungeons of dragon breath.
‫This is actually a 1982 game runs on a tier 80 and it was one of the first 3D games.
‫It was.
‫I mean look at that thing.
‫That was a I was a decade before Wolfenstein 3D.
‫They did not invent 3D gaming.
‫In fact a decade before this was that there was actually a game that was very similar to that called
‫the Maze war 3D.
‫So anyway this was my intro to being a nerd.
‫This was where I learned BASIC you had to learn basic by typing it in every time you boot the computer
‫because there was no way to save it back then so you didn't have it look at a tape cassette that was
‫actually a way you could save it.
‫So anyway the summary here is trim the optional requirements from your project be judicious about getting
‫your project tiny the first couple of projects focus on your Docker files if you're doing swarm then
‫focus on your compose files as well.
‫Watch out for your A.I. patterns and your Docker files so that they are clean as well as working well
‫and then stick with the familiar OS and from images that you know grow your swarm as you grow in the
‫project.
‫You don't have to replace swarms you can just keep growing them and lastly find ways to outsource your
‫plumbing or just not less.
‫I lied and then realized parts of your tech stack may need to change because this is agile infrastructure
‫so your best your first choice may not be your best choice.
‫That's fine.
‫Be okay with that and be willing to change things along the way and give me feedback on such an app
‫and thanks for coming.