Practical tips to improve your developments in CDK [Parte 2].
We’re back with our list of practical CDK tips. In the first article we talked about basic concepts, not related with CDK but any software project. We talk about naming convention, testing and tagging. Today we will talk about property management but, we are also going to talk about topics that are strictly related with CDK like constructs and Stacks. Here we go.
Property management
A very common practice in cloudformation involves add parameters in templates in order to customize them. In CDK, parameters already exist. However, it is not a good practice to use parameters as you can read in official documentation. AWS recommends centralizing property management in the CDK context. You should add the properties your app needs in context.json file or equivalent. In CDK there are so many ways to modify the context. In the below image you can see an example:
These properties will be used within the application as shown in the following image:
The stage property define which properties CDK have to use, pre, pro or dev:
You can pass properties on the command line using the -c flag, so it is possible to deploy in any environment just changing the value of stage property. It is a good option, however, the greatest advantage of using CDK remains in use developer tools. So, why not use your favorite developer tools to manage properties? If you like manage your properties with YAML files then use them, if you store your properties in consul, use consul. Feel free to use any tool. Use a familiar tool will reduce learning curve, increase the quality of you developments, and it’s very likely you already implemented a properties management system in your company. Reuse you workflows it’s always a win-win.
If you don’t know how to manage secrets or you are considering new methods, we suggest you use AWS Systems Manager Parameter Store service. Parameter Store allows you to store configuration properties and secrets in a secure way. Retrieving values stored in the parameter store using CDK is pretty easy as you can see in the CDK documentation. Here is an example:
Stacks
In our experience working with CDK we have detected confusion about when and how to use stacks. A very typical question is to define the number of stacks that my CDK application should have. The answer to this question depends on several factors. We are going to see some guidelines that will help you structure your code, but bear in mind these guidelines are not set in stone.
Regarding the number of stacks, you should take into account what resources you will create and if it makes sense to group them within a stack or not. For example, if you need to create an infrastructure for a new software application, it is a good idea to create all resources that the application needs in just one stack. However, if you have to create resources shared for multiple applications or resources critical for your business, then consider creating those resources in their own stacks.
In short, you should group resources that are related to each other in some way, either because they are necessary for an application to work or because they are elements that work together, such as a VPC with its respective subnets and ACL networks. If a specific set of resources are critical for your company then create them into separate stack in order to avoid accidental updates. Then active stack termination protection and monitor it in some way, for instance, using cloudwatch events.
Constructs
Constructs are the base building blocks in CDK. Every resource is generated by a construct. There are different types of constructs, Level 1 (L1), Level 2 (L2) and Level 3 (L3). L1 constructs match 1 to 1 with Cloudformation resources. For each Cloudformation resource, there is a construct that implements it. L1 constructs are always named with the prefix Cfn. L1 constructs will have the same attributes as their equivalent in Cloudformation.
The L2 are the “curated” constructs. They have default values and they are very easy to use even if you don’t have much knowledge of cloud formation. Finally, the L3 corresponds to patterns that are designed to solve common problems in AWS, such as an API Gateway with a Lambda and a BD Dynamo.
All constructs are maintained by the CDK team, however, you can create your own construct and customize it, adapting it to your needs. We don’t recommend this practice but sometimes it is useful in certain cases, especially when you use an L2 type construct that has default values that don’t fit your needs. In any case, we recommend that you do not abuse this practice. Try to create as few custom constructs as possible.
Imagine the compliance of your company request that buckets cannot be publicly accessible and that all stored objects must be encrypted at rest. One way to satisfy those requirements would be to create your own custom construct and ask the DevOps team to use this construct instead of CDK L2 construct. Below we can see a custom implementation that meets compliance requirements. In the example you can see that the construct inherits from the Construct class instead of the Bucket class. We advise you to do it this way because in this way you can design more extensible constructs.
If you are looking for an alternative way to enforce the compliance in your CDK applications, then you should take a look at using Aspects. Aspects are the way to apply operations to all constructs for a given scope. With an Aspect you can verify that a certain resource is private, or it is already encrypted. In the following image, we can see a stack that creates a private S3 bucket using the custom construct from the previous example:
The kms_key attribute is empty, so objects stored within the bucket will not be encrypted. For this reason, we have created an Aspect called BucketChecker that checks that the buckets of the GekoPrivateBucket class have the encryption_key attribute defined. In case they do not have it defined, an exception will be thrown. In this way, making checks on the created resources is easier.
Resume
We have dealt with various topics, however, we have given priority to two key concepts. The first key concept is how to structure the code of a CDK application, that is, the number of stacks that an application should have, when and how to create a custom construct, how to create tests in CDK or how to deal with identifiers. A good structure helps save technical debt and improves the quality of the delivered code.
The second key concept is the compliance. Throughout both posts, we have provided ideas on how to meet the hypothetical requirements of a compliance. One of the most important lessons we have learned managing our clients’ infrastructure is that meet compliance requirements are really important. Defining a compliance could be painful at first, however the pros outweigh the cons. Compliance allows reducing IT risks, improves infrastructure governance and creates a framework that helps the different teams of a company (SRE, Development, SecOps, …) to interact and reach agreements. For that reason the code you generate in CDK should always keep in mind how to satisfy your company’s compliance.
We hope that you have enjoyed reading both posts and you have learned something useful, nothing would make us happier. If you need information about Cloud and the DevOps world, we invite you to contact us and keep checking out our blog in order to find other useful publications. See you soon!