tfdoc, stages README

This commit is contained in:
Ludovico Magnocavallo 2022-02-16 10:14:51 +01:00
parent 9cd7b43f93
commit 4b73cc4de6
6 changed files with 38 additions and 27 deletions

View File

@ -346,10 +346,10 @@ Names used in internal references (e.g. `module.foo-prod.id`) are only used by T
| name | description | sensitive | consumers |
|---|---|:---:|---|
| [billing_dataset](outputs.tf#L57) | BigQuery dataset prepared for billing export. | | |
| [custom_roles](outputs.tf#L62) | Organization-level custom roles. | | |
| [project_ids](outputs.tf#L67) | Projects created by this stage. | | |
| [providers](outputs.tf#L78) | Terraform provider files for this stage and dependent stages. | ✓ | <code>stage-01</code> |
| [tfvars](outputs.tf#L87) | Terraform variable files for the following stages. | ✓ | |
| [billing_dataset](outputs.tf#L58) | BigQuery dataset prepared for billing export. | | |
| [custom_roles](outputs.tf#L63) | Organization-level custom roles. | | |
| [project_ids](outputs.tf#L68) | Projects created by this stage. | | |
| [providers](outputs.tf#L79) | Terraform provider files for this stage and dependent stages. | ✓ | <code>stage-01</code> |
| [tfvars](outputs.tf#L88) | Terraform variable files for the following stages. | ✓ | |
<!-- END TFDOC -->

View File

@ -179,12 +179,12 @@ Due to its simplicity, this stage lends itself easily to customizations: adding
| name | description | sensitive | consumers |
|---|---|:---:|---|
| [networking](outputs.tf#L100) | Data for the networking stage. | | |
| [project_factories](outputs.tf#L109) | Data for the project factories stage. | | |
| [providers](outputs.tf#L125) | Terraform provider files for this stage and dependent stages. | ✓ | <code>02-networking</code> · <code>02-security</code> · <code>xx-sandbox</code> · <code>xx-teams</code> |
| [sandbox](outputs.tf#L132) | Data for the sandbox stage. | | <code>xx-sandbox</code> |
| [security](outputs.tf#L142) | Data for the networking stage. | | <code>02-security</code> |
| [teams](outputs.tf#L152) | Data for the teams stage. | | |
| [tfvars](outputs.tf#L165) | Terraform variable files for the following stages. | ✓ | |
| [networking](outputs.tf#L101) | Data for the networking stage. | | |
| [project_factories](outputs.tf#L110) | Data for the project factories stage. | | |
| [providers](outputs.tf#L126) | Terraform provider files for this stage and dependent stages. | ✓ | <code>02-networking</code> · <code>02-security</code> · <code>xx-sandbox</code> · <code>xx-teams</code> |
| [sandbox](outputs.tf#L133) | Data for the sandbox stage. | | <code>xx-sandbox</code> |
| [security](outputs.tf#L143) | Data for the networking stage. | | <code>02-security</code> |
| [teams](outputs.tf#L153) | Data for the teams stage. | | |
| [tfvars](outputs.tf#L166) | Terraform variable files for the following stages. | ✓ | |
<!-- END TFDOC -->

View File

@ -383,10 +383,10 @@ Don't forget to add a peering zone in the landing project and point it to the ne
| name | description | sensitive | consumers |
|---|---|:---:|---|
| [host_project_ids](outputs.tf#L51) | Network project ids. | | |
| [host_project_numbers](outputs.tf#L56) | Network project numbers. | | |
| [shared_vpc_self_links](outputs.tf#L61) | Shared VPC host projects. | | |
| [tfvars](outputs.tf#L80) | Terraform variables file for the following stages. | ✓ | |
| [vpn_gateway_endpoints](outputs.tf#L66) | External IP Addresses for the GCP VPN gateways. | | |
| [host_project_ids](outputs.tf#L52) | Network project ids. | | |
| [host_project_numbers](outputs.tf#L57) | Network project numbers. | | |
| [shared_vpc_self_links](outputs.tf#L62) | Shared VPC host projects. | | |
| [tfvars](outputs.tf#L81) | Terraform variables file for the following stages. | ✓ | |
| [vpn_gateway_endpoints](outputs.tf#L67) | External IP Addresses for the GCP VPN gateways. | | |
<!-- END TFDOC -->

View File

@ -328,11 +328,11 @@ DNS configurations are centralised in the `dns.tf` file. Spokes delegate DNS res
| name | description | sensitive | consumers |
|---|---|:---:|---|
| [cloud_dns_inbound_policy](outputs.tf#L50) | IP Addresses for Cloud DNS inbound policy. | | |
| [host_project_ids](outputs.tf#L55) | Network project ids. | | |
| [host_project_numbers](outputs.tf#L60) | Network project numbers. | | |
| [shared_vpc_self_links](outputs.tf#L65) | Shared VPC host projects. | | |
| [tfvars](outputs.tf#L80) | Terraform variables file for the following stages. | ✓ | |
| [vpn_gateway_endpoints](outputs.tf#L70) | External IP Addresses for the GCP VPN gateways. | | |
| [cloud_dns_inbound_policy](outputs.tf#L51) | IP Addresses for Cloud DNS inbound policy. | | |
| [host_project_ids](outputs.tf#L56) | Network project ids. | | |
| [host_project_numbers](outputs.tf#L61) | Network project numbers. | | |
| [shared_vpc_self_links](outputs.tf#L66) | Shared VPC host projects. | | |
| [tfvars](outputs.tf#L81) | Terraform variables file for the following stages. | ✓ | |
| [vpn_gateway_endpoints](outputs.tf#L71) | External IP Addresses for the GCP VPN gateways. | | |
<!-- END TFDOC -->

View File

@ -306,8 +306,8 @@ Some references that might be useful in setting up this stage:
| name | description | sensitive | consumers |
|---|---|:---:|---|
| [kms_keys](outputs.tf#L52) | KMS key ids. | | |
| [stage_perimeter_projects](outputs.tf#L57) | Security project numbers. They can be added to perimeter resources. | | |
| [tfvars](outputs.tf#L67) | Terraform variable files for the following stages. | ✓ | |
| [kms_keys](outputs.tf#L53) | KMS key ids. | | |
| [stage_perimeter_projects](outputs.tf#L58) | Security project numbers. They can be added to perimeter resources. | | |
| [tfvars](outputs.tf#L68) | Terraform variable files for the following stages. | ✓ | |
<!-- END TFDOC -->

View File

@ -2,7 +2,18 @@
Each of the folders contained here is a separate "stage", or Terraform root module.
They are designed to be combined together, each stage leveraging the previous stage's resources and providing outputs to the following stages, but they can also be run in isolation if their specific functionality is all that is needed (e.g. only bring up a hub and spoke VPC in an existing environment).
Each stage can be run in isolation (for example to only bring up a hub and spoke VPC in an existing environment), but when combined together they form a modular setup that allows top-down configuration of a whole GCP organization.
When combined together, each stage is designed to leverage the previous stage's resources and to provide outputs to the following stages via predefined contracts, that regulate what is exchanged.
This has two important consequences
- any stage can be swapped out and replaced by different code as long as it respects the contract by providing a predefined set of outputs and optionally accepting a predefined set of variables
- data flow between stages can be partially automated, reducing the effort and pain required to compile variables by hand
One important assumption is that the flow of data is always forward looking, so no stage should depend on outputs generated further down the chain. This greatly simplifies both the logic and the implementation, and allows stages to be effectively independent.
To achieve this, we rely on specific GCP functionality like [delegated role grants](https://medium.com/google-cloud/managing-gcp-service-usage-through-delegated-role-grants-a843610f2226) that allow controlled delegation of responsibilities, for example to allow managing IAM bindings at the organization level only for specific roles.
Refer to each stage's documentation for a detailed description of its purpose, the architectural choices made in its design, and how it can be configured and wired together to terraform a whole GCP organization. The following is a brief overview of each stage.