Refactor Bedrock Terraform structure

[dtzar]

The current terraform structure doesn't allow people to bring their own infrastructure (i.e. vnet) and should optimize for modularity & composability. This proposal would align to DRY and allow many "environments" combinations. I'd also like to see at least one environment flavor have a default GitOps URL variable & ssh keys (no private key needed) set to enable some form of stack (i.e. cloud native stack) deployed to the cluster.

If there is a desire to make this module available in the public terraform registry, then I'd recommend to either: a. move the /aks/ folder contents to the root which may add other items in the above folder if desired OR b. add main. variables, output, etc. at the root which includes aks/* etc (similar to one of the environment examples)

bold - means this resource is put behind a count switch and corresponding var to enable/disable

• /aks/
  • main.tf - contents of current cluster/template/azure/aks.tf
  • backend.tf - contents of backend state configuration
  • flux.tf - contents of current cluster/template/azure/aks-flux/aks-flux.tf
  • virtual-node-addon.tf - installs virtual node addon
  • conditional-service.tf - optional services which would be tightly coupled to the AKS cluster. Test: If I deleted this cluster, would it make sense to delete this as well?
  • variables.tf - inputs.tf files for core bedrock module
  • outputs.tf - outputs for core bedrock module
• /backend-state/
  • Main.tf
  • storage.tf
  • Variables.tf
  • Outputs.tf
• /environments/ - composed module examples using only the tf code from surrounding folders
  • /simple/ - most basic install to get bedrock going with what we deem minimum useful functionality.
  • main.tf - sample module which contains one or more of the above module references
  • outputs.tf - reasonably desired outputs to what is deployed
  • variables.tf - uber list of all potential variables from above modules with safe defaults.
  • terraform.tfvars - required variables with empty strings assigned
  • /advanced/ - most comprehensive option with all services deployed/enabled
  • main.tf - sample module which contains aks + one or more of the above folder module references
  • outputs.tf - reasonably desired outputs to what is deployed
  • variables.tf - uber list of all potential variables from above modules with safe defaults. terraform.tfvars - required variables with empty strings assigned
  • /advanced-byo/ - mirrors the advanced example, but individual brings their own values for dependent services (i.e. vnet)
  • main.tf, output, variables, etc.
  • Readme.md - deeper explanation of module options
• /keyvault/
  • main, variables, outputs…
• /test/ - contains any unit/integration tests
• /trafficmanager/
  • main, variables, outputs…
• /vnet/
  • main, variables, outputs…
• readme.md - explanation of repo structure, link to environments/readme.md, testing project, pointers to other locations where it has walkthrough examples/applications.
• Travis/circle/azure-devops.yml - CI build definition
• .gitignore

[timfpark]

I'm assuming that all of this would be under the /cluster directory off of the root of the project - if so, this looks largely great.

One large question - we will likely have a multicloud project in the near future with GCP. Given that, should we add an azure layer to denote that everything contained in it is azure related? Tactically, I think this means that everything outside of perhaps /backend-state would be housed in this azure directory?

[dtzar]

I'm not sure why you would add the /cluster folder since everything in this repo creates the cluster (currently 83% HCL, 10% shell, 7 % Dockerfile and HCL % will increase once Dockerfile is gone).

As for multi-cloud I didn't consider this. I'd say to stick everything with the existing structure minus the files in the root to an /azure folder. Even the backend-state is specific to azure since it creates an Azure storage account for backend state. Other cloud providers could add a similar structure to Azure at the root /gcp/ or /aws/.

[timfpark]

The reasoning around having a /cluster top level directory is that @andrebriggs team is currently doing a bunch of work around the GitOps portion of this that will also land in the repo that is substantially different -- but builds on -- the cluster creation portion. I'm open to other ideas, but let's factor in -- and logically separate -- that part of the repo from the Terraform work.

In the current conception, all of that work lives in a top level gitops directory but we might want to consider in the long term breaking this out into at least a couple parts -- either at the top level or underneath gitops:

• cicd (which would cover building the Fabrikate definitions to YAML and checking them into the manifest repo)
• a second section that houses tooling and automation around build promotion along a canary hierarchy.

[dtzar]

Some alternative ideas to the gitops folder:

• Add something like gitops.md at the root which is linked to from the root readme.md. This could be similar to @andrebriggs readme here giving the what/why of bedrock + GitOps, but also link to all other GitOps examples/references which may be in other repositories.
• Cover the core Fabrikate dev + GitOps stuff in the Fabrikate repo
• For the tooling, automation, build promotion for canary live in a separate repo connected to a full example app/solution such as PuMRPmicro. I'd like to know what core tooling you think needs to be built for this scenario; it seems all the core tooling is there and what is needed is a detailed walthrough with the AzDO (or other orchestration tool like Jenkins) YAML/pipeline code. i.e. What Andre started here would live attached to an end-to-end PuMRPmicro (or other app) example.

This way the code in bedrock remains tied to the terraform/cluster creation which makes it a cleaner separation for CI/PRs as well as easier to understand the folder structure. You can also keep the spirit of the GitOps attach via the readmes.