#ContainersFromTheCouch - Blue/Green Deployments on ECS

[Music] here we go here we go here [Music] here we go here we go here we go here we go here we go here we go here we go here we go [Music] [Laughter] here we go okay all right wait a minute you're on the the the right side today i know on the left side you know we should just change it up once in a while i guess wow like i didn't even notice until just this second it's like you're in the driver's seat wow i feel like those are some big shoes to fill i think that means you should you know like take over and drive well the good news is here we go today i'm doing i'm doing the demo so we got that but i'm still going to let you we're you know we're like we're like the driver's ed car where you have a wheel and i have a wheel you have a gas pedal i have a brake pedal guess you know we're just we're going to see how it goes nice yeah i actually i like that analogy and um i think i think it's more like neither one of us have the brake pedal it's true we just do it live you know we're just going down a hill and just coasting and seeing how things go yeah if we if we crash along the way no big deal um nice but but hello everyone thank you for for joining the show for whoever's here um i can't see right now but uh it's good to have you it's good to have you this is containers from the couch we talk all things containers containers on aws and you know yesterday we had a couple guests on the show today it's just brett and i going back to the old school the dynamic duo here uh just doing it live but today we're gonna talk about blue-green deployments on ecs using aws code deploy so first of all it's a lot have you know let's let's go back in time brent you know back when we used to deploy things you know for companies that like we weren't just you know talking about it it's not that long ago it really is it kind of i kind of just deployed like about five minutes ago so um that's true to containers to the containersfromthecouch.com that that's a good point so um but yeah you know it's looking back at you know the good old days when we didn't have all these this fancy tooling available to us and we kind of had to build this stuff on our own and um you know just build this extensive monitoring infrastructure to um you know monitor as we were deploying and everyone was all hands on deck looking watching and you know obviously we've evolved in time but over time um but you know so so blue green how long has blue green even been around for i mean i want to say a pretty good chunk of time well it has and what's funny is it's been around longer than you know docker containers have been popular or maybe docker containers have been around and notice by the way i said docker containers and not containers containers have been around for decades docker containers you know kind of made the container super popular so um that's around what like the 2015 time frame maybe something like that um a little sooner 13. yeah that sounds more right yeah time just doesn't make sense to me anymore so i'm not quite sure yeah i hear you um but yeah yeah blue green deploys were around before that so um what is a blue green deploy yeah you know i think i have a really good visual on it but you know to talk about it i think it's you know first of all we added a section to ecs workshop on blue green deployments and that's what we're going to go over today and specifically though you know when we think blue green deploy it's basically a way for you to release your application in a way where you can shift traffic gradually you can shift traffic all at once but it's a way to basically side by side deploy your your application to your production environment and test it to allow for if it fails if it's not what you expect easy roll back so you can quickly roll back but also with blue green you know i think the the original when we talked about glue blue green it was just here's version blue and then here's green flip the switch okay you know green doesn't work flip the switch back but now it's much more advanced than that we talked canary deployments where i can just have a small subset of traffic to my my my green deployment i can health check it see how how traffic's responding and then gradually grow my my green deployment until it's it's good and then that becomes 100 serving all the traffic and that deployment's successful yeah totally um there's a lot there's a lot there i think the traffic shifting is where it all started and i asked this question on twitter uh you know earlier this morning why do you think it's called blue green like where do you think that came from and uh i was thinking back to reading this long long time ago so my memory is going to be foggy foggy on this but basically the whole premise between uh in this kind of deployment is what adam described where you deploy yours your new code right alongside your old code so it's sharing the same infrastructure it's it's running but but no traffic is going to it and then all of a sudden back then you would do it in the router you would actually pop traffic over to the new uh the new version of the application and then you would look to see is everything working correctly and and uh if it wasn't you could very quickly pop it back over to the old version and what i remember was the original premise was we would have like an a side and a b side uh but the problem is if someone were to you know if there was ever a problem on the b side then there would be like some manager or pointer pointy-haired boss that would say why weren't you using the a side because you know clearly a must be better than b so so yeah they uh they decided no let's let's come up with a completely neutral even way to label these things and colors was was the idea and so um you know there were there was a possibility then of having even more additional colors like uh yellow and and orange and and gray and you know whatever gray yeah gray maybe you maybe we call that dark deployments no that that's the friday night deployment yeah but uh but no they over time uh you know they realized we only ever use blue and green we only ever need two because whatever is active the other can be passive and not active and we can go back to it so um so yeah that over time just worked its way out into our vocabulary our technical vocabulary as a blue-green deployment but it was really just sort of the brainchild of one uh random you know ops team and the rest is history that's pretty amazing and you know it it makes sense because like you deploy a and like b is not as a is always like number one right like right you're obviously b is broken you're always going to think b is a little bit slower or has more hugs yeah it's like oh good we deployed a again we're back on our fast deployment you know but that that's cool and i i always look to you for these these stories you know i always get a kick out of them you know it's like uh they just always have good stories to tell so that that was a good one i appreciate it it's fun to understand like the the background and the why you know instead of just like taking things for for face value so absolutely absolutely and so i think you know when we talk about blue green deployments right now and by the way before we we talk we do have um some folks from across the globe here we got a techie thought from dublin hey there and then also worry21 is from germany i didn't know that did you know that brent you know i knew it was going to be somewhere in europe because uh uh i think he's always saying like good afternoon and stuff like that so but okay but yeah like i didn't know it was germany specifically so uh hey grab a beer on me because uh i miss german beer hey look we even have someone from uh our youtube channel uh pavin i recently found this channel thanks a lot for doing this it's really helpful thanks for joining and by the way uh for everyone else if you didn't realize that we have a youtube channel uh you can go to containersfromthecouch.com find any of our videos and they should lead you to our youtube channel and uh then from there you can subscribe you can get go live notifications uh for every time we start the show up so yeah that'd be awesome yes and clearly brent your influence in texas is uh everywhere because we've got quite a few texans here so nice that's awesome i'm in dallas too by the way so or frisco so here's adam here's another little funny ism about uh being in dallas dallas is really kind of a metroplex of like 20 some odd cities and so if you ever ask someone where they're from they'll say dallas and then if you're from dallas you know to then throw in the follow-up question where in dallas and then i get to say frisco so nice okay okay that's good and by the way frisco if you were in san francisco i'm pretty sure the locals there would not want to hear you say frisco exactly i think i was i think i was about to be clubbed one day when i when i realized i needed to say texas frisco texas yes because you will be booed out of a room if you say frisco i'm glad we covered that that was that's very valuable for folks that traveled to san francisco texan raj is back and now i find out he's from houston so that's awesome um we got a batch hello from florida wow plano hyderabad look at this yeah one of my fans nice elbow cough uh nice wait that's hilarious from us west one i like that and look at the follow-up here's the follow-up to the question we're in dallas elena see there it is um okay all right so great talk around where everybody's located thank you again everybody watching oh we got a question about the headphones yeah we you know it's funny we get this this question a lot and uh we both have the same headphones they're kind of old now but uh bose qc35s um so if i were buying them today i would buy the newer bose whatevers they're called but um yeah i like them they're they're easy to wear all day and you know these days i'm wearing headphones basically all day all day yeah they're like pillows on my ears it's fantastic so by the way not a paid sponsor that's right but bose if you're listening and interested tweet me send us headphones please all the different colors uh okay all right so let's let's let's get into it what do you think brent let's start talking blue green and let's actually do some cool stuff from the command line sounds good all right so as we switch over here that's probably my job right remember the yeah we both drive you know two wheels two gas pedals thank you um so okay so uh this is our ecs workshop uh website um if if you've been here before so uh there's a good question i want to answer in just a moment but if you've been here before um you may notice that the layout's a little different we just changed it recently but specifically the section we're going to review today is blue green deployments and i one thing i want to do is this is open source so you know when we talk ecs workshop eks workshop it's not just brent it's not just myself there's a community that helps build this and um actually there's a devops consultant at aws over in the uh the uk that actually submitted this change so siraj thank you for the contribution really awesome so let's get right into it so okay there was a question around ecs and um specifically does uh is blue green supported in the cdk ecs patterns the answer is no right now um you can and we're actually going to go through the cdk this is all done via the cdk but what you'll see is there's certain um components that we built within the cdk that we actually have to create a custom resource for and i'll show you that in just in just a minute but they there is a a github issue out for this um and it's basically because of the way it's implemented in cloud formation the cdk team has to basically create an rfc to determine how they're going to implement this functionality so that's kind of a long story short right there and at some point i will go to that and i'll share that link so you can follow that issue in github as well okay so all of our sections in the ucs workshop do have the videos as well so you could actually watch this video live on ecs workshop thanks to brent i will not because yeah then it's just going to be really weird oh my gosh it's like uh they say those busters don't cross the streams i think it would be like that you know we would like rip a hole in the in space or something so yeah we we can't do that i agree it would just it's like multiple scenes out there yeah exactly everyone else out there you're free to to watch it from this site it's totally fine also it's on containers from the couch but yeah adam is is banned so and also you know now that you mention it though let's look at really quick containers from the couch just calm just so you can see yeah this is where all of our content goes that we do on the show so that looks nice it looks really good looks really good nicely done brent so thanks i can't take all the credit um my lovely wife uh did a lot of the work so she's all she is she is really creative i gotta tell you if this was me doing this it just would have been like like blocks and just you know like plain squares contained and horrible exactly like i would have lost a lot of friends that way okay so um so you know again we talked about blue green deploys but really this is just a technique for releasing your application by shifting traffic between two versions of your application in uh basically one environment with with two copies of your application and the idea is to slowly migrate that traffic over you know you have your blue release active green comes up you have first a test endpoint to make sure that it passes basic validation tests and then once that's good you you start to either you can do it all at once or gradually switch over to green so um good stuff here on that so we're going to do today is we're going to deploy a very simple nginx app it's going to be an nginx app that's just going to show up the color of the particular version that we're on um so it's just going to be an application load balance service so you'll see an application load balancer we'll have two target groups which i'll show you in just a moment um target groups for blue target group for green and then there's uh also a a listener on 8080 so that the production port listens on 80 and then the test port is on 80 80. so that's where we can get that initial testing done before we actually start to canary out and then we're going to build the pipeline so i i i don't love engine x so much it's just easy so i just happened to see that i know you're just lucky it's not jenkins exactly oh man i built so much with jenkins in my time totally uh but okay but with that said i love code pipeline i really love our code suite um or our code tools code services suite so what we're going to do today is we're actually going to use code commit for our git repository we're going to use code build which is actually going to build our docker image and push it to the elastic container registry and then we're going to use code deploy to actually deploy using our blue green deployment provider to fargate by the way fargate so and it could be ec yeah ecs on ec2 and of course code deploy is not limited to ecs but we like containers so we're going to talk ecs here let's just stop for one second talk about all those services that we're putting together code commit is designed to hold data so it's obviously stateful ecr is obviously stateful it's designed to hold artifacts but everything else is totally ephemeral and you're only going to pay for it when you use it and that's incredible you know like it code build is going to come up it's going to do your build and then it's going to go away and you get to stop paying for it and then code deploy is going to do the same thing it's going to run the deploy and then it's going to go away instead of having something that is up all the time and and you're constantly having to like care for it and feed it and and maintain it this is just all going to happen for you in the background so yeah i love that point yeah yeah it's awesome and and like code pipeline if i i don't want to misspeak so we'll check but i'm pretty sure you don't pay for code pipeline you just pay for what you use within the pipeline i may be wrong am i wrong i think there's a i think i think there's a i don't know i think that you might pay a little bit of something for code pipeline paging richard boyd paging richard you know what i'm sorry this is my 80d here i can't focus on one thing yeah okay so um yeah so one free pipeline and then it's a dollar per active pipeline per month yeah so exactly it's it's not going to break the bank or anything but it's not technically free yeah so good okay so and yeah so we're going to use all of these services today and yes we are going to actually use the cdk to deploy this so um yeah that was answering texan raj so yes cdk all the way because if you know adam you know adam loves the cdk i really do uh you know although i'll say you're gonna start seeing a shift with me is i will talk a lot about cdk but as copilot continues to improve are the for ecs i'm gonna i'm gonna start talking i wanna talk a lot more about copilot because that tool command line tool is so powerful but yes yeah this is cdk and i love it totally yeah um so just a quick example this is what a you know aws code pipeline example looks like i'm not going to really dive into that and then a blue green deployment example so this was taken from uh upstream github repo aws samples but just to give you an idea of visually what blue green deploys look like so um yeah we're gonna just we'll keep it at that because i think we talked a lot about it okay so i've cloned this repo which you do in the prerequisite steps and this cdk is all done using typescript so for those that are sick of hearing me talk about python today we get to talk about typescript so very similar as far as the format obviously you know python versus typescript there is a difference in how you manage your files in in your repository but we're going to get started with installing all the packages so we're going to do an npm install this is going to install all our cdk dependencies everything we need to actually build and run our cdk code and then we're going to build all of those uh files okay so that's wrapping up perfect let's go to the next step let me move this here my apologies okay so one thing is this uses a a newer version of cdk we're actually using in this example 1.54 we're already on 1.57 cdk moves very fast oh i already have it bootstrapped i think so we're good but generally what you want to do is you want to bootstrap your environment first and um when you bootstrap it's just basically creating a bucket it's putting some prerequisite assets in there so anything that's related to your environment that's being deployed that's it references a lot of that in that s3 bucket so that's just creating kind of that that asset uh storage environment for you so now that we've done that i'm gonna run a cdk deploy actually let's do it let's do a cdk diff and let's see what we're going to build and then i'm going to run through the code and i hope my text is okay so if it's a problem please let me know i think it's good okay let us know let us know in the chat if it's too hard to read yeah thank you uh so what we're going to be doing here is you know in the past you've seen me i've been i've defined our um ecs services in cdk so in the example here what we're going to do is pretty much deploy a load balancer ecs cluster the code commit repository a lot of stuff okay and then of course we're going to deploy the code pipeline as well so that's the code pipeline the code build environment as well as the code deploy configuration and i mentioned earlier because the cdk is not like doesn't have a like a really high level construct around this like an l2 or an l3 construct we have a custom resource to build our deployment configuration and a deployment configuration is what defines how you deploy your application using aws code deploy so what that means is if we look here that means um let me actually oh shoot i went to the wrong section here but that's basically safe with my configuration i'm determining the type of deployment i want to do whether that's linear or a canary so linear is just basically a a certain set over a certain period of time canary is a small subset and then very similar you just you grow out in time but also my steps and and that so i did see there was a question yes from techy stories hey welcome back um she wants to know is are there security features included by default and let's let's touch on that just real quick as a recap for cdk type projects specifically yeah so um with the way it works with the cdk is cdk manages a lot of the underlying components for you a lot of that we call it the boilerplate and iam being one of those and what i mean by that is if you were to create a resource in aws on your own you'd have to create the iem policies sync those resources that you want to talk to each other through iam create service roles um etc so the cdk is going to only grant the access between the resources on a least privileged basis and to only what's needed to talk to one another so by default for example if you wanted to have a your load balancer i don't know open to the world or you wanted to open up ssh oftentimes that's something you'd have to do on your own that's not going to be out of the box by default but if i'm creating an s3 bucket and an ecs service and i want to connect those together i can use the cdk um these these helper methods to connect those resources together but long story short is yeah go ahead well i was going to say and then if you just think about the way all of these services are fitting together you know like code deploy needs to be able to push into ecr ecs needs to be able to pull from ecr um there's you know something that uh somebody needs to read out of an s3 bucket etc like all of those permissions are least privileged and included as part of the boilerplate and it is possible to go back through and override some of that if you if you feel the need to if there's like a tweak that you need to make but yeah for the most part that's all been included as part of the construct or part of the best practice exactly exactly so um just to kind of go over some of the things we're building again we're building our ecr ecr is our container registry so we're building a a repository i mean it's you know when i say building it's just creating a pointer but this is a fully managed container registry so um we're just creating a repository for our docker image and by the way we're enabling image scanning on push which i really like it doesn't cost you anything and when you this is just a little sidebar when you push an image to ecr you have the ability to enable image scanning on push and that way every time you push an image you can have a scan run on that that docker image for any vulnerabilities i did do a tech talk on that not too long ago so that'd be cool to link in here but regardless um you know techy stories you know asks about security a lot which i like and this just is one of those pieces that you can add to your pipeline you know when we talk devsecops where you have a pipeline but you also are integrating security there by scanning your your ecr images so we create our code commit repository and again it doesn't have to be code commit in this example that's what we use but of course code pipeline um also works with github bitbucket and i there's maybe more i can't think of any more at the moment but yeah there's a set yeah exactly so then we're going to create a code build project so and actually by the way i did run a cdk deploy so this is happening in the background while i'm talking um and in our code build project so code build is a way to you know if you think in the uh the world of like git lab or or you know where you have like git labs yeah you have like a runner this is like a runner right it just spins up a container it's gonna run and build whatever it is that you've defined in your build spec which is your gamble definition of how you want your test and build to run and then then it moves to the next step basically so that's defining our build and then we just you know some of the other stuff uh kind of boilerplate stuff vpc ecs cluster as well as the load balancer with two target groups so a target group you know we have our load balancer which has a listener and the listener talks back to target groups and the target group will point to your applications and that could be over ip that could be over a couple different options but here the way we're setting this up is we're just creating basically two empty target groups right now with the idea that once we start the blue green deployments um and we integrate that into all of this then we'll be switching over between target groups as we go between blue and green nice so it actually gets back to that original idea of the router you know like the the load balancer is our router and the two different target groups are blue and green that's that's pretty cool exactly and um so yeah so that's that's it so it's building this stuff this takes a few minutes of course you know we're creating a network creating 74 resources here um which equates to a lot of lines of cloud formation so um that we don't have to manage well while we're waiting let's uh let's take a break and mention that on monday uh we are going to be running and you and i are going to be hosting part of uh aws container day so um you definitely if you're interested in kubernetes uh this is a day zero event for kubecon europe so uh if kubernetes is at all interesting to you sign up for for container day at the url down here aws container day.splashthat.com and uh i think i saw an email uh this morning that it looks like if you wanted to attend cubecon and do the keynote plus uh the booth the expo hall the the conference passes for those are free um otherwise uh a kubecon conference pass is now only 75 it used to be like 1400 so um it it's a it's gonna be an interesting conference a good one to attend uh aws will have a booth there and you'll see a lot of our content uh from containers on the couch uh will be in the booth as well there's going to be some workshops and and people you can talk to kubecon itself is going to be a european standard time but uh the container day day zero event is going to be us standard time and then we'll repeat it again and for for europeans and and again for uh asia-pacific so uh definitely consider checking that out yes yes yes yes please do um okay so we're done we we have our our build so actually our environment's been deployed and what i've done is i've captured the load balancer url and now i actually want to see what that looks like so what we should see is a url which feel free if if you want to go here and this yourself you absolutely can this is real and what we're going to do is we're so we so we've deployed our application so with everything we just did we deployed an ecs service an ecs cluster we have the blue green setup ready to go now what we want to do is actually push to um our git repository to to trigger a deployment of the green version of our application and yes by the way someone had mentioned about uh cloning i apologize in the ecs workshop this is a bug that i just created um i will be sure to fix that because we don't have the clone in this uh particular section so that was my bad the is it not the code pipeline repo oh is it there to okay maybe it is there it's not just chapter it's up higher when you um i think in the micro services yeah the microservices section yeah so i just gotta put it here too okay all right so what we're now um we pulled down a sample repo okay and we look at our remote right now i set our remote to be that um that uh code commit repository that we just created so when i make a change now i'm gonna push to that repo and what i'm gonna do is i'm gonna change our nginx pump and you know i'm having issues with this oops let's go here and just so you could have one more issue do you think you could make your font bigger absolutely i always forget how to do this um so i think i gotta go reference preferences and then i gotta find it yep and there's one for terminal and one for it's in user settings yeah why like it's the simple things are the hardest things for me okay let's see how is that better or a little more let's go one more i'm gonna go two more okay so just just in case okay all right so we have that for now all right so what we're gonna do is we're gonna change our background color from blue and by the way not just any blue but cornflower blue to green okay and then we're going to get status we're going to add this file git commit dash m adding green and then we're going to push okay so what have i done i've changed our application to go from blue to uh green and what i want to do now is go to the code pipeline so we don't miss it and show you what's actually happening so here's our pipeline you can see the deployments already triggered okay so where there's a source stage which pulls down our code from from git it then basically bundles it into an artifact and passes that to our build stage the build stage of our pipeline is actually going to build our docker image and it's going to push it to ecr and when i say build the docker image it's going to actually capture that nginx configuration or that the index html that i just modified bundle that into the docker image and then put your er and once that's done it's going to then trigger the blue green deploy which i have to tell you the ui in our blue green deploy with code deploy is so cool and i can't wait to show you so wait to see it as you i mean brett you know i just love like pipelines i don't know what it is i i'm just a devops person at heart and i love good ui so yeah i'm excited to see this so check this out so we we built our docker image we tagged it and as you can see we we have a latest tag but we also have a git shot tag right don't tag and thank you don't run latest in production your friends will not like that and now we have our deploy stage so you know talking about code pipeline just really quick really cool how the different levels of integration that are included with code pipeline so when i think if i'm managing this on my own i have to think about managing a ci service a cd service i have to think about all of these things i need to have something to manage that blue green that i have to configure and monitor and watch i don't have to monitor code pipeline that's a managed service i don't have to monitor code deploy that's a managed service so just you know another neat thing to mention there okay so what is cool yeah right like isn't this beautiful so okay so what's happening right now so we're instead the first stage of our deployment it's creating a replacement task set so if you're familiar with ecs you have a task definition a task definition is like a basically like in the kubernetes world it's a way to define your pod okay it's a very similar a task pod like i like to just compare those two so it's understood by all but essentially that task definition is where you're going to define your container or set of containers that you want to run as one collective unit and so right now it's building that new task definition and the next step is it's actually going to start to test that new test definition with a new service basically confirming how is this working um are we healthy to actually start to route uh production traffic to this app so let's see auto refreshes let me let me repeat just to see if i understand it correctly so we're waiting right now on our far gate tasks to actually come up but we aren't sending any new traffic to those new tasks yet so it's not just building the task definition it's it's actually like building the task definition plus bringing up our new containers and all that stuff that's really cool exactly so and you can see here it so we're basically doubling that task count right now so it's all within the same service we're we're doubling our task out so you can see we have the old app and then we have the new app test definition here that's about to be deployed and forgive the numbers that's just because i've done testing before no worries and we have a question from our youtube channel i defined four containers with one task definition will these templates work if i start setting up my pipeline and i think that's what's actually pretty cool about this is we're not really thinking in terms of containers we're thinking in terms of tasks so if they're all part of the same task then yeah it'll absolutely work whether there's one container or ten containers inside of them bingo and so take a look it already ran through step two that was really quick it so it tested that traffic against my health check so obviously our health check is nothing advanced it's just checking that nginx returns a you know 200 and now it's starting to route traffic so look at this on the right here look at this this awesome little graph and i love that they're using like even you know 20 traffic shifted like yeah i mean the terminology is there the this is this is so hard to do like and to build this kind of automation on your own oh there you go so see it's i'm i'm continuously refreshing and you can see i'm hitting blue quite a bit but every so often i'm hitting the green well that begs the question what if you wanted like a 100 cut over or one of those situations you didn't want to gradually cut over you can absolutely do that and there so if we look at the documentation there's there's different ways so you can do a canary deployment you can do a linear deployment or you can do all at once just like you said yeah so absolutely you can have the the choice here we do that so awesome and seriously so hard to do like there are entire companies built around doing this in kubernetes so i you know i love that this that this exists yeah it's it's really impressive and it just goes to show like when a feature is wanted you know we hear you we implement it it may take a little time but we want to make sure we're doing it right and yeah i mean it's just this has grown like you know when when blue green first came out it wasn't as feature-rich as it is today but that's because we continuously improve these services so basically this is going to take a few minutes um actually probably too long to be honest but i want it go ahead maybe you were about to say this maybe i just interrupted you but i mean would it ruin the demo if we pressed that button stop and roll back deployment no and that's what i was just going to do i'm glad we're on the same page here so as soon as i interrupted you i thought that's probably what he was about to do now he's going to go there no but it's good brent we're on the same page here this is good we're like peanut butter and jelly um okay so this is another thing too so you have the ability to just stop your deployment so i could keep where it's at and just stop it and halt it or i can stop and roll back which i'm going to do right now and it's going to tell me are you sure because you know maybe you don't want to do that but that's what i've decided to do so it skips everything it counts it as a failed deployment and now it's going to give me the status on the rollback which as you can see was lightning fast and now we're good no more green so the rollback was all at once which makes sense that's what you would want yeah absolutely and look i still have these tasks running they'll eventually diagnose you yeah yeah um so just that i mean this is pretty cool like this is the type of stuff that gets me giddy um so yeah so we're on blue so now what do you say let's deploy a broken let's break our application and deploy it and see what happens oh yeah let's do that while you're setting that up i'm gonna i'm gonna address some of these questions from chat um and on the xmj do we have this integration of code pipeline with eks the way you're showing for ecs this is really cool i don't think so yet but i think the code pipeline team is is looking into doing this kind of thing so um don't don't think never just think not yet um and how does this work if something like helm if like is there an approval process where you could see the change or anything like that oh i like that question first of all do you mind if i answer this brent i'm sorry yeah okay so well first of all you know brent and i will always i think agree on this ideally we don't want any gates in the way any human gates right ideally you need to to have rich testing of your application and and be confident enough in your application to have a ci cd process where you can have these roll backs where you don't need these gates but i understand every environment's different you know enterprises are sometimes have some change management processes that you can't get around in your code pipeline you can actually have an approval step here so you could um after this build i could run like a cdk diff or i could deploy it to a dev environment here and then have an approval gate that only certain people within an iem that have an iem role or um that are part of an im group could approve this particular deployment so yeah did you want to add anything else to that brent i i think just to emphasize what your original thought was is you know if you put a human gate in place do it as a temporary measure and like try and capture what is that human looking at and what you know what are the things that they care about in the checking and figure out how to automate that so that eventually the automation can be the gate instead of instead of a human because ultimately where you want to be is developer pushes code and that's the end of any human involvement and everything else that you have is covered by uh pre-agreed the thing that i love about code checks is i look at them as sort of contracts you know as long as the these well-defined uh sets of criteria have been met and proven to be true then we're good so go ahead and ship that code yes so uh techystory says cooldemo thank you uh i agree that was a really cool demo t sergeant green says how does this differ from cdk pipelines is there any overlap yeah that's a good question so cdk pipelines um because we're adding a so cdk pipelines will um and this is referencing i believe the the cdk pipelines that the new um feature that was released where it'll actually you define your pipeline in a construct and it'll build all this nice stuff for you cdk pipelines the deploy step is a cloud formation deploy so with code pipeline you you can have code deploy has multiple deployment options and cloud formation is one of them so essentially the cdk pipelines construct is going to build an artifact of your cdk code which is going to be cloud formation it's going to basically take that assembly cloudformation template pass it to the deploy stage and then the deploy stage is going to deploy the cloud formation for you in this case our deploy stage we had to create the pipeline outside of that construct because we have a custom deployment that doesn't fit within the the cdk pipelines functionality does that make sense yeah i think so and also it also sounds like someone could potentially go and write another construct that would would set this up and include it um this is still relatively new i think so it you know it may just be that there isn't a construct written for this yet yep and and again remember with uh blue green they don't have cdk doesn't have a um uh a construct built around this yet it's still there's some work that needs to be done yeah so peak of humanity asks does cdk create the fargate cluster on platform one four or greater ephemeral storage encryption for ecs tasks is available starting with that version and i think the answer is yes but i also think even more importantly is the construct would allow you to specify that if you wanted to keep it at a specific version uh you could totally do that yes and while we wait for that aw cdk fargate service i just want to show you um it does i believe i want to say it defaults to one three um maybe it does like latest for the platform version yeah uh so yeah let's see here anyways you can override it so i don't know exactly what the the default is but um this is a something that you can very easily override and if you look at ecsworkshop.com under the microservices chapter we actually you can see where we define platform version there for reference so uh a techie thought uh suggests also consider business load factor i call 1980s deployments if humans are clicking buttons and yeah i mean imagine if like the person that was in the middle of the gate you know for approving is is out on vacation or stuck in a meeting or you know whatever and we all just sit around and wait you know waiting for that bug fix to go out so uh yeah it's definitely better to load them you know i'm not saying get them out of the way i'm just saying front load them as early in the process as possible yes agreed awesome and so just get quickly up to speed here i broke our application i basically had index return of 500 so what's going to happen is after this replacement task set is deployed it's going to test it and it's going to fail and then roll back so that'll just be it takes a minute for that to happen that'll be cool but we can see again we see here's our app we have our extra set so remember demo app was on 5 earlier now it's on six so six is our our newest version and actually it does look like it defaults to one three so for platform version for this but it is super easy to set it to one floor beyond yeah yeah i mean it's very easy so that's pretty much it so we're waiting for the deploy to finish but you have the ability to um you know kind of customize this based on your needs if you want to just do if you want a canary quickly you can canary every minute you know and if we go to code deploy let's actually go to our deployments actually go to our application so in co-deploy you have your application which defines how you're going to deploy to what service to what endpoint and then you have your deployment groups and so the deployment group is where i can specify my load balancer how do i want to shift traffic and then you know so we have some default patterns but what i like is with the configuration uh deployment you can actually modify this yourself and i can say i want to shift you know 10 of the traffic every one minute or that's cool 50 every one minute so that's very cool yeah it's customizable in that sense so let's go back to the deployment and let's see it should fail soon still still waiting here and the problem is it happens so quick i don't want to miss it but yeah when it does when it does fail but anyway so are there any other questions while we wait for this to to fail out yeah a techie thought uh points out for people interested in cdk there is the upcoming cdk day uh so definitely check that out and sign up for it and worry 21 is wondering for having no gate or approval process in your delivery pipeline especially for production it feels like you have to build a lot of trust in your automation is there any chance you could cover some best practices in the future and i think yeah we should we should put something like that together i think um it'll be a really cool demo uh but we should build something yes i'm i'm so in for that that is really awesome so ayushi says funny how i've been using lambda to kill ecs services and force create it to update when my pipeline runs this will sure help a lot well yeah that's that's awesome glad to hear it and lambda is awesome for that kind of functionality but you know when when there's a sort of built-in way to do it then that's just one more piece of code you get to delete i love deleting code so you know that's less for you to have to manage and maintain and it reminds me of a so years ago i worked at a startup and i built a rolling deployment automation for uh very similar to this i built this really awesome framework we used it they still use it actually at my former startup but i think they might they're migrating away from it but um which is always happens uh but the cool thing is is within a a couple years or a year i don't remember how long aws released that functionality in code deploy so ideally what would have been nice what they should have done is deleted my code get rid of it and just use that and that's how i when i build an aws if a feature is not available yet i'm going to write code to fill that gap and i with the intention that as soon as aws releases a feature that fills that gap i'm deleting my code i'm done so no sacred cows which i i love yeah so anyways i i clearly broke something in my deployment but i don't know what happened here the demo gods are not looking kindly on me right now it says it's in progress it does it does i just i i i don't know what i did but anyways so let's recap because i think we're kind of running low on time yeah we're running out of time you know it's it's funny we always talk about this brent but it like this time goes by so fast like you know we plan all this stuff and you think oh there's i'm not gonna have anything to talk about and then right yeah it's it's like shocking how fast an hour can go by um hopefully it's the same for you guys out there too so you guys needs that uh for for everyone out there because uh that would mean that you're you're enjoying it so uh that's awesome tell your friends about it uh hit the subscribe button on our youtube channel um it obviously you can subscribe on twitch also we'll sometimes get push notification for that but other times we don't but uh on youtube i think you know since that's ours you'll definitely get it there and uh feel free to join us uh for every show so we'd love to have you yes and um there is one question that i want to address that just came up um around what what sort of tools are available for performance testing scaling of ecs tasks um so this is i i think container insights is going to be a a big help here this is something you can enable on your cluster that gives you task insight into your tasks from a a monitoring perspective into your services and into your cluster meaning fargate or ec2 so definitely check out container insights we do have a section on that at an ecs workshop as well but you know you can always add custom metrics and there's a there's a sort of subtle nuance to this question also because container insights will tell us how many requests per second you're getting uh i'm wondering should we do a show on just how to performance test your container and and understand what the request per second it's capable of serving is and then use that to help set your decision making on on thresholds and target tracking auto scaling and all that so because ultimately you really need to know going in at a certain container size you know with my code what should i expect maximum uh transactions per second would be and you're not going to go over that so you may as well use that as the scaling decision yeah that that would be a great one to talk about i i concur yeah we should all right i'm gonna write that down so good stuff once he writes it down that means it's happening folks that's right remember that so uh okay so thank you everybody for joining honestly this this was a lot of fun i was glad that i got to be back in the driver's seat again demoing i i love to demo and i love to just build things um so it was nice to do this so thanks everybody and we will see you not tomorrow we will see you monday wait it's today thursday or wednesday wow today's wednesday we will see you tomorrow i uh today's wednesday march march 0. i don't know part of the problem is we have not come up with a topic for tomorrow so uh we're gonna do that next but yeah we'll see you tomorrow watch twitter for the topic idea and uh otherwise uh see everyone tomorrow thanks y'all see you tomorrow bye

Channel: Containers from the Couch

Views: 1,279

Keywords: learning, containers, docker, orchestration, aws, cloud, ecs, ecsworkshop, devops

Id: DZ5eePBq74A

Length: 58min 26sec (3506 seconds)

Published: Thu Aug 13 2020