zecfoundation
/
cloud-foundation-fabric
mirror of https://github.com/ZcashFoundation/cloud-foundation-fabric.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cloud-foundation-fabric/blueprints/factories
History
Ludovico Magnocavallo 819894d2ba
IAM interface refactor (#1595) 
* IAM modules refactor proposal

* policy

* subheading

* Update 20230816-iam-refactor.md

* log Julio's +1

* data-catalog-policy-tag

* dataproc

* dataproc

* folder

* folder

* folder

* folder

* project

* better filtering in test examples

* project

* folder

* folder

* organization

* fix variable descriptions

* kms

* net-vpc

* dataplex-datascan

* modules/iam-service-account

* modules/source-repository/

* blueprints/cloud-operations/vm-migration/

* blueprints/third-party-solutions/wordpress

* dataplex-datascan

* blueprints/cloud-operations/workload-identity-federation

* blueprints/data-solutions/cloudsql-multiregion/

* blueprints/data-solutions/composer-2

* Update 20230816-iam-refactor.md

* Update 20230816-iam-refactor.md

* capture discussion in architectural doc

* update variable names and refactor proposal

* project

* blueprints first round

* folder

* organization

* data-catalog-policy-tag

* re-enable folder inventory

* project module style fix

* dataproc

* source-repository

* source-repository tests

* dataplex-datascan

* dataplex-datascan tests

* net-vpc

* net-vpc test examples

* iam-service-account

* iam-service-account test examples

* kms

* boilerplate

* tfdoc

* fix module tests

* more blueprint fixes

* fix typo in data blueprints

* incomplete refactor of data platform foundations

* tfdoc

* data platform foundation

* refactor data platform foundation iam locals

* remove redundant example test

* shielded folder fix

* fix typo

* project factory

* project factory outputs

* tfdoc

* test workflow: less verbose tests, fix tf version

* re-enable -vv, shorter traceback, fix action version

* ignore github extension warning, re-enable action version

* fast bootstrap IAM, untested

* bootstrap stage IAM fixes

* stage 0 tests

* fast stage 1

* tenant stage 1

* minor changes to fast stage 0 and 1

* fast security stage

* fast mt stage 0

* fast mt stage 0

* fast pf
 		2023-08-20 09:44:20 +02:00
..
bigquery-factory Several updates 2023-05-13 23:51:46 -04:00
cloud-identity-group-factory Update factories and apigee tests 2023-02-25 19:26:11 +01:00
net-vpc-firewall-yaml Moved allow_net_admin to enable_features flag. Bumped provider version to 4.76 2023-08-07 14:27:20 +01:00
project-factory IAM interface refactor (#1595) 2023-08-20 09:44:20 +02:00
README.md Rename examples folder to blueprints 2022-09-09 16:38:43 +02:00

README.md

The why and the how of Resource Factories

Terraform modules can be designed - where it makes sense - to implement a resource factory, which is a configuration-driven approach to resource creation meant to:

  • accelerate and rationalize the repetitive creation of common resources, such as firewall rules and subnets
  • enable teams without Terraform specific knowledge to leverage IaC via human-friendly and machine-parseable YAML files
  • make it simple to implement specific requirements and best practices (e.g. "always enable PGA for GCP subnets", or "only allow using regions europe-west1 and europe-west3")
  • codify and centralise business logics and policies (e.g. labels and naming conventions)
  • allow to easily parse and understand sets of specific resources, for documentation purposes

Generally speaking, the configurations for a resource factory consists in one or more YaML files, optionally grouped in folders, that describe resources following a well defined, validable schema, such as in the example below for the subnet factory of the net-vpc module, which allows for the massive creation of subnets for a given VPC.

region: europe-west3
ip_cidr_range: 10.0.0.0/24
description: Sample Subnet in project project-prod-a, vpc-alpha
secondary_ip_ranges:
  secondary-range-a: 192.168.0.0/24
  secondary-range-b: 192.168.1.0/24

Terraform natively supports YaML, JSON and CSV parsing - however Fabric has decided to embrace YaML for the following reasons:

  • YaML is easier to parse for a human, and allows for comments and nested, complex structures
  • JSON and CSV can't include comments, which can be used to document configurations, but are often useful to bridge from other systems in automated pipelines
  • JSON is more verbose (reads: longer) and harder to parse visually for humans
  • CSV isn't often expressive enough (e.g. dit doesn't allow for nested structures)

If needed, converting factories to consume JSON is a matter of switching from yamldecode() to jsondecode() in the right place on each module.

Resource factories in Fabric

Fabric Modules

Dedicated Factories