CDK App Lifecycle
In the previous part, we initialized our first CDK app using the sample application template provided by AWS. It will help you understand how CDK apps work before developing your apps with different levels of constructs in the following sections.
So, as a start, we have a sample code with L2 level SQS queue, and SNS topic constructs in our stack ready for deployment.
Well, in this part, we will see the lifecycle of a CDK application and then synthesize a CloudFormation template from our sample code using the CDK Toolkit.
Now, as in the last part you first initialize a CDK app and then customize it with some constructs and additional stacks according to your AWS architecture. Then, you deploy your source code with the CDK toolkit, and your application passes through some stages.
Construction (or Initialization):
The first phase is the construction phase. Now, although the construct term is used for building blocks to define your AWS resources, technically, application and stack classes are also constructs but of special types. So, in this phase, all constructs including app, stack, and their child constructs are instantiated, and their construction chains implemented by their init methods are executed. And most of your CDK code is executed at this stage.
Preparation:
Then, the preparation phase starts, which is a special phase for the constructs having the prepare() method. If a construct implements the prepare method, it is executed at this phase. Besides, it is the phase your CDK aspects are executed. The prepare method has a very rare usage, and it is not recommended to customize your constructs using this method. You will primarily define your code in the init methods of your stacks executed at the construction phase.
Validation:
Next, the validation phase begins, which is for validating whether your constructs will behave as expected. If a construct has the validate method defined, it is executed at this phase.
Synthesis:
And after the validation is finished, the synthesis phase starts, which creates the deployment artifacts by executing the synthesize() methods of all constructs. In your ‘app.py’ file, the main of your CDK app, the ‘app.synth()’ method call at the bottom triggers this synthesis process. And these deployment artifacts may include CloudFormation templates, Lambda function bundles, files, Docker image assets, etc. depending on the construct type.
Deployment:
And finally, all these deployment artifacts are deployed by creating CloudFormation stacks.
So, this is the lifecycle of a CDK app. The phases until the deployment are local.
So, can you generate the deployment artifacts without deploying them on CloudFormation? Maybe, you just want to see what your app produces, right? Well, CDK Toolkit provides a command for this purpose. So, let’s go back to our sample CDK application to continue.Open the sample project folder directly. As you see, the ‘app.py’ file is at the root of my folder on the Explorer.
Open the terminal again. And activate the virtual Python environment if it is inactive. And to synthesize the CloudFormation template from our CDK app, let’s type the ‘cdk synth’ command.
$ cdk synthAWS CDK creates a separate template for each stack, even if they are of the same class. So, if you have multiple stacks in your CDK app, you can provide the ones you want to synthesize as inputs to the synth command.
For example, in our case, you can provide ‘my-first-cdk-app’ as the stack name, which is the second input of the ‘MyFirstCdkAppStack’ class initializer in the ‘app.py’ code, the main of your CDK app. In CDK, the first input provided to a construct initializer is its scope, or in other words, where it is defined. So, in this case, the stack is defined under the app. And its second parameter is the identifier, making the stack name ‘my-first-cdk-app’. Anyway. Let’s continue with the command. If you have more stacks in your app, you can provide a second stack name for synthesis, using spaces after the first one like this. But we have a single stack in our app. So, no stack name is necessary; the ‘cdk synth’ command will be sufficient. When no stack is provided, it synthesizes all stacks in your app.
Once finished. As you see, it printed a CloudFormation template in YAML format, which is the template produced by the synthesis operation. It has an SQS queue resource as in our stack definition file in our CDK app. Then, there is also an SQS Queue policy resource, which allows the sample SNS topic resource, to send messages to the sample SQS queue. So next, we see the SNS subscription resource as defined in our CDK app, which subscribes the sample topic to the SQS queue. And finally, we have the SNS topic resource, which was referenced above.
But the template doesn’t finish here. As you see, there is also a CDK metadata resource, which CDK automatically adds to all templates generated. AWS CDK Team uses this resource for analytics and some security reporting. Likewise, there are more template sections below used by CDK, such as a condition for the CDK metadata. And at the bottom of the template, a parameter for the bootstrap version, which is an SSM parameter reference storing the bootstrap version used by this template.And a template rule to check this bootstrap version. So, if the CDK team publishes a new bootstrapping template with crucial modifications, it will ask you to update the bootstrapping stack you created in the last part by running ‘cdk bootstrap’ again as before.
If you noticed, now we have a new folder named ‘cdk.out’ in our project. ‘cdk synth’ places synthesized deployment artifacts under this folder. The ‘my-first-cdk-app.template.json’ file is the JSON version of the template. As side info, CloudFormation templates can be in JSON or YAML. The ‘cdk synth’ command prints the template in YAML format on the terminal but physically produces the template file in JSON.
Next, there is a CDK assets file in JSON format. This file holds the information about the file or Docker image assets generated by the synthesis operation and their target destinations when you deploy. For example, our CDK app has only the JSON template file as a file asset and the S3 bucket name and object key as the deployment destination. If you are familiar with CloudFormation, CloudFormation stacks require templates to be uploaded to S3 buckets in the same AWS region beforehand. So, during the deployment, this file will be uploaded to theS3 bucket destination here before creating the stack.
There is also a ‘manifest’ file in JSON, which defines a set of instructions to deploy the template or other assets if they exist. It is a file generated and used by CDK.You don’t need to worry about it. The ‘cdk deploy’ command we will cover later uses this file to perform the deployment.
There is also a ‘cdk.out’ file in JSON, which holds the version information the same as the version field in the assets file.It is another file used by CDK.
And finally, there is the ‘tree.json’ file, in other words, the construct tree, which holds the construct hierarchy in your CDK app in JSON.
So, the ‘App’ is the highest-level construct. Then comes ‘my-first-cdk-app’, the ID of your first stack as its child. And after that ‘MyFirstCdkAppQueue’, the sample SQS queue construct, the SNS topic construct, and others related to CDK metadata.
Let’s revisit the ‘my_first_cdk_app_stack’ file, which holds the sample stack’s class. As you see, these are the names of the constructs defined in this stack. In all construct definitions, the first input is the scope of the construct, and the second one is its ID. And ‘self’ here, indicates that the construct defined is the child of the current construct, which is the stack.
Additional Plugins:
Python extension provided by Microsoft. It introduces helpful features such as IntelliSense by installing additional extensions with it.
AWS Toolkit, the official Visual Studio Code extension for AWS applications. After installing it, you can open its view feature on the primary sidebar by clicking ‘AWS’ under the additional views.
On the CDK explorer, expand the ‘MyFirstCdkAppQueue’ this time. Well, there is a resource corresponding to the SQS queue resource in the CloudFormation template. And two more constructs under the scope of the SQS queue construct which are an SQS policy construct and an SNS topic subscription. These two constructs result from a single line adding an SQS subscription to the SNS topic resource. If you remember, they were also defined in the output template generated by the ‘cdk synth’ command.
Look at how CDK simplifies defining your infrastructure. This is how CDK works and synthesizes CloudFormation templates from your apps.
