AWS Nordics Office Hours - Continuous delivery for AWS CDK applications with CDK Pipelines

hi everyone and welcome to aws nordic's office hours with me your regular host jonatha i am a developer advocate here at aws and this is our weekly show coming to you live from the nordics where i bring on aws experts to talk about a specific topic and then let you our audience ask your questions and hopefully by the end of every hour you'll learn something new about aws so in this hour you'll be able to ask your questions and don't worry if we don't get your questions straight away we'll try to cover them where it is appropriate throughout the hour like i mentioned every week i have guests on and this week i don't only have one guest i actually have two guests on so this week i'm joined by asgard and by pankaj this time we're gonna talk about continuous delivery for aws cdk applications with cdk pipelines so welcome to the show both of you hey hi so we'll do as we always do start off with the basic introduction so ask god tell us a bit about yourself hey everyone my name is asker sherikov and i'm a solutions architect based in sweden in malmo so as part of my role actually i also specialize in our developer tools so i'm really happy to talk about cdk today thanks for having me thank you yeah same as oscar i'm also a solutions architect but based out of oslo norway i'm quite passionate about devops in general uh and then that's why i know a bit about cdk and cdk pipeline that i guess we are about to talk uh as well um so really excited to be here great to have you both yeah great to have you both on the show pancakes you joined us just a couple of weeks ago as well to talk about aws lambda power tools so that episode is available on demand if you want to watch that as well all right so we're going to talk about cdk pipelines and to get there to cdk pipelines i think we need to start off um pretty much from the beginnings to talk about what aws ck is because we know some of our audience they are probably cdk experts some of you out there perhaps you haven't started using aws cdk yet so to begin with let's ask a question why can't i just set up services through the aws console yeah that's a good question in general you should not be setting up things on aws console directly for that we have infrastructure as code as we call it and aws cloud development kit or aws cdk as we call it is is one of those tools that help you write infrastructure as code so coming on to maybe what is infrastructure as code right and in its simplest essence i guess if if you are coming from a development background it's basically about applying all the practices that you have uh with application code development to provisioning your infrastructure as well meaning that you should be maintaining your infrastructure as code as the name says you should have version version control around it and you should make your infrastructure repeatable so that you can just deploy it uh in the same way in other environments as well so aws provides different set of two links that let you uh build infrastructure as code and not just aws there are a lot of other open source tools as well that lets you do the same um and then one of that is aws cloud formation uh which is sort of think of it as a backbone of all the other tools that we have around and aws cdk is one of that as well so aws cdk basically lets you define your infrastructure as code uh in in using one of your familiar programming languages uh it could be java uh it could be python it could be typescript etc right so the basic idea is that if if you are familiar with one of the programming language um you can start to use aws cdk and and build around uh with that all the infrastructure in aws right um so yeah um that's in in very short about what infrastructure s code is and what is aws cdk that's great all right so i can see people are posting in the chat already great to see that we can see that it works keep your comments coming i see comments about beards so far which is great the evolution of beards i suppose from mine through asgar and to pancatch them so hi everyone in the chat keep your questions and comments comments coming throughout this hour all right so that was quick about why infrastructure as code is good and a basic intro into aws cdk so we're going to get to cdk pipelines and but i think it it's important to go from the beginning to get there and i promise you we're going to see demos we're going to see code we're going to see examples of how to use it throughout this hour all right so going from there then um what's next then yeah i guess now since we have introduced aws cdk and the next topic should be what's what's about cdk pipeline and and what it's trying to do um so with aws cdk uh there is a concept of construct as we call it uh right and there are different levels of construct uh with aws cdk and you can think of these levels as level of abstractions right so starting from l1 constructs which are uh like a one-to-one mapping of aws cloud formation resources right so if you have a cloud formation resource you have a l1 construct with aws cdk as well to sort of mimic the same behavior uh but with with cdk you you have these higher level abstractions as well which we call as l2 l3 or different levels of construct so with l2 construct you mean that it's an higher level abstraction which takes away some of the boilerplate and heavy lifting that you have to do with cloud formation uh resources and and it's just very like easy way to get started with those resources so that's about l2 construct and then there is a concept of l3 construct or further which we call that as patterns right and this can sort of set up a full-blown architecture for you with just few lines of of uh construct code that you have to write in your code base and one of those construct is again a cdk pipeline um that that's that's based on the intention of getting your cdk applications deployed via ci cds uh in a multi-account setup uh very quickly and easily without you needing to take care of a lot of heavy lifting around building those pipelines so that's that's about the cdk pipeline and how it relates to uh aws cdk itself so um yeah i'm gonna ask you a couple of questions around ci cd pipelines and so on but first a question from the chat or a couple of them at least so is cdk mandatory for cloud formation to work uh no the answer would be that cloud formation is sort of needed for cdk to work right so it's the other way around wherein cdk is actually using cloud formation as an underlying sort of service to provision your infrastructure and it's an higher level abstraction on top of that to write infrastructure in your family programming language so you're using typescript or python or or net for instance to to write your infrastructure as code which is then outputted as cloud formation to use yeah right and then the second question is let's say that you have infrastructure set up in cloud formation is there a smart smart way to move to cdk can you take your cloud formation templates and make them cdk yeah um that's a good question i i think i was in a conversation with one of the customer earlier this week around the similar topic so there are a few different ways that you can do this one is something called cfn include construct that that we have it basically lets you include your cloud formation template and basically start building on top of that cloud formation template and further define rest of your infrastructure as native cdk application right so it's it's sort of a quick way to get you into cdk application but then we recommend customers to slowly refactor that as well and then start using some of the like native uh cdk constructs as well but it's generally a good head start for you to just include it and then start building your new infrastructure in native cdk form so so you wouldn't take your existing cloud formation templates and just put them through a converter and output cdk uh no i mean i don't know of any such tooling which which can do that for you but it would be nice if there is one that exists sounds like a space for an open source tool so any builders out there who want to start building that tool where we're open for trying it definitely all right so i said i was going to ask a couple of questions around cicd as well so tell us about ci cd why is that a good practice we've already covered infrastructure as code and so so why do customers use ci cd and pipelines yeah i mean basic concept of ci cdn and devops in general is that you should not be touching your infrastructure and deployment process manually so once you have pushed something to your version control it should automatically and seamlessly get deployed to your different environments obviously there will be different steps that that the deployment process will go through but the idea is basically to make your your deployment process repeatable and and without any human intervention so once you're done merging your pull request the the pipeline should take care of moving your code base end to end uh obviously there it's it's a journey uh which which customer has to go through in order to make it full proof uh but that's the basic concept around why you should be uh thinking about having ci cd pipelines and and that journey is perhaps a bit easier now with the release of cdk pipelines yeah otherwise before this release which i think was this summer is that correct um [Music] yeah and so before that you could use cdk with your pipelines so so have deployment of infrastructure as part of your pipelines but in this case you're also able to build your pipelines with cdk yep yeah and i mean i mean we'll go through some of the details as well as to why this is easier uh to to set up things for you so yeah all right so um anything else you want to cover around cdk pipelines or is it time to start looking at um well how to actually start using it um i guess we should just move on to the fun bit yeah i like show and tell everyone who's watched the show before knows that uh when we get past that first 10 12 15 minutes it's time for show and tell to actually start seeing things in action so i guess it's time for that i see there's a question in the chat about sample cdk samples for cdk as well and we'll post several links throughout this session share those with you as well so you can get started easily all right uh another question i just need to add that as well and see if you can answer it depends on if you've used terraform so what are advantages of cdk over terraform if you have lots of terraform code why would you consider cdk yeah it's always one of those questions where i would say it depends uh yeah it's always a matter of choice and preference um i mean i won't say that if you have your entire infrastructure written in terraform today you should go back and rewrite everything after today's show uh it's it's a matter of preference in the sense that if you like working in your familiar programming language and then and you want to provision your infrastructure that way uh cdk is one of that tool that will let you do the same uh terraform if you have already built a good competency around terraform i've used terraform a lot in my previous jobs and it's equally a good tool uh to work with one thing that that always happens and and it's always the case even with cloud formation is that once some service is released right uh generally you will get cloud formation support and then and based on that the l1 construct that i talked about for cdk around the same time uh cd terraform which is like an open source tool generally the community is very active so you you do get support for new services as well but it that that there might be a lag sometimes right right all right that's a good good answer i think okay uh is it askiar are you gonna go up go out and start showing us examples of cdk and cdk pipeline yes please so let's switch over to your screen share then yeah um so i hope you can see the the the code fine so uh what we're starting with here is basically whenever you when you install cdk toolkit on your machine you create a folder you go there and you just run cdk [Music] init basically which will initialize this cdk application there in that folder this is what you will get so you will get like a bin file we will talk about them as well uh some lip file basically which will where we will be writing our code and where we will be defining the infrastructure and all other kind of supporting tools for this example i'm using typescript because typescript is the native language for cdk so that's why we're going to use that um one other thing that they've done because we are going to use github repository for our pipeline i've created an empty repository copied uh cloned it to my folder so basically now it's kind of is set up as my upstream and i have if you're asking like how i'm connecting to it then i just have a a token on my account and that's what pipeline is going to use to actually pull the code from github so basically that's kind of the prerequisite that we need to clear and right after we have our pre-created uh first uh stack which uh and where we're going to actually define our cdk pipeline so we start with importing some of the some of the constructs that we will need so we'll need code pipeline and this really shows what you mentioned before pankaj that it is the coding language that you are familiar with in this case as oscar mentioned he's using typescript and i think that everyone who's used typescript or or javascript node uh recognizes this yeah that's true you'll see me showing java because that's what i like yeah but typescript is equally good language not starting the language wars and then there are other languages as well yeah okay so we imported some of the libraries and constructs that we will need uh from now on i will actually not be typing everything and just copy and pasting it if you don't mind just to save time so first and the main construct here that we're going to talk about is the pipeline itself so we are going to define it here so const pipeline we create a new pipeline we call it cdk pipeline here we give it a name we allow cross account keys and that we will need to actually be able to deploy to two different accounts from one pipeline and this is what you need which is like a necessary step when you run code cdk pipeline sorry is you need this synth step that will basically you specify the input for your for your code which in our case is github this is my personal repository the branch that we are going to use and some commands so that our pipeline is going to run right after it will actually pull this this code from our repo so with that done basically what we need to do now is switch to our cdk pipelines demo ts which is under our bin folder and this is uh what you could call a entry point to your app meaning that whenever you run a cdk application here you you specify which stack you want to run so in our case we want to run our our cdk pipeline stack and we need to explicitly state which account that we want to deploy to and that is again necessary if you want to do cross region course account deployments so with that saved uh first thing that we need to do is actually add it to our github repository and that's uh quite important if you worked with cdk b4 you could assume that okay i just need to run ctk deploy now not the case now because we are going to pull the code from the repository right so before we actually deploy the application we want to make sure that the code is there so first of all you need to run like with add git commit and after that bit push i'm not gonna do that now because what then instead of doing that i will just show you the what will happen right after just to save our time again and another important point actually when you do cdk pipelines um is you need to add a little line to your cdk json file and that's very important you will see this in all the instructions that concern um cdk pipeline because it uses a new style of stack synthesis and it's not enabled by default i believe so you will need to add this line there and you will need to bootstrap your environments which pankaj i think you can talk a little bit about in depth right why do we need to bootstrap environments yes yeah okay uh i mean do you want me to do it now yeah please okay uh so yeah as as oscar was mentioning that when you are building a cdk application in general it's not specific to cdk pipeline you need to first bootstrap it right and what bootstrapping means is that it basically will provision few things which will make it function on behalf of you and and historically there has been one way of bootstrapping your cdk application but in order to add these uh capabilities which are like cross account deployment and few other things there is a new way of bootstrapping cdk application as well so i can show a few bit uh quickly around bootstrapping because it's something i think which i have had conversations with customer as well to to make them understand how to best use bootstrapping and some of the iam stuff that that we mentioned around cdk pipelines so as oscar was mentioning this is basically the line that you need to add to your cdk.json cd cdk.json is think of it as a configuration file for your cdk application right so you basically uh tell cdk uh that that it needs to bootstrap based on new way of bootstrapping um and then i'll show what happens when when you basically bootstrap right so there is a way that you say cdk bootstrap then it will go and and bootstrap your aws account obviously in this case it will pick the aws account that is configured based on my aws credentials and and under the hood it will basically go and create a stack called cdk toolkit and if you will go and dive a bit more into what it actually creates for you it will create a bunch of im roles and permissions which it needs to to function on your behalf right and if i dive a bit more into what this bootstrapping actually does um so you you okay it's not good you can basically do something like this which is you want to beforehand see what the bootstrapping will do you can do cdk bootstrap and show template and this is actually going to show you the the cloud formation template that it's going to run on your behalf right and this is what you're seeing is the new new template that it will run for you uh and if you want to see the difference you can basically have this environment variable uh disabled uh and once you do that it will basically pick the old template for you and if you can see here uh into the details it's very like basic stuff that it used to provision before it was an s3 bucket where it needs to store your asset etc but if i now switch to uh the new way of synthesizing things right and then i do bootstrap show template you'll see that there are a bunch of other im policies that it will create for you right and and these are needed for cdk to act on your behalf to actually go ahead and deploy things say cross account right so it makes those things really easy for you and how you do that is basically uh trusting the account that you want to deploy to right so one of those command will look something like uh let me see something like this and if you look at this closely right this is basically saying cdk that you need to bootstrap uh this particular account which is over here and it needs to trust the account ending with three to one um and you also define something called cloud formation execution policy and this is a policy which uh cdk will use when it's going to deploy uh to this particular uh account which is ending with four five six right so if you set up a cdk pipeline you are say doing a cross account deployment these this is the policy that uh cdk will use to deploy to that account right and you might be wondering at this point that is this a good uh practice to give administrator access to a particular account to basically do anything inside another account and the short answer is no and that's why i wanted to bring up this topic uh because i've had few customers asking about this and there are few best practices that we actually recommend uh in our documentation uh so this is our cdk pipeline construct documentation page uh it's it's it is obviously having a lot of details but it also there is a section which also talks about cdk bootstrapping right um and it it documents all the stuff that i just told about like the new synthesis and all but if you go further down there is a section around best practices right and it's highlighted in yellow and and all those things but but the short sort of summary is that basically you should not be using administrator access when trusting other accounts right so administrator access is something that you should use just once when you are bootstrapping uh the account where the cdk pipeline is going to be existing but all the other trust that you will establish with with the cdk pipeline and the trusted account that should not have idly administrative access uh you should basically configure a policy that will uh basically support all the needs that you have from your cdk application so that would be the one way to go and then other thing that we recommend is actually configuring permission boundaries right so if i go back here uh where i was showing you show template part you'll see that uh this is the role uh which will be used by cdk to deploy stuff right and there is a way wherein you can point cdk to say that please don't use this particular cloud formation template but use what i am telling you to use right and we even link uh basically a sample template here sorry where we actually give you an example as to how you can create a permission boundary right so if you see here we are defining basically our own bootstrapping template but it's it's having all the same things which are expected by cdk pipeline but in addition uh we are defining a permission boundary and it's it's a good way for you to basically prevent uh developers or any other audience to quickly escalate their permissions uh inside like your cdk pipeline itself and then do whatever they want to do so permission boundary could like prevent actions like creating a new i am role on on their behalf right so this is just one example so these are some of the best practices that you should be uh thinking about when you are actually going to use cdk pipeline in production setup right you should not be blindly just following the first part of the documentation because documentation is talking about to quickly get you up and running but but there is a section which which documents this best practice that i just told about uh in a good way as well so so do look at it uh if you are going to use this in a production like setup and i put pasted it the link in the chat and this boot strapping it needs to be done on each account that you would deploy to is that correct yes so that's a one-time setup that you need to do and then rest of the things will be taken care by cdk pipeline on your behalf so you don't need to traditionally how you would do is assume role and do all those stuff cdk pipeline will do that on your behalf so there's a comment in the chat that i suppose at some point the new style will be the only style at some point yes um i think it's even documented uh in one of our dock page cdk bootstrap i i think i can find that and then paste that here uh but at some point yes right now uh it's still like the legacy uh bootstrapping is still the default uh but but at some point it will definitely replace and and the there are certain advantages to the new bootstrapping as well like one of that is its version so you can actually say that pick this particular version of bootstrapping as well if for some reason you are incompatible with the new version right you heard it here first people legacy cdk that's that's interesting uh all right legacy cdk bootstrapping yes yep all right great pankaj thanks for that explanation back to oscar's demo then but first if you just joined us this is the aws nordic's office hours with miguel aguirre i'm joined by pankaj and asgard we're talking about aws cdk pipelines today keep your questions and comments coming in the chat of course thanks pankaj yeah that's a very important point about bootstrapping because if you use cdk before and you will try it just right away it will not work so please make sure that you bootstrap your environment with this new process uh and that will take care of things so i'm gonna cheat a little bit here because it's a video because i want to save our time and make sure that nothing breaks in production so i will just show you what actually happening so what we added this code and then um cdk asks us uh if like it shows us all the new security related resources that it wants to create first and it asks us okay do you want to actually do deploy these changes we say yes and then it's deploying our pipeline stack all the resources we can see here takes some time and then if we switch to the actual console we will see under code pipeline we will see this new pipeline that we call gdk pipeline so we can see already that it hooked up the source so it picked up the code from github uh it passed the build stage and uh it's now updating the pipeline but it's not really gonna update anything because we haven't added any steps to our pipeline right we just created the pipeline itself so the let's just pause there for a second i think this is important to to note as well that it's not a new server this we're not introducing something new a new cdk pipeline service we're using the same services that people are familiar with we're using uh code pipeline it's using code build and so on so it is once again using cdk for for setting things up and using these pipeline cicd tools that you're familiar with yeah and hopefully by the end of the session you will see how how many things it takes care of for you so yeah let's let's take a look at so actually from from this point forward we will not need to do any cdk uh commands anymore because we deployed the stack from now on all the updates that we're going to make we will just push to our repository that means that if you work with like if you have a team of developers they don't need to have aws credentials anymore at this point if you if you've set up this pipeline they can just push code to the to your repository to a specific branch that is uh configured here and that's it it will actually pick up this update automatically build it and deploy it that's pretty cool very cool so after we have our pipeline set up what we actually need to do now is create the actual stacks right the actual stacks that will hold our resources so what i'm going to do is take a like base stack application stack approach which is very common when you create one stack that holds so-called shared resources so in my case what i'm going to deploy is a web application that is running inside the container um and we're running it on far gate ecs so elastic containers service and so as a shared resources we will have vpc so basically we can have the same vpc but we can have a lot of containers that we run there and applications and we will create a cluster ecs cluster that as well can hold a lot of different applications so this is what we call to base stack stack that holds our shared resources so nothing really interesting here so actually you can see here how simple it is to create resources with a cdk you can see just three lines basically two lines of code and that's vpc created we just passed its name we specify how many availability zones we want for that vpc and that's it and we create a cluster for ecs as well just the cluster itself we supply it because it needs that and that's it and actually you can here's you can see here that we're going to kind of export it make it available for the other stack that we're going to create right because this ecs cluster will be used by application stack that we're going to uh create now as well just give me a second i hope you don't mind me copy pasting stuff but just again it's a lot of a lot of typing yeah a lot of uh especially here uh so here we have more stuff going on because this stack is actually going to define the containers themselves um you can see here that we are create importing basically the cluster we use the cluster that we pass from the base stack um we define the fargate task definition where we just basically say okay we want this much memory and this much cpu for our uh tasks then um one interesting thing here and that we're doing is the docker image asset so the actual application code is going to be here as well in the cdk pipeline code let me just copy this stuff from here so what we're going to do we are going to paste sorry we're going to paste this src folder here that holds our flask application and the docker file so that means that our ctk pipeline uh not will just deploy the resources it will actually build the the application itself so we are just telling it where to find our docker file we define the container itself um we're supplying the image the task definition that we already created and the interesting thing here is we pass environmental variables here to our containers uh what we're going to pass is just some strings but in the production environment you can basically pass this way the same way you can pass maybe configuration parameters or something like that that's pretty pretty useful we do some port mappings just to make sure that it is reachable uh we create security groups of course that we will attach to our cluster the service um here we are creating the application load balancer because we want to put it in front of our actual acs cluster and interact through the load balancer with our cluster so yeah that's it basically so we have baystack that have just a couple of resources that are shared and then we have application stack where we have most of the application related resources defined so now one last step which is kind of specific to um cdk pipeline is that if you used cdk before you can just already go and just deploy these two stacks and it will work but since we want to make them just as a part of of our cdk pipeline we want to group them into what we call a stage on the stage as you can guess from the name is basically just one step in the pipeline so we're saying okay add this stage to the the other step to to the pipeline and inside of that step we are basically just adding these uh stacks okay and we are just using some uh we are outputting some some values as well and we also here specify that okay we are we want to pass some of variables from the pipeline to our application here okay so since we have our stage now all we need to do is add this stage to our pipeline so we need to import it first and after that we need to create a stage here just define it so this is will be our stage we specify which account and which environment to deploy to so it's account number region and our variables that we want to pass there uh last step make sure that you add this stage to your pipeline with a simple command pipeline ad stage so this way uh if we deploy this and i'm gonna cheat a little bit here again and show you the video of what's gonna happen because yeah it's gonna take some time um interesting part here is that as like so far you see on the screen it's the same right the pipeline looks the same same stages and all that then actually it's updating itself at this point and when it does that you can see that it automatically adds all the stages that are needed for our uh uh in our pipeline so it adds now the asset step where we where the code build will actually build our docker image and then uh the application stage itself where we actually deploy our stacks and you can see them here base stack you it first it prepares it then deploys and then the app stack the order in which it deploys the stacks it knows because we have some dependencies there right we pass the vpc or the cluster from base stack to the application stack that's how it knows which order to use when deploying those so when that is ready so it will take some time again to actually deploy here you can see step by step let me just find the yeah step where i just go to my console grabbing the load balancer dns name and testing if it works and it does if you take a closer look so we have a red background we have a a greeting that says hi from my main account those we pass here actually so you can see here that we pass this and we pass the background color so now another really cool stuff that you can do is uh code uh with cc edk pipeline is you can just add another stage and it will use the state they stack the stacks that we already created before right uh the only difference being that we are just changing which environment that we want to deploy to so we just used the different account as you can see we still use the same region we pass a different uh variables here so and uh here also what we need to do we just go add stage and we add our alt stage which stands for alternative stage save it deploy it what you will see there is uh this basically so you will see that it does the same things as as usual it hooks it picks up the the new code updates the pipeline and we can see here that it's deploying it to the app stage first the same as in the last deployment and after that take a look here it it actually deploys it to upstage out which is alternative uh stack alternative environment uh sorry so basically it was just a couple of lines of code we deployed the same stack with actually different uh variables right we passed it a different environmental of harrybills there and we just like that deployed it to another account and here i am just finding the dns address again just to check that it works fine and [Music] it's loading it doesn't need so from the same from the same application code we see that the background is different now the the greeting is different now but we basically deployed it to to another region to another account and it was possible because as pancatch set is very important that you bootstrap your accounts in in advance so that second account that we're deploying to also needs to be bootstrapped and it needs to trust uh the domain account where our pipeline is located right so just a couple of questions from the chat based on what you just showed there's a question around using a different docker image because in your example now you're you're building uh an image and well i guess that's stored in ecr and you're using that image but you could basically for your ecs tasks you could use any docker image yes either a public public image or a private one if you have permissions to it yeah yeah so as far as i know at least for docker hub you can there is a construct that accepts even your credentials so yeah definitely you can pull images from docker hub for example from uh ecr for sure if you upload it as part of some other uh pipeline you can do that yes uh it's just in this example i want to to show that it's possible to bundle your application code with your cdk pipeline code yeah and i think that um perhaps is tied together with this question if you can deploy node.js apps and and i think you just answer that you can bundle any type of app you wish this is you've set up the infrastructure in this case using ecs and you use the it was a flask application i think yeah yeah but you could basically use any type of application for it definitely of course you can use whatever you want like as long as it can run inside the container it's fine cool then we have a question that's very very specific perhaps for a specific use case let's just see if you recognize that stuck in an error both source and artifacts must be set to code pipeline i want to use an artifact name defined in the build spec seems to be okay in the cloud formation templates yeah i think what it's referring to is that because with cdk pipeline it sort of it's an opinionated uh construct right so it assumes a lot of things on your behalf and one of that is is that it it sort of generates an artifact bucket for you so if your code build project already has a build spec defined i guess you can still do that via something called partial build spec let me see if i can show that for you it's something called this thing right so this is again an example in i don't know if you're showing my screen but this is again an example in in java uh creating a code pipeline or cdk pipeline but basically you can point it to a build spec file still but the artifact bucket uh that that is there is something which cdk controls for you so you still need to output uh the directory using primary output directory construct even though you are using a build spec file uh to sort of define your code build project so yeah based on the question i think that's what it was intended for but i might have misunderstood it as well otherwise i know pankaj is is eager to dive deeper into that question you can reach him on twitter you see his twitter handle next to well i guess next to him so feel free to to dm pankaj there as well one more thing i think which i wanted to touch upon because uh the question arised around is is that using uh again images from different account right uh can be this can be a different account as compared to where you want to ever deploy resources right so you don't need to trust that account in the same way as you would do account where you need to deploy resources right so there is a like a different option that you can use for such accounts which is trust for lookup right so you can segregate these two responsibilities saying that okay my cdk pipeline you need to trust this x account just for lookup purpose right and you can sort of cut down your im policies based on those requirements compared to what you would have trust for something where cdk pipeline will deploy something for you right that's great so ask was there anything left yes actually i just want to show a couple of more things so if you've noticed before what we saw is that cdk pipeline would we created two different um stages right so it would actually deploy first to the main account and the second to the alternative account and you might ask ask like why because they are not really in dependent on each other wouldn't it be faster if i could just deploy two stacks at the same time and you can do that and i just wanted to show what you need to do for that so there is a construct called wave as part of a cdk pipeline and basically wave is is a stage in itself but what you can do is you can add your stages to that wave and the stages that you add to your wave are actually going to be deployed in parallel and that's uh actually pretty interesting as well because just last week i had a conversation with a customer they wanted to deploy 10 um 10 stacks at the same time and they couldn't find the way of doing that like straightforward way of doing that so for them actually what seems to be very nice as solution in this case could be something like that just create a wave create a a pipeline create a wave add all these 10 stages that you want to deploy in parallel and that and that will work fine so if we save it now and again just show you the video what's going to happen when you do that so when you add that you will see that the the pipeline now looks like this basically the wave action now you can see that both of them are deployed in parallel and actually uh so you see that they have like the same sort of steps right until this first step will not complete uh in both of them they will not proceed to the second one and so on that's uh important to keep in mind but that's again it's a good solution like if you want to test something and you want to test them in different accounts it doesn't make sense to wait until like first account and the other you just push them at the same time and they will work and actually i mean at the end i guess i will show there that i can no i i'm not showing it but like the the containers themselves are still running and they work fine um and just one more thing until just give me a minute so for those of you who were looking closely you remember that we were outputting the load balancers address and you could i wonder why did we do that well as part of the test like just to test that our deployment worked fine we can add a another step that will run after our wave and this step will basically take our load balancers dns addresses right and we will run certain command that we basically will do uh curl and it will see if the status quo if if it's not 200 then it will exit with one basically it will throw an error at you and you will see it because the pipeline basically will fail in that case um yeah and that's kind of one way of doing some sort of like integration test uh something that you can automate and if i just show you how my current pipeline look it looks like now i hope you can see it so everything is the same i have my test here and then i'm not gonna show it in code but what you can do you can also add manual approval step so after you deploy and you see that your test is fine you probably will still want to check manually maybe or run some tests uh before you approve the switch to to production so here you can have the manual uh step well you will actually need to click approve and after that we will have another stage which i called pro stage and then it will actually deploy your application there so that is it that is everything i wanted to show you i hope you covered some basics that uh yeah helps you move faster with cdk pipeline very cool and i think if any of the viewers have ever set up a complete pipeline using cloud formation i think it's very obvious that this is a whole lot easier it is a lot of things involved to get that up and running and well just making changes to it is quite complex as well so using cdk pipeline seems to be a whole lot easier there's a pretty long question in the chat let me bring that up there we go if there's a new version of cdk should we you remove the existing cdk2 toolkit and reboot strap do for instance if there is an update to cdk do you need to reboot strap or is that not needed unless you now um are going to use cdk pipelines i need to use the well not the legacy the the new one yeah i i i don't think you need to like recreate it every time if you are already already using the modern or the new way of bootstrapping uh but there is obviously a migration path i think it's actually documented in the same cdk pipeline construct documentation page uh as to like if you have been using the old way of bootstrapping and now you want to use capabilities in cdk which requires you to have news new bootstrapping then there is a migration path as to how you can do and and what things you should be careful about because there is a things around role renaming if that happens then your existing pipelines might start to fail so it's it's i think very clearly documented in in troubleshooting issues section of the cdk construct or cdk pipeline construct so would that mean that um you you don't have to do it you probably don't have to do it but if things fail you should do it yeah is that the answer not really i i guess what i was trying to say is that in idle scenario you should not uh be required to do that if you are moving from old way to new way or you require some features that that requires you to have new bootstrapping then you have to obviously migrate away from the old way of bootstrapping and there is a migration sort of checklist as to how you should do that in the same cdk pipeline documentation right i can yeah i can say that i had to do that myself because i have i had one environment where i bootstrapped a while ago and haven't used that and then i wanted to deploy and i had to do the same so yes uh i think like if panker said that it's it's in the documentation is good but yeah i think when you kind of have this major update you better update like it's it manually basically yeah i think there is also a question regarding can you add a stage with a custom code build project and the answer to that is yes you can do that um so i guess when you were seeing oscar's code we were using shell step uh as as the default step and then it obviously is again a higher level abstraction on top of code build project uh but if gonna you show my screen there is a code build step as well that lets you have more control over uh some of the configurations and and basically have everything under your control for setting up a code build project so yeah you can definitely do that all right cool so this hour just flew by i know i know we had a lot more things we could have shown uh but we are actually approaching top of the eye hour uh i i know you wanted to show um you have about a minute to talk about it and we'll share the latest maybe this will be helpful for for people uh who are trying to sort of get head around how is it different right so this is an open source project which is available on aws samples uh it tries to sort of use different things uh not with an intention that you cannot do one thing with one tool or other thing with another tool it's basically trying to showcase different possibilities uh so basically this repo tries to set up this static website uh with cloudfront s3 static website distribution with cdk right and i wanted to actually dive a bit into it but basically if you go to front-end infrastructure folder of this it's obviously written in java but but there is there is a pipeline package inside it and it holds like front-end pipeline stack which sort of gives you an idea of what it would take if you have to do this via native code pipeline cdk constructs right so basically you still deal with a lot of the specifics of code build code pipeline and you have to sort of take care of stitching things together while at the same time if you go to this other construct as we call it it basically tries to set up the same thing for you but using cdk pipeline right and you can if you that was my intention to actually compare these two today and show that how much easier it becomes if you are sort of using cdk pipeline um um other thing uh that i wanted to show quickly uh for those who might not be familiar i don't think we have the time to be honest pankaj sorry about that but this this is a url that you can share it's a cdk workshop so for those of you who want to get like a hands-on experience this is a public workshop that you can use and it also has cdk pipeline as one of the topic all right that's great where is that workshop it is there okay everyone with that thanks everyone for watching let me see if i'm able to share it here we go thanks everyone for watching this has been another edition of aws nordic's office hour thanks pankaj and thanks askara for being with us today and i hope everyone enjoyed this session on cdk pipelines thank you very much and see you again next monday bye

Channel: Gunnar Grosch

Views: 102

Keywords:

Id: 5BpKoVJb7QI

Length: 60min 55sec (3655 seconds)

Published: Mon Sep 20 2021