Deep Dive into AWS Fargate

okay we ready wow I'm actually louder than this morning okay well hopefully we'll be in a little less of a hurry too because I'm not trying to squeeze everything into a into a shorter time so welcome back this is a deep dive on AWS Fargate i'm abby fuller I work in developer relations for AWS - the person that just tweeted at me that he's on the abbey Fuller truck yes it's awesome I love it uhm so this is far gate let's see if I can get my clicker to work okay we'll use my laptop clicker instead okay so first things first - who here is new to containers who years running containers in production yeah okay so thanks I'm that could that comes up for me a lot is not only why are people using containers but also why are they using these orchestration tools and then I think someone asked a really good question after the session this morning which is so I'm using containers already and I don't understand why I need another tool to help me do that why can't I just run the containers myself why can't I just stick them on the host and kind of hope for the best so with containers I think comes it's it's more than just the basics right it's more than just kind of making this container and sticking it on an ec2 instance somewhere and hoping for the best it's it's a lot more it's about how many of them you have running where they're running how much resources are using how do you deploy them how do you manage them how do you scale them how do I have something that keeps me on track when I say I want a minimum of two and I want a maximum of 25 what keeps track of when you should have 2 to 3 and then 3 to 5 and then 3 to 25 what tells you when to stop what says hey I'm out of resources and I still need to place more containers to meet my minimum what do I do now so that's where people are really turning to things like like orchestration tools and containers themselves are really powerful but there's not much to them all they are is that wrapper around the process there are you're using you have your libraries your binaries everything's all in that one little piece and you're seeing two people move to these containers because it's enabling to do something that couldn't necessarily do it in the same way before right that they had to previously if you wanted to play your model if you have to have one server for each copy of your monolith that makes it slower to scale makes it a little bit harder to work with you end up with what people used to call like spaghetti code right which is where all the pieces are all intertangled and that too to change one piece you have to change all of the pieces effectively because you can't separate kind of function a from function B and that's thing that people were really able to solve with micro-services so you have one function has one job and then you can scale all those pieces independently but you don't really want to be doing that all by hand right you don't want to be scaling up your services by hand you don't want to be deploying them by hand you probably want some sort of automated process to help you and that's where our orchestration tools come in and I think the way it started was was first and in the 2012 you had the the Col like docker on AC 2 story where I ran docker myself I kind of managed all the pieces myself then people said you know what this is too much work also I really like docker I really like the format that is containers but it's still kind of a lot of work so me Bill TCS and people like TCS and then there were some folks that said so you know what ECS isn't necessarily what I want to use I want to use kubernetes so now you have the same version of that story with with kubernetes on ec2 people are running a technology that they're that they're really behind but they don't want to manage all the pieces themselves so what you're finding really is that the orchestration tools are not quite hitting it for everyone they're they're helping and they're solving some problems but they're not solving all of the problems so today we're gonna focus on Fargate so far gate is is pretty much as close as you can get to the people that asked me in between sessions today to to kind of containers on demand so far gets available and in four regions now it is us ds1 so Virginia it's in it is in Dublin it's in Ohio so far gate no infrastructure so it removes the the bottom piece of this right so you focus only on your containers and your tasks you don't focus on the infrastructure at all so launched really easily scale really quickly you manage everything in a way that feels to me kind of limb to ask right you define everything at the container level instead of Linda's function level and then you don't do anything with the underlying resources you don't do anything with the underlying hosts this is my favorite Fargate quote and says when someone asks you for a sandwich they aren't asking you to put them in charge of a global sandwich logistics chain they just want the sandwich and PS the sandwiches Fargate right so I don't want to know how you make cheese or where how do I sliced turkey the right way or who grows my Tomatoes I want to just eat the sandwich and to me frog a this is that sandwich right is that there was still problems even with orchestration tools that I'm trying to solve so remember this managing a production infrastructure can be can be really a lot of work because beyond kind of the orchestration piece there's still a lot of hands-on pieces that that go into that and something like UCS makes it makes it a little bit easier so you see the the top level here ECS takes that part the scheduling and orchestration and the cluster manager and the placement engine but what do you CS doesn't take over is how do I provision the all of the nodes that belong to my cluster how do I'd go about making those nodes work in a way that works for me so like packages that are installed in the hosts how many of them I have when do I need more when do I need less for gate lets you focus on your application so I had a really nice a nice quote from someone on Twitter yesterday where he said our job is X and for them they're working with currency but anything that's not directly focusing on this the currency things that we're working on at work I don't want to have to think about that because it's not directly supporting my job and that's kind of the way I think about forget to write which is that it just lets me focus on what makes me different on what makes me special it just lets me focus on my application instead of all the pieces that go into it so instead of provisioning ec2 instances just to run my container based workload all I have to think about are the containers so what does this look like in practice if you've seen any of my talks before you might have seen this and I keep trying to make it prettier and then I keep giving it up because despite my best it's I'm not a graphic designer so someday someone will take pity on me and make a a prettier version of this but this is what your choices end up looking like on an AWS so you have the Amazon container services which have previously also been called dcs which I realize is confusing because everything is kind of called DCs but we're gonna sort it out so your Amazon container services and then your first step is you pick your orchestration tool so that's ECS which is the Amazon version or in the preview or once it's in GA that's eks so you're picking UCS or you're picking kubernetes and then after that you have a second step and that's your launch type and the way to think about launch type in this case is how much control do I want over my infrastructure do I want to manage everything down to the cluster hosts or do I only want to manage my containers and that's what that far gate level is so from ECS and eks I'll be able to choose either ec2 which is the traditional way so manage your cluster infrastructure or you can choose the Fargate launch type which don't manage your cluster infrastructure only manage your containers so I think the best way to look at Fargate honestly is by jumping back to ec2 mode for a second so the traditional way of looking at ACS so how do these pieces map back to the technology that I've been building with my monolith for a while now so an instance is just a regular easy to box so once I register it to my cluster that's where all my tasks run a service is that layer that manages in places the task a task is that wrapper and configuration around my process so ultimately that's my container process plus some docker options like the amount of privileges or the flags or some variables or something like that so in ECS you're responsible for all three of these pieces you're responsible for provisioning the in the instances you're responsible for writing and defining the services and you're responsible for the tasks themselves instances you can configure either just through the base ECS optimized ami or you can bring your own or you can do it I used to do and configure it through ec2 user data like you would any other virtual host everything else gets configured through the API so you can either access that directly through the console or you can go through the CLI tasks LAN to task definitions Tanner's blonde - container definitions and so how compute works is pretty flexible you bring your own instance type you can pick any combination of resources you like works with things like GPUs reserved instances spot instances and good stuff like that so a lot more flexibility but also maybe a little bit more thought that goes into it right so you have to choose instance it works for you you either use UCS optimized ami or you can make your own but you're responsible ultimately for provisioning and maintaining that underlying cost or infrastructure Fargate a little bit different so you use a lot of the same building blocks so the same task definition schema so the document that defines where your container comes from the resources that it used uses the name of the family that it belongs to you use the same kinds of AP is relatively easy migration so you can run them either side by side in the same cluster or you can switch back and forth which we'll talk about a little bit later and it shares primitives with things with VCS so primitives it means kind of AWS integration side of things so V PC or I or I M or cloud watch or cloud trail those are all used the same way in EECS mode in ec2 mode and in Fargate I removed a checkbox here though so in frog game mode I'm not responsible for the instances themselves the cluster happens on the Amazon side I'm are still responsible for services and tasks and that's how I define what's running so the containers that I'm using and all that good stuff instances are not configured by you but everything else is exactly the same right so you're still using the same definitions which means that I can switch back and forth a little bit more easily and some of the differences in this case might be that I changed my launch type and with Fargate we'll talk about in a second but it's a different networking mode so some things to keep in mind so some differences but ultimately it comes down to the launch type and requires compatibilities and you can switch back and forth or run them side by side in the same cluster compute works a little bit differently too and so forget you get 50 ish combinations of CPU and memory so not quite as flexible as ECS doesn't work with things like reserved instances or spot instance right now you're not responsible for that pool of compute you just pick the combination of compute that you want this is the number one most popular question I get other than maybe how do I get into e KS preview but the the number one most popular question is okay so you have e CS and you have Fargate and how do I know which one I'm supposed to use and I think that the short answer here is it depends on you and it depends on what you're doing I think the the better way to look at it is how much control are you looking to have so if I I didn't have far gate around when I was working with with ECS in production but the way that I would do it now is I would probably start with far gate because I have to control and kind of fuss with the least amount of things and I would move to ECS if I needed a level of control that I didn't have in far gate for example if I wanted to build around reserved instances or spot instances I'd use DCs I'll talk about some more of the differences but ultimately it depends on you and I think ultimately what it might end up looking like for some people in production is running both of them side by side so tasks that you don't kind of need much customization on will be running in Fargate mode and tasks that you need something like a sidecar container process or a daemon process running on the host those tasks might stay in ec2 mode so I think it can look really successful to have both of those running next to each other in the same cluster a couple of the differences so obviously the change in networking mode and we'll talk in more detail about AWS PPC and they specify container port there's no host port no links only the local loopback which we'll also talk about but that's 127 0 0.1 or localhost no support for ELB classic only alb or NLB and windows container is only on ec2 right now not in Fargate mode so this is what requires compatibilities is that basically lets you either say this containers for for gate this containers for ec2 or this container is for both you can have both and you can use it to switch back and forth promised a little bit of a networking and promise that if you're not into networking we're not going to go into a ton of detail but I think it's really important right when you're changing your networking mode that you know at least a little bit about what's going on so hopefully it's not so late in the day that everyone gets sleepy when we talk about networking but we're going for it so two kinds of networking that we're going to talk about today so local networking and external networking so local networking means that on a single it's easy to instance to components can communicate with each other via the local loopback interface so again that's one 27001 or a local host that means that you don't have to go through a networking interface like Annie and I you could just communicate directly on that host so that's local that's local networking we're gonna talk about how that works in Fargate external networking means how do I communicate with services that are not part of that same host so in ECS and Fargate that means tasks that aren't containers that are not part of that same task definition will be on different hosts that also is the same way that you communicate with an external service like a database so that means that traffic is most likely routed through your V PC and your subnet you get two kinds of subnets either public with an Internet gateway or private with no internet gateway which means that your traffic is routed through a NAT so network address translation so in traditional dock our networking of three ways to kind of to handle this whole communication process the default is bridge doctor zero that's the default containers are on the same network and these IP address local containers can communicate with - - link none means no network interface only the local one host Maps directly to the host network so the good news is is that there's now a fourth type that we made because we didn't like the other three so we made our own and this one is AWS VPC so the way this works is that with AWS VPC each task is allocated an en I so that elastic networking interface so containers that are launched as part of the same task can still continue using that local loopback and then with that en i allocation comes a private IP or if you're using Fargate you can use the public IP if you want also but those tasks can communicate via the en I because it's directly it's a it's a one-to-one mapping so it simplifies your container networking makes things a little bit more straightforward that is currently the networking type on Fargate so if you want to use Fargate or if you want to use ec2 mode and switch back and forth you'll want to look into the AWS PPC mode because that will be required I think it's a good thing by the way it's always a little annoying I think to change your networking type into networking that's not everyone's favorite topic I like it but not everyone's favorite topic but it enables some really cool things because what it's doing is it's moving networking from the ec2 level down to the container level so you have a mapping between your tasks and your networking interface which simplifies the whole networking stack that you're using which is a little annoying to set up but incredibly powerful and it simplifies things in a way that enables you to do a lot more because you have that mapping so if you're looking to learn more about this I included some links for you about how it works in Fargate and also just how AWS VPC mode works in general a couple people have asked how to get the slides and they'll be posted by Amazon and also I'll post them myself on my speaker deck account as well so if you're looking for the links and you were not fast enough to take a picture that's okay the links will be in the deck so a couple of frequently asked questions so that if this was your question you don't have to wait in line and ask it afterwards number one can I have both ec2 and Fargate tasks yes so you can either run a hybrid cluster or you can switch back and forth tasks can definitely be compatible with both another frequently asked one is how do I exact into a far gate container short answer is that you don't exact requirements and is H does that does not work in Fargate you kind of have two options here so one and I sort term solution is that I would stop the Fargate container and then flip it back to ec2 mode and then I would exec and I think that brings kind of a bigger discussion up and that's why do I need to exact into the hose into the into the container the same reason and why do I need SSH access and I think in a lot of cases that's just the tool that we've been used to solve a problem which is that I immediately need access to a process that's not behaving the way that I expected in this container so I want to get access to it right now and see what's currently happening right this very second so I'm not sure this it end up looking like or who will end up building it or whether it will be an open source tool or an in-house one but what I'd like to see instead is a is a more long-term solution to that to that question which is how do I get immediate data from a container without necessarily requiring access to the physical infrastructure and to me what that would look like is some kind of tool that I could use to attach to a running container so I could see the process running the logs running the the output of whatever the container was what the status was so that I could debug something on the fly without needing actual access the other solution is in the interim which is that I'm not sure everyone is sad about is that if you're logging directly from your container to somewhere else you're probably missing logs and you're actually probably missing the important ones because you're missing what happens when your container dies so what happens when your container dies and you didn't expect it to but your logging is going directly from your container somewhere else your logs are now gone because your container died before I could ship those logs off somewhere else so what I used to do is pull all the logs off somewhere externally first so instead of shipping them directly for my container maybe I map to something like var log messages on my hosts and then I use a collector container to send everything back up which means that even when my container dies I've gotten all the logs because I was not dependent on my container running properly in order to get them if you've worked with the the Fargate first run wizard the number one question is why can't I use my own VPC the wizard is just for learning it's just for kind of getting started and playing around with everything you absolutely can and should in production use your own VPC so the the first run wizard that it takes you from that blue box and the Fargate console page that is for learning and for playing with things and figuring out the concepts in production absolutely do use your own VPC good so a couple of little other things to cover so it is very unlikely I think that people in production are doing things from the AWS console at any sort of scale I think what I use the console for is things like immediate visual feedback so how do I get something like a graph or an immediate response or to look at something really quickly or to in a lot of cases to try something for the very first time so that's what I might use the console for but in a production environment I probably want to automate things and unless you're really good at automating with the browser you probably don't do your automation this way and so most people use the CLI so steel eyes that I know of for both Fargate nice yes a lot of them are shared the first one is the original so that's the AWS CLI the official one it's open-source and includes most AWS services this is what I've used in the past because it meant that I could use a single CLI and use it for every service that I was running there are also some UCS and Fargate specific ones the first one is also official it's called the ECS CLI it's just for ECS its biggest differentiator is that it supports docker compose files so if that's a format that you're really invested in or that you're interested in using that's the way to get support for those compose files there are also some really good unofficial options so I think my favorite right now is is the Fargate CLI which is is made by one of the AWS essays his name is John pig nada and to me it feels very Dockery so I like Fargate run tasks nginx faregates top tasks nginx so it feels very much the the CLI kind of feeling that I would expect from from docker because it's using a lot of very similar language so that one's really nice there's also one called cold brew so you have some non-official options in there as well I think some of the non official the unofficial options are easier to work with I think the AWS CLI was more powerful for me because I could do everything at once because probably my deployment process is not just easy yes it's probably easy s plus something else and that meant that I can install just the AWS CLI and still take care of things like cloud front validations so some nice tools out there whether they're official or unofficial and I think finally is that the best person to learn from isn't just me or the other developer advocates or developer relations people are evangelists but it's all the other people in the audience that that are just like you right so if I can suggest anything it's join a meet-up join an online community join an AWS user group but I see so many posts that are from people on Stack Overflow or something saying or the AWS forums even being like hey I have a question about adding a subnet to my VPC and then they come back six months later and they say never mind solved it and then how does that help anyone else right and I know that all of you because I've seen so many people that have come up to the twitch booth and here and other sessions and talked to us in the hallways and they've all had these great ideas or they're trying to solve these crazy hard bugs or they're working on these really cool projects and I want you all to share that so I think as Vernor said in Akina this morning go build but also I'm gonna add one thing to that and say go build but also tell me about it tell your friends about it tell your co-workers about it tell people in the meetups and the user groups because that's how we that's we create an actual community and that's how we share things right because if I build something in a vacuum by myself what happens then so how does someone else in the same room has probably either solved the problem that I'm struggling with or has a really great idea for me right and if I never share that if I never write about it if I never blog about it if I never speak about it no one will ever know that so go build also go tell us about it tons of resources by the way if you're looking to get help so there's two slack channels right now there's one from that's from us that's official it's the AWS developers one if you want to get an invite you can send me a DM on Twitter and I've been letting people in that's my twitter handle make sure that you send your email if you'd like to get access to the slack there's another one that's an e CS developers one that one is community run not AWS run and I'll post the URLs but if you'd like to get into that one it's a community so I can't help you but the community can help you and there's also a whole squad of people on on Twitter and email and social media and at the twitch booth that are happy to to help chat and answer questions right so always feel free to tweet me always feel free to email me and the same with any of the other container developer advocates that are here to help you out so that is all like last time I will be right up there answering questions for as long as y'all want to hang out so bring me your questions come hang out and we won't do questions out loud because there's not enough there's not enough microphones for everybody okay with that thank you very much enjoy the rest of the summit and I will see you right up here [Applause]

Channel: Amazon Web Services

Views: 28,448

Rating: 4.7830191 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS London Summit 2018 - Breakout Session, AWS London Summit 2018, beakout session, Fargate

Id: xBgiArJHv7E

Length: 25min 18sec (1518 seconds)

Published: Tue May 22 2018