Going Docker, Swarm and Kubernetes Production Like a Pro • Bret Fisher • GOTO 2019

[Music] so you can get all the links references I will have little short links on key slides that have information so that you can just take a picture because I know even though put things are on the internet we all just like pictures so I do the same thing so the the rest of the resources and all that stuff will be there of course you can reach me on Twitter I'm looking up there when I have a hundred screens down here I don't know why I'm doing that and remember to rate at the end and ask your questions in the app and then we'll pick out some questions at the end and answer them alright so I've been doing docker talks for over four years I think I counted it up over 50 of them all around the world and it's to the point now when I talk about production it's like okay how do I cram all of that into 30 minutes right so I'm looking at you assuming that you're a developer oriented person with maybe a little bit of ops responsibilities or maybe you just work with ops in a DevOps like relationship so I'm assuming you're not full-time ops so I'm not gonna teach you all of the intricacies of a thousand node setup and stuff like that right so it's it's often a group of people that have to do all this stuff so let me tell you I am mostly an ops person but the more important thing is I'm a geek since the fifth grade the actual company stuff I do is I'm old so I've been doing a long time and I mostly do now courses on the Internet because I can reach more people more people like you so in this you actually get at the end I think yeah at the end I have a link for you to get that course for free not not necessarily to entice you to stay if you tweet me I'll give you the code but if you're here today then you're obviously just didn't docker so I have three courses we have our fourth on the way and I'm a container fanboy so really the first thing is warning all of your projects will have way more in them than you can possibly handle and your job largely ends up at the beginning talking about how to not do things so this is the same of all IT projects so this is my initial slide of these are all cool things but you don't and shouldn't do all of them at the same time so there are lots of solutions out there but doesn't mean you have to do them or should do them things that you maybe could opt out of right out of the gate when you're starting on containers or maybe you are doing containers but now you're switching to an Orchestrator is things like automatic si ICD dynamic performance auto scaling container izing everything all at once like even just in one app you could just container eyes may be the easiest part and leave everything else as is let that run for a while when I say awhile I don't mean a week I mean longer than a week and then avoiding persistent data migrations til later when you're a professional when you've got this all down and it's basically muscle memory then consider your your data unless you're someone who's like a data company which you've won you've probably already done all this and to you are probably moving data around a lot most of us don't upgrade our data platforms near as much as we do other things we're not pushing five the new deployments of a postgrads version every day so maybe consider that for later because you'll probably get less out of the benefit and it's a lot more work so anyway also warning we like buzzwords here so micro services are not required in containers I'm a great my great legacy apps all the time last year I migrated a 20 year old PHP app and it works great in containers it it's easier for them in containers because now their development workflow is a lot less arduous it's on a Bluehost which if anyone knows hopefully hosts is it's a small little company with 10 employees and they've been using an old server forever we just moved them into container world on a different provider we never had to change any code so those stories are out there about legacy apps and I just want you to know they're there if you've heard of 12 factor this still is even though it's a decade old a standard that works well in containers but you're never going to have it all done so just start now just try to containerize now mostly when your container izing the environment variables or the configuration for your environment is the only thing almost in every single app that I have to change but it's usually the only thing in most apps even if they're with really large really old or really slow I rarely have to change source code we usually just have to change the environment so don't let those get in your way so let's focus on some examples I'm going to give you some quick examples and we're gonna go through a lot of stuff so we're gonna start with docker files and images and we going to talk about operating systems then infrastructure and then a bunch of random stuff like security because security all right so these docker files are the most important thing to the success of your project because if you start it's like the wrong ingredients in a cake right if you start with salt instead of flour the cake will not work right so here if you have really bad docker files or really inefficient docker files this will not this will make everything else suck like kubernetes can't help your bad doctor files so it's important that this is also documented well so I prefer docker files with tons of rate of comments in them right about every line like just fill it up because all those comments like most building tools will just be removed before it goes into the image so it's not taking up space it's not a concern so we always document the crap out of that yeah and I study the official images because the official images from docker tend to be the most used you know they all have hundreds of millions of downloads and so and they do a lot of tricks some of them have fancy entry point scripts like my sequel databases it actually on startup will automatically create the user and the password and the database and all the things it needs but it does that in something called an entry point script and most people when they're first learning don't realize that all that stuff is there an open source on docker hub and you can you can pull from that and I think I still from it all the time stealing on the Internet is great as long as it's MIT so the official images are the ones I continue to recommend but there's a couple of quick I'm not gonna go through a ton of these because we could fill up a talk but the two that I see the most are versioning so people tend to use latest just when they're getting started but then they forget later at the should not do that so this look this first one up here oops I'm gonna hold on one second I forgot my pointer app this is always fun in the middle of a talk all right now I can get my fancy pointer mmm all right so how does he do it how does it work it's not a laser all right PHP right so we will pin it to the specific image version before any serious work happens right when the team is just done playing around and we're getting serious we'll pin that version and we stick with it but notice I'm pinning all the other stuff as well in this particular case I'm combining a bunch of things all in one image which may not be what you want to do but we're painting all the versions environment variables at the top so that way when I open the docker file I see all the versions of things in that docker file in terms of dependencies right up front so that's for apt-get dependencies but you also want to do this down here where when you're installing all sorts of little stuff you can do it this way where you're pinning this exact version of apt-get dependencies the reason this is really important and you may not even have been aware of this was before containers we tend to make servers and leave them alone but now you're gonna be making servers in the form of docker images every day constantly so it's more critical that these versions are exact now maybe not curl but curl also has vulnerabilities so yes maybe pin it because the curls vulnerabilities will fail your image scanner which we'll talk about later so you want all that and you want to pin those ver and that's you can see how easy at the bottom there it's easy to pin basically you just install them and then go discover what versions are there and then stick with those and hard-code them in and then when you start needing the checkup datum you can update them but again this is all in your source code right so this is in your get repo with your app so it's when your app changes this can change so it's lockstep with the app itself it's really important you keep that there because you don't deploy random versions of your app so why deploy random versions of your dependencies right all right leaving that default config config this is a good one for complex systems so elasticsearch my sequel postgrads all these types of data storage systems are notorious at eating a lot of memory maybe using a lot of i/o and they have settings but you can configure those and you can change the default inside your docker file without having to store a configuration file and then somehow get it into the image right before you go live or in orchestration you would use a config value so here this is a good example of a very simplistic way for me to basically echo and then it's a little it's very simple but it's the point is easy instead of requiring on orchestration to also store a config file and then make sure that always gets in at the right time and then having to store that somewhere else like that that's great for later but to get started this works great we did this for years without orchestration on a worldwide CDN platform so it works reliably alright people talk about vm's in bare metal this is mostly no longer a discussion I think it was early days but I kind of just put it in here anyway basically stick with what you do now it will work just fine it's not it will change the behavior of some of your apps so I recommend just spend a day or two even if you're not that person just spend a day or two googling around for how to how to track performance of your apps and you'll find often very easy performance tools that you can simply run on some servers throw some load at them especially if they're web services and get some results so then go to your old infrastructure run that same thing go to the new proposed infrastructure run it and look at the results so I have it's a little bit dated but essentially it's all the same but we did some my sequel benchmarking and we asked the question what if we did my sequel in a VM versus my sequel in a container in the VM versus my sequel on bare metal bare metal right what's the differences well it turned into like a third five page document of all the different things that you might consider but the gist of it is there is no tweet but the gist is measure performance it's not that hard it doesn't have to be super accurate if you're not an expert it just needs to be something but better than nothing and an S and that just of it was whether it's a VM or a container and a VM doesn't matter more less vm's is better and bare-metal is always awesome so if you can do bare metal especially for write intensive stuff it's always a good thing alright let's talk about the OS a lot of people think they have to change or should change their OS simply to do containers that's not necessarily true the when I'm talking about talking about your host level OS not what's in your container but the actual host level so there's still innovations happening at the kernel level and now that containers are so popular on Linux the Linux kernel has you know there are features that are being added and changes being added driven by the container community so it's important that you have a modern kernel this is a little less of an issue now because almost every distribution is on a 4x kernel which is actually been around a long time but older I'm gonna just say sent to West sent OS is one of the ones where they really lagged behind on the version of the kernel and just because docker could technically run on a 3.3 dot 10 kernel no one should be doing that anymore like there's lots of performance and we're weird quirks that people arrive at and almost every time I mention this someone afterwards will say yeah we run a 3.15 kernel and we didn't know and then we started having all these weird issues and they were random and then we just updated our host OS and they went away so I hear that a lot I don't have specific issues to point you to I just know that people get a lot better on 4x so generally if you don't care about your OS if you don't have an opinion I just recommend a boon too because it's got all the things out of the box it's long term support model all that stuff all right and container well OS is this is a common question people say hey should I also do like a container OS Rancher or something like that and poor OS those sorts of things and I think the right now I don't see anyone that I work with then I call these companies regular companies they're not Netflix and Google they're sort of the regular business that is not exclusively an IT business the total cost of ownership on container OSS is unclear we're not exactly sure if all the work you put into replacing your host OS that you're used to with this brand new thing is is worth the security is worth the change right away yep everyone has to relearn how to use it how to test it how to troubleshoot it and I there's not a lot of clear value in that yet so it's an interesting side project but I don't really see anybody using in production and I'm not even sure how long Rancher OS will even be around so all right and then make sure that you always have the latest docker docker has been released this summer the latest is 1903 and that is what you should be using it's the most stable if maybe you want to be super conservative last year's its 1806 their date based or 1809 rather sorry but a lot every one of the package managers I think still has old versions so a lot of people when they're getting started automatically end up with old versions of things and don't realize that they're on the wrong versions yeah okay moving on so now that we're talking about what's in your image right what's in the image itself what do you start from and if you didn't know all the official images you've probably tried or used they're all based on a minimal Debian experience and you can have other options on most of them they have one's called Alpine a lot of them also have something called slim so you have those three choices but you also see people making other variants and some people say hey I want to make my own custom boutique image and I usually frown on that because again they don't have clear there's no measurable outcome of that that I see that's a value people just want to do cool things but it doesn't actually yield productivity in the business so I say stick with the defaults there well tested and millions of people are running them and the minute there's an issue the internet will know so instead of your boutique thing stick with the default but the defaults are huge and they tend to be big so a lot of people say let's go to Alpine and Alpine is really really tiny and it is security focused by being minimal in the number of files that are at risk essentially they take out a whole lot of the stuff make it really small five Meg and to start and that means that there's less surface area for risk but it's new so there are lots of things that throughout the year I'll find quirks with clients or issues with things that are only being caused using the Alpine image and not the other images or we've recently found that CVE scanning doesn't really work in Alpine usually at all but sometimes half at best half of the security vulnerabilities so if you do security vulnerability checking or if you need to really alpine is not an option for you because it doesn't provide that completely yet the best you can get with it that I've seen and I just learned it this week is to scan it you'll you'll get flags for no thick let's see Alpine fixes for vulnerabilities but not vulnerabilities that Alpine hasn't fixed so that's a huge margin of error and and if you're a security person it will talk more about that later but you might want to care about that ok let's talk more specifically about that if you don't care so much about CVE in it or if you're not scanning today and it's not a requirement I think these are pretty much all the things I said and the yeah so enterprises may require other distributions so it might not even be an option for you I'm cautioning people this because I end up having clients that go Alpine and then we have to go back and so I'm trying to save you time not that I'm dissing Alpine because it's an awesome project it just has limits so these are sizes and this is the first reason that people get excited about smaller images who here has filled their hard drive with images on their local computer at least one of you okay like 30 percent 40 okay great you have filled your hard drive so we all want smaller images and I agree with you that's the goal but if you look these are node nodes images the slim okay that top one is slim and nobody uses slim it's like the long-lost brother nobody cares nobody everybody forgot about them and the the Alpine one there is a little bit smaller but if you have that much concerned but you're just space where a hunter meg is an issue then you just need a little bit more money to buy another hundred mega disk space because the reality is is these are all single instant storage right so these images will only be stored once per server perversion and so it's it's not a huge issue as an operator this has never been a problem to me I'd you know I just add another 10 Giga disk and the cloud or I ask someone not to provision me a little bit more disk and I'm good to go so and if I know up front what I have to do then I just provision ahead of time and plan for it whereas a lot of people will make this Alpine decision purely based on size and think that everything else will be fine it won't be alright so we're gonna talk about architecture and this talk has a spawn when this was three years ago this talk was called docker production then it was docker and swarm production and now it's docker swarm and kubernetes production so eventually it will be like five acronyms because we'll have all these different tools and I'll be talking about all of them but swarm the architecture of swarm in kubernetes at small scale tends to be the same whether you whether you like Dockers built in swarm which we talked a lot about in my workshop yesterday and people have been running in production for years and it's just fine for them and or you know people that are catching on the wave of kubernetes and and going there whether either by mandate or because of complexity or their vendors already support it or whatever reasons both of them tend to feel the same way until you start to get really like hundred servers kind of scale alright so for the swarm side I kind of break it out into three sizes and I call the first one baby swarm so baby swarm is one node and I actually have an entire list of why if you just want to use docker and you don't really think you need orchestration which is totally fine that a single server swarm is way better than like docker compose or the docker engine because it knows health checks it understands rolling updates it does lots of things that are more operations focused even on a single server and I'm sure all of us in some place in our infrastructure have one a single server doing one job right it may not be important but we've probably got something somewhere and if you got to run containers on it just run swarm it doesn't change your compose files really it makes everything easier and then if you need to scale out whether it's swarm of kubernetes you've got all the same paradigms you you know how to do health checks you understand the rolling update process you've practiced so then when you scale up to larger interested installations you're good to go right so you can start there small H a on swarm and kubernetes are both pretty the same pretty much the same you need three instances to store the raft database you have to know about all that but basically to have consensus and allow things to change and make changes to the infrastructure or to do rolling updates or health checks you always have to have at least three nodes doing management or we call it the control plane so the control plane has to be on three and in the smallest instance instances right you can do it technically on three most companies don't do this this is to me more about hobby projects maybe for your CI infrastructure you're just gonna have some load balancers pointing to the nodes and then you'll have different different containers running on each node based on the orchestrator and then that raft database is replicated across three that way you have redundancy so if one node goes down it can still do work still update containers still run health checks but if to fail and you lost majority that's when you are in trouble alright so this is kind of the minimum infrastructure that I look at now the nice thing is with you have to do this yourself you have to build five servers and you would make them all managers and that way too can fail so let's say you're doing a maintenance on one and then another one happens to fail you're still okay right so I like the idea of during maintenance I can still lose a server with kubernetes if you were considering something this small I would say cloud-hosted use a provider in the cloud AWS digitalocean Adger they all do their own kubernetes and you don't have to do something fancy like Fargate which is a little more expensive but they will in essence they will provide you the kubernetes management control plane usually for free and then you just provide workers you provide the nodes to do all the work right so the thing with swarm is you have to count you this yourself because none of them provide a swarm solution simply because it's just it's literally one line per server to make it so there's not a lot of value they can add there so with kubernetes the heart one of the hardest parts of kubernetes is getting the management infrastructure correct and secure and redundant that's still a very challenging part of kubernetes and there's lots of tools to help you with that because it's not easy so the clouds provide that as a value service saying hey I'm just gonna provide you an API endpoint you spin up a bunch of nodes and join them to the kubernetes cluster with swarm it's it's your do it yourself so you have to kind of design that yourself all right so beyond that if you're still building out swarm / kubernetes there the what you're gonna do once you get beyond ten nodes is you're gonna separate out the management control plane and you're gonna protect that put it in a back-end network and then up front maybe in the DMZ if we still call it that you're gonna have all your nodes all your worker nodes all right and that looks the same whether it's warm or kubernetes and with swarm it's a little simpler because the back five all run the same stuff with kubernetes the different control plane services are on different stuff on different servers so some of them not all of the stuff in kubernetes can run across five servers at once so all right yeah so workers in DMZ all right so the general consensus says everything beyond that is custom unless you're using a cloud provided solution where you're just giving it Cooper Nettie's is just giving you an API and you don't care how the cloud does it the rest of them it gets really complicated really fast and you need to be an expert you basically need to be a full-time operations person if this is kubernetes you need three people doing full-time DevOps on this cluster when you I think I have a thousand no I don't okay I wanted to see if I went ooh I did go to a thousand so that's that's it for infrastructure anything beyond that and we basically need to have a conversation about your infrastructure to design you a custom solution if you're in my workshop yesterday if you remember I her up a graph that had a thousand little points on it and it was looking really complicated it was meant to scare you into thinking that kubernetes was that complicated it's not it's just it can be if you really want it to this is a reminder that orchestration largely has its underpinnings in the DevOps movement which is largely based around infrastructure as code as one of its core tenants and infrastructure as code implies that we really shouldn't be treating our servers as special unique snowflakes that we log into and make our little home directory with all our scripts right because we all like that especially a sysadmin so we'd like to get in there and make things different so basically every time you have cessation to a server a panda dies that's essentially the rule there so don't basically you can do that if you have to but build as you're building out this stuff think about it in a way that if I can I throw away the server tomorrow and I'd be okay that's the question you should be able to answer can i if I'm building this now it's 2019 I should be able especially with swarm it's a little bit easier to do this with swarm than kubernetes I can throw any node away and if I'm in AWS the auto scaling group will just create another one now granted my apps also have to be fault tolerant so we're not forgetting about your apps but the server's themselves should be to be able to throw away there's nothing unique on any one of them as long as I have that h.a easier said than done I get it but public service announcement okay so a lot of people ask about reasons for multiple clusters is a popular conversation I have almost every time I talk about orchestration and really the the one answer that I think sums it all up instead of going through all of these is these are bad these are reasons you would not make multiple clusters is per region you you at a minimum need one cluster per region you cannot span any Orchestrator reliably over the globe so your that's what's called federation where you make multiple clusters in different places and then you federated with a higher level of abstraction okay so other things you can do in the same cluster very easily is have different kinds of hardware have different kinds of networks as long as they're I'd say within ten milliseconds of each other generally when we talk about this in the consulting and DevOps community of operations we talk about ten milliseconds it's not a hard line number but anything above ten milliseconds means it's usually outside of AWS is regions or a tzer's region and it's somewhere else and that you probably have a problem and basically all that means if things will get slow we technically did this one time where we built 4700 servers all running swarm at the same time around the world and everybody's different servers because someone put the join token on Twitter as an experiment and we said okay let's join as many possible servers to one container cluster at a time and then let's run 70,000 instances of WordPress and we did it and it kind of worked but it what the point was the functionality was there it was just latency was so bad that it making decisions and executing stuff across seven you know 4700 nodes that had sometimes 100 millisecond latency it really dragged it down it took minutes for any decision to even begin to make a decision on the servers so yeah geographical boundaries are a good reason I always argue for it no matter how small your shop is always have multiple clusters even if you're in one one data center and your one-person shop and you're the only person that cares about servers still have multiple clusters because you're gonna make mistakes I make mistakes and I don't want to make those in production the problem is is if I have a test infrastructure that no one but myself cares about it's not a good test right it's not it's not reliable enough for me to break it in subtle ways so I often use the IT department as my guinea pigs so you so you know maybe the CI infrastructure or maybe if you load up epics or PRS on to live infrastructure so that everybody can test it in real time while things are in development maybe that stuff is all on one cluster and so if I break it as the operator I've only affected you not our customers right so it's semi production I don't know what you want to call that but we tend to do that first and that way especially because I'm spending a lot of my time training people on how to run these things right and so I need to give them an infrastructure that will make them think before they hit the enter key so they don't know not just yeah it doesn't matter nobody's gonna see it they have to think but it's not gonna kill the entire company's revenue streams when they do it so so multiple multiple server clusters all right anybody here care about Windows I care about Windows I'm just asking it's not a negative connotation been a Windows server admin for decades it is a thing and it has been around since 2016 in terms of containers 2019 supports it way better so if you're going to consider Windows or if you have to run Windows builds because I know some people they build software that runs on Windows so they don't necessarily run Windows servers but they have to build use server 2019 it's the best one use the cloud instances because they're even better they they version them quicker than the named versions like this and swarm is more stable than kubernetes okay in general because swarm has been there alone a lot longer alright so now we get to the security stuff and my overwatch is reminding me that almost done okay so security stuff quick hits here everybody asked me about how do i lock - how do I get my security team onboard they're very nervous about containers and how do I lock this thing down because I assume it's full of vulnerabilities and holes and things that I need to worry about in general if you just take a nap out of an on container solution that's running on a native host and you put it in docker the defaults of docker are way more secure than the hosts alone it implements three main things in loot and Linux including the what you see on there the the Linux kernel capabilities it shrinks it down to like 44 from I think a hundred or something capabilities in the kernel app Locker and set comp are enabled which are not I bet enabled on your apps unless you know what those already are and you know that you you customize them so that thing already makes it better the next thing I would say is change the app to the non root user in your docker file does anybody know about this like this is a thing if you're a developer the MongoDB is fine that the my sequel it runs fine but if you're running you know node Python Ruby you know whatever those solutions their default containers will likely run his route and it may even be like in the node the node one they created the node user for you but they didn't enable it because a lot of apps will break so they don't enable it for convenience which I you know docker tends to dance between hard on security and easy to use so they dance in the middle there I think this was a decision that was maybe a risk because we have a lot of people running root when they don't need to run as root in the container so all you have to do like in the case of node is just type user and then node instead of app name and then your app will run as a regular user in that container not as the root of that container and what that really means is is if your app had a vulnerability and they were able to basically get into your app inside the container then they could act as root in the container doesn't mean they could automatically get out of the container it just means that they would have root permissions inside that container right so ideally do that and then the next thing is user namespaces it's not enabled by default and what that means is the root user in your container will no longer be the root user on your host okay and that means that if there's a vulnerability like we've had a few had a few were its kernel bugs its bugs in Linux that allow a potential user that's root in a container to break out of the container and that would have not happened if you had user namespaces turned on because if they once they got out the container there's still a regular user they can't they don't have full access to the host because they work they never had root to begin with and it doesn't work on all apps so tread lightly but test it see what happens it often is something you need to enable per server setting so you often would end up with separate infrastructure that has this enable and the apps that work run there and then everything else that doesn't work with user namespaces runs on other infrastructure that you don't have it all right and just check out that URL I've got like 20 other big things that are soup some of them are easy some of them are hard but it's sort of in an order of risk versus reward and you can check those up okay so you can take a screenshot of this basically scan everything tell your security teams hey look we're scanning code at three different levels it's essentially doing the same thing because they're all scanning four CVEs but you can scan whether you do a git commit you can scan while you're building images you can scan after the image is built your choice or all free if you have the time if you have the resources those are all open source tools I think some of them lead you to paid tools if you want more features but that's kind of that's a great advantage of containers is that you can easily now scan without having to you know literally the second one I think is like four lines in my docker file that's all it is and it scans every time I build four CVEs all right content trust this is something that eventually you will get to but your security team might be interested in you working with them on it where you're going to be signing your code then you're going to be signing your images and then you're going to tell your servers to not to only run images you sign and you can automate a lot of this you can you have to train your developers to sign code and commits I don't sign code sign commits rather and then you can as long as you have the right to Ling whether there's some free there's some that's not free you can have these different levels of authorization and there's even a term where we call it promoting the image so if the image gets scanned it gets validated it doesn't have any red red flags and then it's promoted to be allowed in production and then the server's will only run it even if it's you have multiple checks there in other words like the image won't be available but once it is some servers still won't run it unless that has a certificate on so that's all possible alright and I just as a reminder focus on outcomes not tools there's really three things that I look at when someone's asking me hey should we do this in our cluster my mind goes to the three sort of big things are you gonna get it if you do this are you gonna get a bunch of your time back are you going to have a mean time to recovery improvement or is it going to improve your deployment velocity because if either any of those things are true I like it let's keep talking but if it's not one of these chances are it's probably just neat or what someone said you should do and there's no real business value so then I'm gonna be like man let's put it off let's put that off till next project let's see let's look at it later right so no to everything else that's not a hard and fast rule but when I work with people I'm a geek some of us are geeks like we just like new stuff we just want to do that and so this is my quick head checklist on how to do that I did a show this week actually last week with Laura taco you used to work at the Jenkins company calcloud B's so she's done CI CD platforms for many years and we did an hour and actually here in Berlin no in Vienna you know where I'm at right now we last week in Vienna and so if you watched that video she talked about all what her team's use for metrics to make sure that their DevOps is moving forward the business not so much the tech itself but the business it's a pretty cool hour of chit chat okay this is all about if you want to go faster into production or if you're having problems with production deployments and it's taking too long the project itself what I mean is there's too much there's too many requirements in your project we got to do monitoring we got to do Prometheus and we got to do ALK and we got to have our customized centralized automated storage that moves around the cluster like magic if you if you have that kind of problem and a lot of my clients do when they come to me they've got this laundry list of stuff the thing that I tend to do is I tend to check hey is this something where there is already an outsourced product like there's a good market for it it's plumbing to me it's something that's just not super business focused it's more of a utility I'm gonna recommend they outsource it even if it means money because they're already spending money on all their people to do the open-source stuff so that's usually more expensive than the software products itself so these are the things that I look at can we outsource the image registry can we outsource the logging can we outsource the monitoring alerting if you're not familiar with those container tools there's a gigantic list that's super intimidating when you first look at it at the at the first URL the second URLs are more approachable and they also include open source the first one is sort of everyone who paid money to see ncf the second to our list of open source utilities plus products that solve certain problems we're not gonna have time to go through all of these but I'll just give you the quick rundown when you start talking about orchestration you're not talking about just the orchestrator you're talking about all these other tools that connect to it all right so if you're an absolute open source person which is fine but if you insist on open source then this might be a sample stack forsworn all right and even if you wanted to do the Alex is here he's gonna be in the next next talk I'm not sure what room he's in but he's gonna talk about open faz Alex Ellis and that and other tools but that is if you want to do functions on top of swarm or kubernetes so this stack is a lot of tools and not me not meant to scare you off but when you start your orchestration project it is not just I need kubernetes or I need docker Dugger swarm like there's a lot of other stuff that goes on there and that's where the commercial stuff is coming in so this would be that same stack where I choose to buy products or software's of service products instead of pure open-source all of these things will make it easier for me to do the project and get things into production it goes fast basically makes me go faster right it also takes less people to do it and then if you're a person interpret interested in dr. enterprise that is the one I know the best of the three main orchestrators that they call them container platforms now I think and so if you're interested docker enterprise desk swarm in kubernetes you can do them both at the same time one or the other you it's your choice and you can the blue lines are the things that are changing so now you have dakka dakka dakka and a lot of places that provide solutions and then it plugs in to a lot of the other stuff there the stuff on the right like the CSI calico that stuff right there that's all specific to kubernetes so when you when you get into kubernetes you end up with a lot of choices for every layer of the stack so they provide some defaults and then let you customize each layer as you go and oh and you also get all this other stuff if you pay for it so that's a mostly security focus stuffed the content trusts already talked about and then this is my last slide it's a little old it's a it's about a year old but in case you're choosing an Orchestrator I was like visual we all like pretty pictures so this is showing the size of the dot is their size of their market the placement of the dot closer to the topper right is where they have a better strategy and they're a leader in the platform's so the big three to me or docker rancher and OpenShift with red hat and then pivotal and is right behind them I feel like and basically that's pivotal VMware so they are essentially the same thing now as of a couple weeks ago so and then Mesa Sphere IBM sousei platform 9 or that sort of thing so if you're a business and you're relying on this infrastructure and you have servers your ops team probably already has other products that do this without containers right so you're probably going to want to move from a paid platform like Python up Python like chef or puppet enterprise right like those are platforms that big companies buy to manage their infrastructure they're probably going to want to buy one of these platforms to manage their container infrastructure instead of going pure open source we talked about yesterday that with kubernetes the last thing I ever recommend is doing pure vanilla open source usually buying a tool is the right decision for most companies if you're - if you're small or if you're super cloud focused and use what the cloud makes you makes for you right that they know it Barbee better than you do probably with kubernetes especially and then the last option is to build it yourself just because you can doesn't mean you should and kubernetes is changing rapidly still swarms definitely slowed down as it space kubernetes is still very rapid development so I I do this all day long and I get nervous about you know relying on just building it myself because I probably didn't do it right I probably have security holes and vulnerabilities I mean even Tesla left the password off their web dashboard and the internet took over their kubernetes cluster because they forgot to lock it down so if Tesla can't do it right maybe we shouldn't alright that's it remember to rate we have maybe three minutes for questions if somebody put in some in the app so yeah you

Channel: GOTO Conferences

Views: 15,663

Rating: 4.8742137 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Bret Fisher, GOTOber, GOTO Berlin, Docker, Swarm, Kubernetes, k8s

Id: 5zY5_iTGIsU

Length: 44min 35sec (2675 seconds)

Published: Tue Dec 03 2019

Reddit Comments

[u/mto96]

This is a 45 minute talk from GOTO Berlin 2019 by Bret Fisher, Docker captain, DevOps trainer and consultant. I've dropped the full talk abstract below for a read before diving into the talk:

Learn fast from my years of being a container consultant and Docker implementer. Come join me for a jam-packed session of decisions you need to make and key technical factors you should know. No fluff, all practicals. Updated for 2019 and based on my 3 years of top-10 DockerCon talks.

You should show up if:

• You are planning or involved with building/using a Docker production system.
• You are thinking of using Swarm and/or Kubernetes (but not required).
• You like random 80's/90's video game trivia thrown at you.

DevOps in the Real World is far from perfect, yet we all dream of that amazing auto-healing fully-automated micro-service infrastructure that we'll have "someday." But until then, how can you really start using containers today, and what decisions do you need to make to get there?

This session is designed for practitioners who are looking for ways to get started now with Docker and container orchestration in production. This is not a Docker 101, but rather it's to help you be successful on your way to Containerizing your production systems. Attendees will get tactics, example configs, real working infrastructure designs, and see the (sometimes messy) internals of Docker/Kubernetes in production today.

Session Topics

• Preventing scope creep in your project planning (what you can throw out)
• Easy Dockerfile anti-patterns
• OS and Kernel choice
• Container image choice
• Swarm and Kubernetes architecture designs
• Infrastructure layers to maybe outsource
• Infrastructure "stacks", layer the solution from low-level OS choices to high-level cluster GUI's