 My name is Amy, so I just kind of wanted to get a general idea of what y'all backgrounds are. So, if you know what containers are, please raise your hands. Okay. So, if that's a, yes, I've heard of containers, but do I actually know what containers are? Can you raise your hand? Like, okay. Cool. So a lot fewer. And then also, do any of you work in DevOps? Can you raise your hands? Okay. Okay. Perfect. Then I think that I kind of like scaled my slides to be the perfect level. So my name is Amy, I am a software engineer at Rancher Labs, and I actually started working there in March. It's my first job out of college, and we are an infrastructure container management company. I also run a YouTube channel called Amy Code, so if any of you want to check that out, I'll probably do another version of this talk on that channel as well. And then also, I'll have these slides on Twitter. So in creating this talk at like 5 a.m. this morning, because I'm super great at procrastinating, Jeff last night told me that the theme was trust, which I forgot about, and then remembered again when he told me. So I was like, this morning I was like, how am I going to talk about trust? What the heck? I don't know how I'm going to do that. So then I was like, f that, I'm going to talk about lack of trust. So I'm assuming a lot of you here are app developers, so I know that a lot of you come from Turing school, so I'm assuming you do a lot of Rails apps. I don't trust app developers because I work in infrastructure, so the idea is that everything is ephemeral, and that we need to be able to kill your apps if things go wrong, and we need to bring them up again. So the theme of this talk will be the lack of trust, and Kubernetes. So the main question is, is like, you write this awesome Rails app, right? And now you need to get it onto the cloud. The core concept of the cloud, again, is that everything is ephemeral. Things die, things are complicated, lots of things need to talk to each other, networks go down, and this is all under sort of the topic of distributed systems, cloud, things like that. It's like pretty vague, right? So you put a lot of trust into folks who run your infrastructure, but do you actually know what's going on, and should you actually put that trust in folks running your infrastructure? So let's talk about what's actually going on behind the scenes. So the main aspect of this relationship is that we want our services that we use, you know, web application, things like that, to be always available, right? We want them to be accessible, and we want there to be low latency, so I don't want to wait forever for your page to load. And as application developers, it's not really your job to think about how to deploy these applications. So for instance, I don't know that you really need to think about things like high unexpected traffic, application failures, how to scale things, how to make things more available, how to make your resource utilization more efficient, right? So this is where containers come in. So what is a container? I'm going to simplify it to a point where I'm just going to call it a baby computer inside another computer, and that's like what it is. The baby computer is the container, and the bigger computer is the server. So why do we want a baby computer inside another computer, right? So the idea is that it's easier to transfer around, there's resource isolation, it's super efficient in terms of using these resources, and what the container does is it encompasses the application environment, and I'll like go more detail into that into my next slide. So a common like conceptual comparison is a virtual machine, and I hesitate to say that because they're very different. However, it's something that a lot of people compare that to in order to better understand what it is. The main difference is that containers are a lot more efficient, and a lot of other things you can Google that on your own time. Also you'll note that on the bottom in the gray I have like little Googling points that you can look up later on my slides when I post them up. Containers are ultimately a means to abstract away your infrastructure. As an application developer, you don't really want to think about your infrastructure, how your application relates to it, you just want to develop and make clean code, right? And so I'm here to handle the rest of it for you. So here we have a sample container, this awesome picture of boxes. So let's go ahead and walk through what's going on. So here you have your lovely app that you've developed. On your local machine you have a lot of different dependencies, right? You have different versions of Ruby, you have different operating systems, you have like a bunch of things installed that make your app work locally. When we try to deploy this to the cloud, right, it's like you can't have these inconsistencies, everything needs to be consistent. You need to test with different web browsers maybe, you need to test with different Ruby versions, different operating systems, and that's where containers are here to help. It's here to replicate these environments for you easily and quickly and in a easy to understand manner. So ignore the writing on the right and let's just look at the picture on the left. This is conceptually what's happening. You have your application, we have our container, we've defined different versions. So the first is an operating system, Alpine is a Linux operating system, 3.6.2. We've defined that we wanted to use Python 3.7, I'm actually a go developer. And then we have some maybe like setup scripts or things like that that we want to run to make this application work, right? So you all, when you deploy your applications locally and you test these things, right, you do this manually. So this is automating all of that. So on the right, this is basically what we're doing with our container. So on the top, you see that we have Alpine installed with Python in there, and that Python version is 3.7 because that's the latest version. And then we've copied, so that's work directory in ad, so we've copied your application to this container, and then we run some stuff on there to like set it up. I don't know what stuff you do, but whatever you do, you can put it in there. Then what we've done is we're exposing port 80 on that container to the world so that you can talk to your container. And then after that, you run your command to run your application when the container starts. So it'll be Python, and then it'll run the application. And so that's what's sort of like the core concept of what's happening within container. It's like easily replicable because you have this configuration file, and you can version control it on GitHub or something like that. Okay, so this is when containers sort of have this existential crisis because there's a lot that needs to go on to make these containers available on the cloud, on your servers. So you want to put this baby computer onto the server, onto the bigger computer. So it's complicated. Where should the container live? So this is under the realm of scheduling. How do I talk to other containers? This is under the realm of networking. How do I talk to the world? So how do I route traffic to my container? Do I have to think about load balancers? All these things like that. What happens if my container gets sick? So this is under the realm of failure recovery, right? Like what happens when all these things happen? Because you can't just like hard code your container and expect it to live forever on that one server. Infrastructure has changed. It used to be, I mean, this is before my time, but it used to be that you would sort of just like nurture this one virtual machine, and if it broke, then you would try to like nurture it back to life. And that's not how infrastructure works for Kubernetes. The idea is, if something dies, you kill it. It's kind of brutal, you know? Now that I think of it, just crazy. So this is where Kubernetes comes in. Kubernetes is a container-managed platform. And basically the way I think about it is we just have a lot of fancy abstractions to organize baby computers. And that's all that it is. There's a lot of terms that sound super complicated, but all it is is just terms to organize containers. Okay, so I'm gonna do like a walkthrough of Kubernetes so that you kind of have these core vocabulary to understand like future documentation or something like that. Once again, I'm gonna repeat the word ephemeral. Actually like I woke up and I was like, oh, I remember the word that I was like looking for ephemeral. Containers can be stopped, rescheduled onto different servers, killed, et cetera. They're ephemeral. The idea is that we can return to this state very quickly and we don't have to like finagle with anything to like make our app heal again. So this is one abstraction to organize containers. Some containers are really tightly coupled together. They need to like always talk to each other. Therefore they need to be scheduled on the same server. So we need to make sure that these two baby computers are always together on the same server. So we need more ways to organize containers, right? So this is where pods come in. Pods are a scheduling unit. They can have one or more containers in a pod and each pod is given an IP address within the cluster to be reached, right? So you have a bunch of servers and a bunch of servers together make a cluster. So for this IP address, it's important to note that you cannot reach to this IP address outside of the cluster. Pods can be confusing. You rarely have more than one container within a pod. So if it's too confusing for you to think about it as like having one or more containers in the pod, you can just think of it as a fancy container with an IP address to be reached within the cluster. A deployment, the next terminology, is another way to organize baby computers, right? The deployment is a group of pods. Here we have a concept of actual state and desired state and I'll explain that in a second. So what deployments do is they help make your actual state reach your desired state. So for instance, one characteristic is you can define the number of replicas sets. All that means is the number of that specific pod that you want running in your cluster. So the deployment controller will make sure that those number of pods are running. So let's say you specify three replicas, one dies or gets sick or is just plain annoying, you can kill it, right? But the deployment, what it'll do, it'll make sure that it spins up again. So when you kill it, there's two pods running and then the deployment will make sure that it reached the desired state that you specified to reach up to three pods. So the main takeaway from deployments is it helps you get from actual state to the desired state that you specify in configuration files. However, we still need more organizational concepts. So deployments were about actual versus desired state, but there's nothing really about like actually reaching a group of pods, right? So services, what it is, is it refers to a group of pods or deployments and has nothing to do with desired state. So here's the problem that we pose. Recall that each pod gets its own IP address. When they restart or die or get killed, their IP address can sometimes change. It's not like a reliable IP address to reach this pod. So it's unreliable. So let's say you have a group of pods, let's call them front end, and then you have another group of pods and let's call them back end. How are they supposed to talk to each other? How are they supposed to send information to each other? Like what is going on there? So this is what services solve. Services is a group of pods and it is a dependable endpoint to communicate. So for instance, we have service front end and we have service back end and they can communicate to each other via this endpoint called front end or back end or whatever you wanna specify it. I think here I call it service one and service two, whatever. And so I wanna like go back and kind of differentiate deployments and services again. Remember deployments, there's no endpoint there, it's just actual state versus desired state. Services, the grouping is there to reach a group of pods. Okay, so now everything that we've talked about so far was within a cluster. So there was no way for the outside world to really reach my cluster or talk to anything or like actually look at your web app. So what we have is called an ingress controller. So this is how we direct traffic outside the cluster and route it inside the cluster. So the way this works is for ingress, I'm able to specify endpoints and to which services I want to direct traffic to. So in this diagram, I have an ingress controller and in the ingress controller I've defined the endpoint foo and if I reach domain.com.foo, I will reach service A. And then let's like kind of pull everything together again. So I've hit ingress route foo, hit service A. Service A within service A have a deployment and that deployment has three pods that it'll keep on maintaining and running and over and over again. Okay, so all of these things that I've just talked to you about are defined in these complicated looking configuration files. However, it's not that complicated and I'm going to break that down for you here. So let's talk about deployments. Where is my mouse going? Okay, actually I can just walk over. Cool, so we talked about deployment before and here we are specifying deployment and in our specification we're specifying two replicas that we're talking about before. So that means that we'll have two pods within this deployment that we always want up and running. That's a desired state. Then we have things called labels which I'll get back to later. And then within our deployment what we want is to have each pod run an image called app image which is whatever your app is. And we're exposing port 80. So that's a deployment. And then you'll see for our service here we have the selector app. So what it'll do is it'll route all traffic to anything with the labels app, our app. And then it'll route from port 80 to port 80 on your container over there. And then for Ingress what's happening is is that your outside traffic is running to your service name our app which is specified here. And then the service port is port 80 which is also specified here. And then we will reach the, we will hit port 9,000 in order to reach your application. And so that's everything sort of tied together. And also these are all called manifest files but it's just more vocabulary. So I just want you to remind you that like all this vocabulary sounds really fancy but it's just the means to sort of like organize your baby computers. Okay so I kind of want you to ignore this slide and to show you that I feel like it's kind of complicated and unnecessary. So all this is is just to deploy each of those things that you saw before. And we'll sort of ignore this because we have a solution to this. So this is all great but how do we keep track of these EML files, right? What if we have similar deployments but they're slightly different? So if we wanted a different version of like our image or if we wanted a different number of replica sets. So this is where we want to version control our cluster or our deployment, right? And this is where Helm comes in. Helm is a package manager for Kubernetes. So this will like keep track of what state you want to deploy things in. So here we just sort of have this configuration file called a chart file. And this just defines the group of manifest files that we want to deploy. So if we go back to this file. So this image. Our chart will basically kind of like group this all together as one version. And then here's how we structure a chart. So what we do is is we have chart.EML is sort of this like metadata file to group together all of these files that we just saw before. And this is all within one cluster that we want to deploy within. And then all I do is do Helm install Amy demo. And then if I do Helm list, we can look at this our most recent deployment that we just did to get our app on the cloud. So there's a lot of awesome features for Helm that you can check out on your own time. So we can roll back to different versions of the chart. We can pull official charts that other people wrote with like cool apps that they want to run in the cloud. We can link charts. And there's a lot of awesome things related to Helm version control and Kubernetes. And thank you for your time. I had a question I was wondering about. A lot of times in these systems you're trying to like cut down on single points of failure. But it seems like there's always a single point of failure. Is that the case? Or are we progressing to a point where we have like federation and self discovery and such that there doesn't always have to be a boss that's like running everything? Yeah, I actually haven't like looked into federation but the, so if we like talk about the predecessor to Kubernetes Borg and things like that, that was Google's previous container management platform thing. I think they've made a lot of improvements to make sure that like if one thing does fail there's always a controller or something making sure these applications or containers are being spun up again. So in terms of whether there is a single point of failure in Kubernetes not really that I know of. So hopefully that answers your question. No? Yeah, no, I have more questions. I always have a lot of questions. I'm always fascinated by like, I'm sure like in the infrastructure industry there's always a lot of talk about Netflix and like what Netflix is doing to support 30% of the internet traffic in the world or in the US. The chaos monkey approach to like if you're not familiar they have a project that they run in their production infrastructure that whose job it is to go Brain chaos. And bring chaos by like killing processes and just like hopping across machines, across clusters and data centers and so forth just killing processes and making sure that things come back to life. Is this like insane? The future? You know like what? I think it's the future like, cause especially so a lot of this comes down to the person like architecting your infrastructure. So Kubernetes itself I think it allows for if you are, I don't wanna say good cause that's like not fair to say but if you're an experienced architect I guess you will make sure that there are multiple replicas and things like that of your system. In terms of chaos monkey that's just it's definitely important to like test to make sure your understanding of that system is right and also that your system is robust. I don't know if y'all have heard of Tammy Bouteau. I don't know if that's how we pronounced her last name but yeah she talks about that a lot. I still need to like go watch on her talks. So hopefully in the future we'll see. In, Sarah was talking about the olden days of like cobbling together our own houses with round bricks and poor mortar. When teams started to have ops and infrastructure people like dedicated to it instead of just like following some eight year old forum post for a wrong Linux distribution. Those teams would often say no. Infrastructure people they would usually say no and this was a big thing. I'm sorry, no to what? Everything. Like it was pretty much their job to say no and I remember there was a lot of discussion in like 2006, 2007 as Ruby was gaining some degree of prominence where it was like how do I get my infrastructure people to be okay with us deploying Ruby in production. And do you think like times have changed. I think the typical infrastructure team now has to support multiple languages, multiple frameworks and so forth. Are we getting to a point now where it's maybe gonna like swing too far? Like our developers just gonna be like all the languages, all the frameworks, everything's cool, put it in the container and then we're not hoarders, we're just collectors. Like is that fair, on track, off track? I don't know about that trend because it's like to containerize something you have to know about it. Like you have to know how to install it. All these things and the other thing is like I think the main thing that containers do is like it helps in terms of your dev workflow so you have these like testing environments to make sure like nothing explodes and it's like easier to set these things up without like needing someone in the infrastructure world to do it for you. In terms of just like containerizing everything that's definitely a thing. But I think it's like everything you just need to know about what you're doing. I realize that's like a very vague question. I mean a answer, but like yeah, I think it's just comes with experience and in terms of like knowing when to make or microservice that you need to containerize and when not to things like that. But yeah. If you're a person who's been on like the app dev side and you're curious about infrastructure, curious about containers and so forth. But don't know, let's say like any of the words that you've said so far. And I don't know about running Linux. I don't know about ports and all these things. Like how can someone follow in your footsteps and learn all these things. Yeah. So like the way that I got ramped up at work was, okay, so you have your app, right? So the first thing that you want to do is stick it into a container and then, but how do I do that, right? So how do you do this locally? Do you have to like make sure you have a specific language version operating system? And then what you do is then you translate that into the Docker file. Make sure all these installations are there. If you need to run any sort of like configuration type of command sort of thing, I can all go in the Docker file. And then after that, what you do is, I guess you can learn more about Docker compose. It's kind of like a tangent, but it just, it makes life easier. I like looking at configuration files more than like running command line things. Has anyone ever said I like looking at configuration files? That's how I know you're an infrastructure person. I am very much, yeah. It's like, it's funny because it's like, I know nothing about front end development. And like, I wish I did, because like I don't have a personal website and I need to get one. It's probably just gonna be plain text, but. And then after that, what you can do is try to get your app up and running in Kubernetes. If you don't feel like running an app specifically for this, like a hello world thing, you can just try like Nginx, getting a web server up there, and then they'll have like a default, like welcome page or something like that. And there's a lot of tutorials online in terms of like how to do this, a lot of explanations and videos and things like that. You should definitely look up. And also actually, KubeCon is in December and they're offering diversity scholarships for people of underrepresented minorities if you're interested in going. I'll also be speaking there. And I'm really excited about that. And I like freaked out yesterday because I found out like while I was on the plane. But yeah, so those are like some ways that you can, yeah. Do you have a favorite hosting platform for like playing with Kubernetes in containers? I don't think you need one. You can just try Minikube. That's like something there for you to do locally. So it's mini and then Kube, K-U-B-E. But in terms of, cause like the thing about containers is like the idea is that your host doesn't matter cause like you're running a Linux container and a Linux container is the same on any like cloud platform. I usually just use DigitalOcean because that's what my company has. Sometimes I use Amazon EC2 instances. But yeah. So that Kubernetes when like container gets sick the job is to kill it or then roll it back and spin it back up. Are there a way to find ways to determine what the stick is in that case? Yeah. Like if it's sick because of an outside dependency rolling it back with the help. So what does it do in that case? Yeah, so what gets sick means is like so there's this thing within Kubernetes called health check and what that means is there's an endpoint that you can ping and it'll return yes, I'm healthy or it won't return anything which means like something went wrong. So there's like a timeout of the other thing waiting for it or it'll say I'm sick. Like it'll tell you that something's happened. And then that's when something like outside of that pod can respond and kill it or something like that. I forgot the second part of your question. If it's sick because of an outside dependency like it was reliant on the baby, it was talking to rolling back with the help of what Kubernetes was doing that security. It would probably just keep on trying to kill it. And just like wait, yeah. So yeah, like the idea is, yeah. So hopefully you are trying to put as much as possible within your cluster that like it needs. And if it does need an outside dependency try to I guess make sure that thing works a lot of the time. It's funny because it's like this is unrelated to containers but like it's funny how much of our infrastructure depends on GitHub and like how often it goes down and when it goes down how much of our productivity just gets killed. And it's like that's why like massive companies like have their own version control system but it's just like it's funny that like at that point of failure could like kill off an entire coast of productivity. It's crazy. One of my favorite tweets that I've seen the last couple of years said think of the poor bastards that have to fix Stack Overflow when Stack Overflow goes down without Stack Overflow. Yeah. Yeah. Cool. Thank you very much Amy. Thank you. Thank you.