Mocking Terraform AWS Using Docker
diego-pacheco.blogspot.com
diego-pacheco.blogspot.com
Terraform comes with `terraform plan`, which does a cursory validation of the infrastructure-as-code, diffs it against the current state of the world in various accounts, and reports back with what it expects to execute. While there are some cases where `terraform plan` succeeds and `terraform apply` errors, they tend to be cases that I don't think mocking would catch. For example:
- Certain AWS resource naming restrictions are not handled by `terraform plan`, but are caught by the AWS API, causing `terraform apply` to fail.
- The validity of AWS ACM certificates (issued vs pending) is not handled by `terraform plan` -- `plan` assumes that any certificate ARN provided is valid and issued, whereas the AWS API will error if the certificate is not valid, prompting `terraform apply` to fail.
There are plenty more examples (duplicate security group rules come to mind as a particularly egregious offender). I'm just not sure I see what value this provides -- if I'm missing something, please do let me know!
IMHO the main use cases for me is: - Speed up development time by doing tests locally - don't need to commit and wait a build kick it and see whats wrong. - Able to be part of the bigger scheme where you can test your whole "infrastructure" or part of it at least we still limited by localstack.
>> - Speed up development time by doing test locally - don't need to commit and wait a build kick it and see whats wrong
Combined with the article linked, it sounds like you're working in an environment where the only machine authorized to interact with AWS, or retain the Terraform statefile, is a Jenkins build server. Might I suggest investigating Terraform Enterprise (despite the name, it's rather affordable, for what you're getting)? TFE integrates with Github (and other VCS) pull requests, allowing a pull request to trigger a `terraform plan`. This gives a pretty good understanding of whether your changes are going to succeed or not, and are pretty quick to run -- I work on some rather large projects, and have never waited more than a few minutes for a plan to complete.
If you're allowed to pull down the statefile, you can also just run `terraform state pull > terraform.tfstate && terraform plan`.
>> - Able to be part of the bigger scheme where you can test your whole "infrastructure" or part of it at least we still limited by localstack.
In my experience, mocking systems like `localstack` are never quite up to the "standard" of the systems they intend to mock (AWS in this case). Of particular note, AWS's APIs, especially for newer products, tend to have lots of "gotchas" that are undocumented or hard to trace back -- things that are extremely unlikely to be covered well in a mocking framework.
If this works well for you, great! Just giving my two cents, as someone who has thought a lot about this and wound up right back at `terraform plan`.
AWS moves pretty FAST, but I don't know anything better than LocalStack fro AWS mocking.
One can test Terraform scripts without requiring it be hooked into Jenkins. If I have an account with a supported provider, testing during development of said script(s) isn't really that hard.
Sometimes when you use PACKER and you have a SHARED infrastructure a build could take 40mim to run all the things with Terraform/Ansible that kind of a mainframe :D Unfortunately this exit :(