4 ms·

I made a small example at https://gist.github.com/rjosephwright/f1485cddcc12dd651ec96558ac7601c6 https://gist.github.com/rjosephwright/f1485cddcc12dd651ec965...

by joseph 4y ago

I made a small example at https://gist.github.com/rjosephwright/f1485cddcc12dd651ec96558ac7601c6 https://gist.github.com/rjosephwright/f1485cddcc12dd651ec965.... There is no YAML, I use HCL for values as they are easier to validate and less error prone, then convert them with yamlencode().

MuffinFlavored 4y ago
Thank you. What are the advantages to this over a light shell script that uses `kubectl + helm` CLI tools in your opinion? You can just `terraform apply` and that's it? My concern is it adds a "third" technology/abstraction layer (Terraform) to another underlying 2 (Helm + Kubernetes, which are also "abstraction layers" in themself, right?)
- joseph 4y ago
  For me there is a benefit in having a single abstraction layer, the Terraform root module, to make IaC changes, and specifically one that is in the form of data rather than a script. The data incidentally contains everything required for reproducibility (all dependency versions are pinned, etc), and it always calls only versioned modules that are published independently. There is one Terraform wrapper script that runs from CI/CD and it is the only script, no matter what kind of change is being made, Kubernetes or otherwise. Teaching someone how to make a change is easy, they just need to make a change to the data and apply it. If the data layer doesn't support the necessary change, then work can be done to add the capability to one of the modules and then publish a new version. For simple needs this might be overkill, but in my environment it helps to keep things from getting out of hand. Helm and Kubernetes are abstraction layers, but very specific ones, whereas Terraform is a generic one that ties it all together.
  - MuffinFlavored 4y ago
    > There is one Terraform wrapper script that runs from CI/CD and it is the only script, no matter what kind of change is being made, Kubernetes or otherwise. Is it just basically: terraform init terraform apply -var "env=$ENV" -auto-approve
    - joseph 4y ago
      It also defines the state in a standard way, toggles CLI configuration if it is present in the root module, and does some validation.
      - MuffinFlavored 4y ago
        could you share it/expand on “defines the state”? i thought state was captured in tfstate and then terraform goes and “diffs”/checks if it is accurate or not
        joseph 4y ago
        I was referring to how and where we store it. Feel free to email me if you have more questions.

by joseph 4y ago

MuffinFlavored 4y ago

Thank you. What are the advantages to this over a light shell script that uses `kubectl + helm` CLI tools in your opinion? You can just `terraform apply` and that's it? My concern is it adds a "third" technology/abstraction layer (Terraform) to another underlying 2 (Helm + Kubernetes, which are also "abstraction layers" in themself, right?)

joseph 4y ago
For me there is a benefit in having a single abstraction layer, the Terraform root module, to make IaC changes, and specifically one that is in the form of data rather than a script. The data incidentally contains everything required for reproducibility (all dependency versions are pinned, etc), and it always calls only versioned modules that are published independently. There is one Terraform wrapper script that runs from CI/CD and it is the only script, no matter what kind of change is being made, Kubernetes or otherwise. Teaching someone how to make a change is easy, they just need to make a change to the data and apply it. If the data layer doesn't support the necessary change, then work can be done to add the capability to one of the modules and then publish a new version. For simple needs this might be overkill, but in my environment it helps to keep things from getting out of hand. Helm and Kubernetes are abstraction layers, but very specific ones, whereas Terraform is a generic one that ties it all together.
- MuffinFlavored 4y ago
  > There is one Terraform wrapper script that runs from CI/CD and it is the only script, no matter what kind of change is being made, Kubernetes or otherwise. Is it just basically: terraform init terraform apply -var "env=$ENV" -auto-approve
  - joseph 4y ago
    It also defines the state in a standard way, toggles CLI configuration if it is present in the root module, and does some validation.
    - MuffinFlavored 4y ago
      could you share it/expand on “defines the state”? i thought state was captured in tfstate and then terraform goes and “diffs”/checks if it is accurate or not
      - joseph 4y ago
        I was referring to how and where we store it. Feel free to email me if you have more questions.