Deploying Your CDK Stack
In the previous part, we discussed the CDK app lifecycle, and you saw how a few lines of CDK code produced a detailed CloudFormation template after synthesizing. In this part, we will deploy the stack defined in our sample CDK app and see what it produces.
Now, if you remember from the last lecture, during a deployment, CDK first synthesizes CloudFormation templates or other artifacts like Lambda bundles from your CDK code and then deploys them using CloudFormation.
You can use the ‘cdk synth’ command to produce these deployment artifacts from your app.
But do you have to synthesize your CDK app before each deployment? No. The ‘cdk deploy’ command we will use in a few minutes synthesizes your CDK app in each call before creating CloudFormation stacks, regardless of whether you synthesized it before or not.
So, let’s go back to our sample CDK code to deploy our app.
In the ‘app.py’ file, the main of our CDK app, we have a single stack declaration of ‘MyFirstCdkAppStack’ class, whose name is ‘my-first-cdk-app’. Now, CDK apps produce a CloudFormation template for each stack deployed. It is why we had a single template after synthesizing it in the last part. So, if you remove this line, no stacks will be deployed. It is how you define and create stacks in your app.
And in the stack’s class definition, the ‘init’ method is used to write the stack code. If you remember from the last part, it is where the construction phase work in the CDK app lifecycle.
Its first statement calls the init method of its parent class, which is the ‘Stack’ class, to initialize with the defaults. And then, we customize our stack below that. In our sample app, we have an SQS queue construct and an SNS topic construct. Then, we subscribe the SQS queue to the SNS topic using the ‘add_subscription’ method of the SNS topic construct.This method is provided by the AWS CDK team with the SNS topic construct.
As side info, these are L2-level constructs. L1-level constructs are pure CloudFormation resources with no additional methods like ‘add_subscription’ here. They also start with ‘Cfn’.
Now, let’s open the terminal to deploy our sample CDK app. The terminal automatically initializes the virtual Python environment in my Visual Studio Code. If yours is not, please do so.
Let’s type the ‘cdk deploy’ command, which deploys CloudFormation stacks from your CDK apps. Now, if you have multiple stacks in your CDK app, you can provide the names of stacks that will be deployed as input. For example, in our case, it will be ‘my-first-cdk-app’ as you saw in the ‘app.py’ file. Or another stack if it exists, such as ‘my-second-stack’ after spaces. But it needs to be declared in your ‘app.py’ file. Or if you want all your stacks to be deployed in parallel, you can provide the ‘ — all’ option to the ‘cdk deploy’ command. So, if you have multiple stacks, you must give the stack names or the ‘ — all’ option.
However, we have a single stack in our CDK app. In this case, there is no need to provide anything. It will just deploy the only stack we have. Let’s press Enter to execute the command. It says there is an IAM statement, which results from the SQS queue policy resource providing access to the SNS topic to send messages to it. When some permission is assigned in a stack, all CloudFormation, and CDK deployments as a result, ask for approval. Let’s provide ‘y’ and press Enter to continue.
As you see, the ‘cdk deploy’ command provides a visual interface to monitor the deployment. If you are familiar with CloudFormation, you might have already realized that these are stack-creation events.
The ‘my-first-cdk-app’ stack was deployed, and we also see its Amazon Resource Name, or shortly ARN, printed here.
Please also note how it displayed the durations of the deployment phases. It printed how long the command took in total and how much of this was during the CloudFormation deployment and the local synthesis operation. It is a nice feature to detect unexpected delays.
Now, let’s go to the CloudFormation Console to see what happened there.
We see two stacks here. The one deployed by our sample CDK app is the ‘my-first-cdk-app’ stack as defined in the app code and as we saw in the Terminal output.
There is also ‘CDKToolkit’ stack. It is the stack that bootstrapped our CDK environment.
So, let’s click the ‘my-first-cdk-app’ stack to view its details.
The ‘Events’ tab displays the stack events.Please note how they are similar to the events we saw while executing the ‘cdk deploy’ command. Let’s switch to the ‘Resources’ tab. So, this is where you display the AWS resources created and managed by your stack. When you create a CloudFormation stack using CDK, CloudFormation Console displays your resources in the ‘Tree view’. This view shows your resources as in the construct tree, like the CDK Explorer feature of the AWS Toolkit on Visual Studio Code. Your resources are grouped by the CDK constructs creating them. Therefore, you know which CloudFormation resource was created by which CDK construct.
You can still switch to the standard CloudFormation stack resources view by activating the ‘Flat view’ instead. However, the flat view says nothing about the constructs creating your AWS resources.
The first two constructs are the ones defined in our sample app. Their names are exactly like in their corresponding declarations in the init method of the stack class definition. But the ‘CDKMetadata’ construct is automatically added by CDK in all stacks and is used by the AWS CDK team for analytics.
Let’s enlarge the first construct, ‘MyFirstCdkAppQueue’. We see an Amazon SQS queue resource with its URL as the physical ID.
It is the main resource of the queue construct. And as you see, there are two more inner constructs created. Let’s see what is in the ‘Policy’ construct. It has an SQS queue policy resource.Inside the ‘MyFirstCdkAppQueue’ construct,i t has an Amazon SNS topic subscription resource. So, these two inner constructs are automatically created after subscribing the SQS queue to the SNS topic via the ‘add_subscription’ method in the stack code.
Then, where is the SNS topic? Let’s enlarge the remaining construct at the root of our stack, ‘MyFirstCdkAppTopic’.
It has an SNS topic resource created. As you see, you don’t have to know how to define the Queue policy or SNS subscription resources. The ‘add_subscription’ method provides them for you.
You can also see the template deployed by switching to the ‘Template’ tab on your stack. It is the same CloudFormation template in JSON created by the ‘synthesize’ operation in the last part. However, the ‘cdk deploy’ command recreated it before the deployment anyway.
