3 ms·
You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know wha
by firesteelrain 3y ago
You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP
- firesteelrain 3y agoMeaning we made our own wrapper for the terraform azure provider. The higher level does not expose those technical details. It just says virtual machine.
- drewcoo 3y agoThat's a lot like peppering your C code with #ifdef/#ifndef to write code that's "platform independent." Just like in the bad old days.
- firesteelrain 3y agoNo, it’s object oriented like
- mattpallissard 3y agoThis hould be done even if you don't care about being agnostic. Lay out your declarations in the format you'd like to interact with, then transform them to whatever they need to be.
- datahead 3y agoHow did you approach testing this? Anything to watch out for when defining abstractions? I'm following Crossplane's abstraction model.
- firesteelrain 3y agoSo we start with terraform fmt -check, terraform validate, and terraform plan. Contract tests are used Then we have test resources that get created, validated then instantly destroyed. If we don’t have access to the CSP, then we can only go as far as contract tests. I can’t integrate with it live such as GCP. Starting to look into Terratest.
- m_0x 3y ago> We have done it at my work to make it cloud agnostic just in case we need to go to another CSP Have you actually tested migrating Cloud Providers with your cloud-agnostic infrastructure?
- firesteelrain 3y agoYes we tested it with Azure Stack Hub and AWS Outposts