AWS Cloudformation is an evolving managed service which facilitates infrastructure as a code in the cloud. What it means is that you can create AWS resources like EC2 instances, S3 buckets and many more just by writing code instead of using GUI console.
For instances, if you want to create 100 EC2 instances for production, and then later you have to create same for development and for testing and then may be later on, you might need to change the configuration of those EC2 instances then doing that by GUI would be a very tedious task. With CloudFormation, you just describe those EC2 instances once in a file called as template and then run it.
Now another cool thing here is that you don't have to write code for all those 100 EC2 instances in that template. You may just describe one EC2 instance and then use CloudFormation Macros to provision 100 or even more of them (AWS resource limits apply).
Anyway, CloudFormation templates are either written in JSON or in YAML and they grow big fairly quickly and it becomes hard to keep track of syntactical and other errors. With aws cloudformation validate-template or with GUI you can identify the mal-formatted template file but what about if you have written any property of a resource wrongly? What if the resource specification is not as per AWS resource specification document?
Enters AWS CloudFormation Linter.
Linting is an ancient concept from good old C era which refers to a tool to check the source code for any syntax or bugs. So CloudFormation Linter or cfn-lint is a nifty tool to check for syntactical and bugs in the template. I tried to catch any logical errors with cfn-lint in the template but it was unable to identify them. For example, in my template of building a code pipeline, I omitted the cfn-init signal to let CFN know that launch configuration is complete so that deployment group of CodeDeploy could use it, but it was unable to catch that. So it would be a great future feature for cfn-lint.
Following is an example as how to install it and then I have passed through one of my templates to identify any errors:
Another cool blog post by Chuck Meyer is here about cfn-lint and git pre-commit validation.
For instances, if you want to create 100 EC2 instances for production, and then later you have to create same for development and for testing and then may be later on, you might need to change the configuration of those EC2 instances then doing that by GUI would be a very tedious task. With CloudFormation, you just describe those EC2 instances once in a file called as template and then run it.
Now another cool thing here is that you don't have to write code for all those 100 EC2 instances in that template. You may just describe one EC2 instance and then use CloudFormation Macros to provision 100 or even more of them (AWS resource limits apply).
Anyway, CloudFormation templates are either written in JSON or in YAML and they grow big fairly quickly and it becomes hard to keep track of syntactical and other errors. With aws cloudformation validate-template or with GUI you can identify the mal-formatted template file but what about if you have written any property of a resource wrongly? What if the resource specification is not as per AWS resource specification document?
Enters AWS CloudFormation Linter.
Linting is an ancient concept from good old C era which refers to a tool to check the source code for any syntax or bugs. So CloudFormation Linter or cfn-lint is a nifty tool to check for syntactical and bugs in the template. I tried to catch any logical errors with cfn-lint in the template but it was unable to identify them. For example, in my template of building a code pipeline, I omitted the cfn-init signal to let CFN know that launch configuration is complete so that deployment group of CodeDeploy could use it, but it was unable to catch that. So it would be a great future feature for cfn-lint.
Following is an example as how to install it and then I have passed through one of my templates to identify any errors:
Another cool blog post by Chuck Meyer is here about cfn-lint and git pre-commit validation.
No comments:
Post a Comment