aztfmod
seperate "rover" logic to allow custom container environments?
It seems 99% of the rover container is pretty standard fare, and that most the "magic" is the rover bash which has a clever way of determining the appropriate tfstate location in a standard way.
I have a few clients who love this model of approach, but would like to use custom dev containers with extra tools like packer/ansible (yes it makes things bigger, but standardizing for gitops is worth it). Are the plans to offer this wrapper seperatelly? Would be a huge win in terms of flexibility. Basically thinking of something like terragrunt: extra binary that depends on TF making it ultra portable.
@Justin-DynamicD we need some basic tools to get all the CAF features working properly. Rover does a more than remote state. It also provide consistency in the SRE team for devops engineers and in pipelines, regarless of the identity type used (interactive login, service principal, managed identities, cloud shell...) Those would be in the base tag:
- Azure Cli: required when calling rest api calls, to set the security context for terraform provider when running with service principals
- sql tool: required to create the azure sql db user and attach it to the user managed identity for password less access to sql db
- terraform: obvious
At the moment the image also includes, packer, ansible, go sdk for terratest, kubectl and some linter for code quality. Those could be in a separate tag.
Let me know your view.
@LaurentLesle So this ticket was opened a good long while ago, so some of my needs/client needs have changed a bit sense then, so I should re-review the rover as it exists now and make sure I understand these other pieces.
Using your base tag is not a bad alternative to what I was thinking, though I'd have to play with it and make sure I understand the behavior and patterns. When I first started doing this, I honestly struggled to get the landingzones to behave the way I expected them to (likely a misunderstanding of intent), so I ended up writing my own lightweight version of the rover as a bash script that stripped things down to the bare minimum: it searches the current subscription for storage accounts with a specific tag that marks it as a destination for state files. I could then make a completely custom container for the client and just copy that script in and tell them to run tfinit instead of terraform init and it would "figure out" all the backend details for you and they can go right to planning/applying per usual. Everything else in said container would be declared in the DockerFile and they could match the SRE expectations as needed. Thus the idea of using the rover as it's own "part" was born. I could adopt the idea of giving the SRE team a consistent environment via a container ... but that container could be easily customized to my client (because my rover was just a glorified bash script that ran on any distro)