claranet / jinjaform

Terraform wrapper with Jinja2 templates
MIT License
35 stars 8 forks source link

Project initialization #14

Closed Dyllaann closed 5 years ago

Dyllaann commented 5 years ago

Hi!

I'm trying out Jinjaform as it looks like it could help me solve some project structure mess. Currently working with symlinks, so it's a bit messy...

I tried getting Jinjaform [0.3.2] into the project, but it gave me some errors. Instead, I moved to a fresh folder to see what jinjaform create would give me. I ended up with this. Image of jinjaform create result

The jinjaform create command was run inside azure-cloud-infra/terraform/ as it was not possible to run it inside azure-cloud-infra/ as this is also my project root and my environment variables are set to

export JINJAFORM_PROJECT_ROOT="/home/dyllaann/projects/azure-cloud-infra"
export JINJAFORM_TERRAFORM_BIN="/usr/local/bin/terraform"

Now, the documentation is not really clear about those environment variables, nor is it about the working directory/project root. I hope I did that part correctly now. One thing I do however miss after the create command is my .jinjaformrc How would I let one create for me, or where does one place one?

Thanks in advance for making this wrapper!

raymondbutcher commented 5 years ago

Hi @Dyllaann, thanks for trying it out!

I'm sorry but I changed project initialization in #13 which included README changes, but didn't release a new version. You were looking at instructions for the new version while getting error messages from the old version, talking about environment variables that are no longer used in the new version (which is why they aren't documented).

I've released 0.4.3 which matches the README. Please give it another try. Hopefully with the README matching the latest version it will make a lot more sense and work as expected. If not, please let me know so I can improve it.

Dyllaann commented 5 years ago

Hi Raymond,

Cool! Updating to 0.4.3 fixed the problem, yes! Initialization worked like a charm in my current repository :).

This was, however, after I manually changed /home/dyllaann/.local/bin/jinjaform from python -m jinjaform $* to python3 -m jinjaform $* Maybe a 'smart' way to determine which python to call could be useful!

Also, I have a question on .tfvars, as it does not seem Jinjaform takes care of including .tfvars in the jinjaform plan, is this right? As in, I have to manually add them with -var-file=*.tfvars ...

Dylan

raymondbutcher commented 5 years ago

Great!

I've added #15 for fixing the bin script.

Jinjaform only works with terraform.tfvars at the moment. There is #5 for supporting other cases. And #16 for fixing the example which I have just noticed is wrong.

The way I use this is to only have terraform.tfvars files, mostly in the lowest level directory (e.g. stacks/management/nonprod/terraform.tfvars and stacks/management/prod/terraform.tfvars but then if you want the same value in both environments you could set that in stacks/management/terraform.tfvars and that gets combined with the lower level file. But more commonly I would set a default value for the variable rather than have terraform.tfvars at multiple levels.

Does that make sense? Is that compatible with your project?

Dyllaann commented 5 years ago

Hi Raymond,

Cool! I'm also perfectly fine for changing python to python3 now and then untill you can figure something out.

I was indeed confused by the account.tfvars and site.tfvars. Good that is clear now :)!. As I do quite some infrastructural changes, I have quite some aliases set up so I do not to remember all the Terraform parameters. Suprisingly (seeing #5), those still work with Jinjaform! (e.g. jinjaform plan -var-file=prod.tfvars -var-file=common.tfvars -var-file=azure.tfvars) For the time being, I'll keep updating those to stay compatible with new changes.

For the future, and automatic *.tfvars merge and/or parameter generator will be the best solution. I might try out Python and see if I can come up with something myself.

Thanks for the quick replies!

Dylan

raymondbutcher commented 5 years ago

The command line arguments get passed through to Terraform so you can use var files like that. But it might not work as expected if you try to use those variables as Jinja2 template variables:

module "something" {
  source = "something"

  name = "${var.something_name}" # <-- regular variable usage
  name = "{{ var.something_name }}" # <--- jinja2 template variable usage
}

If you put your values in terraform.tfvars then Jinjaform will find them and you can use them in templates. But if the file is named something else then Jinjaform won't read the values in for template rendering.

I previously had it reading/merging all *.tfvars files but realised that it's nonstandard Terraform behaviour and not compatible with all projects. Say someone has nonprod.tfvars and prod.tfvars and wants to use -var-file=nonprod.tfvars to get only those variables, it would be surprising if Jinjaform combined them. I think sticking with standard Terraform behaviour is the way to go here.

Thanks for trying the project! Let me know if anything is broken or not obvious and I'll try to improve it.