3 ms·
We also were frustrated at the verboseness and vagaries of the terraform syntax. We ended up preprocessing them using jinja2, injecting our variables via its c
by nicois 7y ago
We also were frustrated at the verboseness and vagaries of the terraform syntax.
We ended up preprocessing them using jinja2, injecting our variables via its context, and using its cleaner syntax for expressing conditions, loops, etc. Now we have the best of both worlds.
- pm90 7y ago... until your jinja templating breaks for some obscure reason, or the underlying terraform resource upgrades (they follow the provider api after all), or if you need to do some state surgery and partition one terraform state into multiple ones, or until you want to import resources into the generated terraform or.... Apologies, I don't mean to be a downer. But... you're making your present life easier but making the code harder to maintain for future maintainers of your codebase.
- detaro 7y agoWhat's the more maintainable alternative? Is writing repeated constructs etc out individually really more maintainable, or are you referring to other ways of getting these things reduced?
- pm90 7y agoJust plain terraform modules, for now. I’m eagerly awaiting 0.12 so the language would have similar features as jinja templating.
- nitelord 7y agoI highly recommend taking a look at the AWS CDK. It's a relatively new project, still in beta and hasn't gotten a lot of attention yet. It allows you to use real programming languages to generate Cloudformation templates. In my eyes this is the best of both worlds.