From da2f601c9ad46d217127ca5ef32394f1c83a431f Mon Sep 17 00:00:00 2001 From: Julio Castillo Date: Fri, 9 Sep 2022 15:59:57 +0200 Subject: [PATCH] More updates --- CONTRIBUTING.md | 8 +++---- README.md | 2 +- blueprints/README.md | 8 +++---- blueprints/cloud-operations/README.md | 24 +++++++++---------- blueprints/cloud-operations/adfs/README.md | 2 +- .../README.md | 2 +- .../cloud-operations/binauthz/README.md | 2 +- .../dns-fine-grained-iam/README.md | 12 +++++----- .../iam-delegated-role-grants/README.md | 2 +- .../README.md | 2 +- .../quota-monitoring/README.md | 2 +- .../unmanaged-instances-healthcheck/README.md | 2 +- .../cloud-operations/vm-migration/README.md | 8 +++---- .../workload-identity-federation/README.md | 2 +- blueprints/data-solutions/README.md | 8 +++---- blueprints/foundations/README.md | 18 +++++++------- blueprints/gke-serverless/README.md | 6 ++--- blueprints/networking/README.md | 24 +++++++++---------- blueprints/networking/ilb-next-hop/README.md | 4 ++-- .../onprem-google-access-dns/README.md | 6 ++--- blueprints/serverless/api-gateway/README.md | 8 +++---- blueprints/third-party-solutions/README.md | 4 ++-- 22 files changed, 78 insertions(+), 78 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 083d8fa41..9495676f5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -66,7 +66,7 @@ Keep in mind we also test documentation examples so even if your PR only changes ```bash # use if you only changed README examples, ignore if you ran all tests -pytest tests/doc_examples +pytest tests/examples ``` Once everything looks good, add/commit any pending changes then push and open a PR on GitHub. We typically enforce a set of design and style conventions, so please make sure you have familiarized yourself with the following sections and implemented them in your code, to avoid lengthy review cycles. @@ -535,7 +535,7 @@ locals { ### Interacting with checks, tests and tools -Our modules are designed for composition and live in a monorepo together with several end-to-end examples, so it was inevitable that over time we found ways of ensuring that a change does not break consumers. +Our modules are designed for composition and live in a monorepo together with several end-to-end blueprints, so it was inevitable that over time we found ways of ensuring that a change does not break consumers. Our tests exercise most of the code in the repo including documentation examples, and leverages the [tftest Python library](https://pypi.org/project/tftest/) we developed and independently published on PyPi. @@ -606,9 +606,9 @@ As our testing needs are very simple, we also wanted to reduce the friction requ The last piece of our testing framework is our [`tftest`](https://pypi.org/project/tftest/) library, which wraps the Terraform executable and returns familiar data structures for most commands. -##### Testing end to end examples +##### Testing end-to-end examples -Putting it all together, here is how an end-to-end example test works. +Putting it all together, here is how an end-to-end blueprint test works. Each example is a Python module in its own directory, and a Terraform fixture that calls the example as a module: diff --git a/README.md b/README.md index cdf9f9efe..2eed5d892 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ # Terraform Examples and Modules for Google Cloud -This repository provides **end-to-end examples** and a **suite of Terraform modules** for Google Cloud, which support different use cases: +This repository provides **end-to-end blueprints** and a **suite of Terraform modules** for Google Cloud, which support different use cases: - organization-wide [landing zone blueprint](fast/) used to bootstrap real-world cloud foundations - reference [blueprints](./blueprints/) used to deep dive on network patterns or product features diff --git a/blueprints/README.md b/blueprints/README.md index 9fd52977c..5c2705c7b 100644 --- a/blueprints/README.md +++ b/blueprints/README.md @@ -1,11 +1,11 @@ -# Terraform end-to-end examples for Google Cloud +# Terraform end-to-end blueprints for Google Cloud -This section contains **[foundational examples](./foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking examples](./networking/)** that implement core patterns or features, **[data solutions examples](./data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations examples](./cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./factories/)** that implement resource factories for the repetitive creation of specific resources. +This section contains **[foundational blueprints](./foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking blueprints](./networking/)** that implement core patterns or features, **[data solutions blueprints](./data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations blueprints](./cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./factories/)** that implement resource factories for the repetitive creation of specific resources. -Currently available examples: +Currently available blueprints: - **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](./cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./cloud-operations/packer-image-builder), [On-prem SA key management](./cloud-operations/onprem-sa-key-management), [TCP healthcheck for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck), [HTTP Load Balancer with Cloud Armor](./cloud-operations/glb_and_armor) -- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/gcs-to-bq-with-least-privileges/), [Cloud Storage to Bigquery with Cloud Dataflow with least privileges](./data-solutions/gcs-to-bq-with-least-privileges/), [Data Platform Foundations](./data-solutions/data-platform-foundations/), [SQL Server AlwaysOn availability groups example](./data-solutions/sqlserver-alwayson), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion/) +- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/gcs-to-bq-with-least-privileges/), [Cloud Storage to Bigquery with Cloud Dataflow with least privileges](./data-solutions/gcs-to-bq-with-least-privileges/), [Data Platform Foundations](./data-solutions/data-platform-foundations/), [SQL Server AlwaysOn availability groups blueprint](./data-solutions/sqlserver-alwayson), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion/) - **factories** - [The why and the how of resource factories](./factories/README.md) - **foundations** - [single level hierarchy](./foundations/environments/) (environments), [multiple level hierarchy](./foundations/business-units/) (business units + environments) - **networking** - [hub and spoke via peering](./networking/hub-and-spoke-peering/), [hub and spoke via VPN](./networking/hub-and-spoke-vpn/), [DNS and Google Private Access for on-premises](./networking/onprem-google-access-dns/), [Shared VPC with GKE support](./networking/shared-vpc-gke/), [ILB as next hop](./networking/ilb-next-hop), [PSC for on-premises Cloud Function invocation](./networking/private-cloud-function-from-onprem/), [decentralized firewall](./networking/decentralized-firewall) diff --git a/blueprints/cloud-operations/README.md b/blueprints/cloud-operations/README.md index ffa727a46..36feb028c 100644 --- a/blueprints/cloud-operations/README.md +++ b/blueprints/cloud-operations/README.md @@ -1,64 +1,64 @@ -# Operations examples +# Operations blueprints -The examples in this folder show how to wire together different Google Cloud services to simplify operations, and are meant for testing, or as minimal but sufficiently complete starting points for actual use. +The blueprints in this folder show how to wire together different Google Cloud services to simplify operations, and are meant for testing, or as minimal but sufficiently complete starting points for actual use. ## Resource tracking and remediation via Cloud Asset feeds This [example](./asset-inventory-feed-remediation) shows how to leverage [Cloud Asset Inventory feeds](https://cloud.google.com/asset-inventory/docs/monitoring-asset-changes) to stream resource changes in real time, and how to programmatically use the feed change notifications for alerting or remediation, via a Cloud Function wired to the feed PubSub queue. -The example's feed tracks changes to Google Compute instances, and the Cloud Function enforces policy compliance on each change so that tags match a set of simple rules. The obvious use case is when instance tags are used to scope firewall rules, but the example can easily be adapted to suit different use cases. +The blueprint's feed tracks changes to Google Compute instances, and the Cloud Function enforces policy compliance on each change so that tags match a set of simple rules. The obvious use case is when instance tags are used to scope firewall rules, but the blueprint can easily be adapted to suit different use cases.
## Scheduled Cloud Asset Inventory Export to Bigquery - This [example](./scheduled-asset-inventory-export-bq) shows how to leverage the [Cloud Asset Inventory Exporting to Bigquery](https://cloud.google.com/asset-inventory/docs/exporting-to-bigquery) feature, to keep track of your organization's assets over time storing information in Bigquery. Data stored in Bigquery can then be used for different purposes like dashboarding or analysis. + This [blueprint](./scheduled-asset-inventory-export-bq) shows how to leverage the [Cloud Asset Inventory Exporting to Bigquery](https://cloud.google.com/asset-inventory/docs/exporting-to-bigquery) feature, to keep track of your organization's assets over time storing information in Bigquery. Data stored in Bigquery can then be used for different purposes like dashboarding or analysis.
## Granular Cloud DNS IAM via Service Directory - This [example](./dns-fine-grained-iam) shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS. The example creates a Service Directory namespace, a Cloud DNS private zone that uses it as its authoritative source, service accounts with different levels of permissions, and VMs to test them. + This [blueprint](./dns-fine-grained-iam) shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS. The blueprint creates a Service Directory namespace, a Cloud DNS private zone that uses it as its authoritative source, service accounts with different levels of permissions, and VMs to test them.
## Granular Cloud DNS IAM for Shared VPC - This [example](./dns-shared-vpc) shows how to create reusable and modular Cloud DNS architectures, by provisioning dedicated Cloud DNS instances for application teams that want to manage their own DNS records, and configuring DNS peering to ensure name resolution works in a common Shared VPC. + This [blueprint](./dns-shared-vpc) shows how to create reusable and modular Cloud DNS architectures, by provisioning dedicated Cloud DNS instances for application teams that want to manage their own DNS records, and configuring DNS peering to ensure name resolution works in a common Shared VPC.
## Compute Engine quota monitoring - This [example](./quota-monitoring) shows a practical way of collecting and monitoring [Compute Engine resource quotas](https://cloud.google.com/compute/quotas) via Cloud Monitoring metrics as an alternative to the recently released [built-in quota metrics](https://cloud.google.com/monitoring/alerts/using-quota-metrics). A simple alert on quota thresholds is also part of the example. + This [blueprint](./quota-monitoring) shows a practical way of collecting and monitoring [Compute Engine resource quotas](https://cloud.google.com/compute/quotas) via Cloud Monitoring metrics as an alternative to the recently released [built-in quota metrics](https://cloud.google.com/monitoring/alerts/using-quota-metrics). A simple alert on quota thresholds is also part of the blueprint.
## Delegated Role Grants - This [example](./iam-delegated-role-grants) shows how to use delegated role grants to restrict service usage. + This [blueprint](./iam-delegated-role-grants) shows how to use delegated role grants to restrict service usage.
## Packer image builder - This [example](./packer-image-builder) shows how to deploy infrastructure for a Compute Engine image builder based on [Hashicorp's Packer tool](https://www.packer.io). + This [blueprint](./packer-image-builder) shows how to deploy infrastructure for a Compute Engine image builder based on [Hashicorp's Packer tool](https://www.packer.io).
## On-prem Service Account key management -This [example](./onprem-sa-key-management) shows how to manage IAM Service Account Keys by manually generating a key pair and uploading the public part of the key to GCP. +This [blueprint](./onprem-sa-key-management) shows how to manage IAM Service Account Keys by manually generating a key pair and uploading the public part of the key to GCP.
## Migrate for Compute Engine (v5) - This set of [examples](./vm-migration) shows how to deploy Migrate for Compute Engine (v5) on top of existing Cloud Foundations on different scenarios. An example on how to deploy the M4CE connector on VMWare ESXi is also part of the examples. + This set of [blueprints](./vm-migration) shows how to deploy Migrate for Compute Engine (v5) on top of existing Cloud Foundations on different scenarios. An blueprint on how to deploy the M4CE connector on VMWare ESXi is also part of the blueprints.
## TCP healthcheck for unmanaged GCE instances - This [example](./unmanaged-instances-healthcheck) shows how to leverage [Serverless VPC Access](https://cloud.google.com/vpc/docs/configure-serverless-vpc-access) and Cloud Functions to organize a highly performant TCP healtheck for unmanaged GCE instances. + This [blueprint](./unmanaged-instances-healthcheck) shows how to leverage [Serverless VPC Access](https://cloud.google.com/vpc/docs/configure-serverless-vpc-access) and Cloud Functions to organize a highly performant TCP healtheck for unmanaged GCE instances.
diff --git a/blueprints/cloud-operations/adfs/README.md b/blueprints/cloud-operations/adfs/README.md index f9940e390..a08b776b2 100644 --- a/blueprints/cloud-operations/adfs/README.md +++ b/blueprints/cloud-operations/adfs/README.md @@ -24,7 +24,7 @@ The diagram below depicts the architecture of the example: ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fadfs), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fadfs), then go through the following steps to create resources: * `terraform init` * `terraform apply -var project_id=my-project-id -var ad_dns_domain_name=my-domain.org -var adfs_dns_domain_name=adfs.my-domain.org` diff --git a/blueprints/cloud-operations/asset-inventory-feed-remediation/README.md b/blueprints/cloud-operations/asset-inventory-feed-remediation/README.md index f67aa67ea..057b7d626 100644 --- a/blueprints/cloud-operations/asset-inventory-feed-remediation/README.md +++ b/blueprints/cloud-operations/asset-inventory-feed-remediation/README.md @@ -29,7 +29,7 @@ The resources created in this example are shown in the high level diagram below: ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fasset-inventory-feed-remediation), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fasset-inventory-feed-remediation), then go through the following steps to create resources: - `terraform init` - `terraform apply -var project_id=my-project-id` diff --git a/blueprints/cloud-operations/binauthz/README.md b/blueprints/cloud-operations/binauthz/README.md index 18d7ab51b..de9b315d3 100644 --- a/blueprints/cloud-operations/binauthz/README.md +++ b/blueprints/cloud-operations/binauthz/README.md @@ -17,7 +17,7 @@ The CD pipeline deploys the application to the cluster. ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fbinauthz), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fbinauthz), then go through the following steps to create resources: * `terraform init` * `terraform apply -var project_id=my-project-id` diff --git a/blueprints/cloud-operations/dns-fine-grained-iam/README.md b/blueprints/cloud-operations/dns-fine-grained-iam/README.md index 5b7c949b3..adfc769fa 100644 --- a/blueprints/cloud-operations/dns-fine-grained-iam/README.md +++ b/blueprints/cloud-operations/dns-fine-grained-iam/README.md @@ -1,28 +1,28 @@ # Fine-grained Cloud DNS IAM via Service Directory -This example shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS by +This blueprint shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS by - creating a Service Directory namespace with two services and their endpoints - creating a Cloud DNS private zone that uses the namespace as its authoritative source - creating two service accounts and assigning them the `roles/servicedirectory.editor` role on the namespace and on one service respectively - creating two VMs and setting them to use the two service accounts, so that DNS queries and `gcloud` commands can be used to verify the setup -The resources created in this example are shown in the high level diagram below: +The resources created in this blueprint are shown in the high level diagram below: -A [companion Medium article](https://medium.com/google-cloud/fine-grained-cloud-dns-iam-via-service-directory-446058b4362e) has been published for this example, you can refer to it for more details on the context, and the specifics of running the example. +A [companion Medium article](https://medium.com/google-cloud/fine-grained-cloud-dns-iam-via-service-directory-446058b4362e) has been published for this blueprint, you can refer to it for more details on the context, and the specifics of running the blueprint. -## Running the example +## Running the blueprint -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fdns-fine-grained-iam&cloudshell_open_in_editor=cloudshell_open%2Fcloud-foundation-fabric%2Fexamples%2Fcloud-operations%2Fdns-fine-grained-iam%2Fvariables.tf), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fdns-fine-grained-iam&cloudshell_open_in_editor=cloudshell_open%2Fcloud-foundation-fabric%2Fblueprints%2Fcloud-operations%2Fdns-fine-grained-iam%2Fvariables.tf), then go through the following steps to create resources: - `terraform init` - `terraform apply -var project_id=my-project-id` Once done testing, you can clean up resources by running `terraform destroy`. To persist state, check out the `backend.tf.sample` file. -## Testing the example +## Testing the blueprint The terraform outputs generate preset `gcloud compute ssh` commands that you can copy and run in the console to connect to each VM. Remember to adapt the testing commands below if you changed the default values for the `name`, `region`, or `zone_domain` variables. diff --git a/blueprints/cloud-operations/iam-delegated-role-grants/README.md b/blueprints/cloud-operations/iam-delegated-role-grants/README.md index 6b363fdbb..bc3c8c464 100644 --- a/blueprints/cloud-operations/iam-delegated-role-grants/README.md +++ b/blueprints/cloud-operations/iam-delegated-role-grants/README.md @@ -42,7 +42,7 @@ This diagram shows the resources and expected behaviour: ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fiam-delegated-role-grants), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fiam-delegated-role-grants), then go through the following steps to create resources: - `terraform init` - `terraform apply -var project_id=my-project-id 'project_administrators=["user:project-admin@example.com"]'` diff --git a/blueprints/cloud-operations/multi-cluster-mesh-gke-fleet-api/README.md b/blueprints/cloud-operations/multi-cluster-mesh-gke-fleet-api/README.md index 73402b6cf..fa0d59adf 100644 --- a/blueprints/cloud-operations/multi-cluster-mesh-gke-fleet-api/README.md +++ b/blueprints/cloud-operations/multi-cluster-mesh-gke-fleet-api/README.md @@ -24,7 +24,7 @@ Ansible is used to execute commands in the management VM. From this VM there is ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fmulti-cluster-mesh-gke-fleet-api), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fmulti-cluster-mesh-gke-fleet-api), then go through the following steps to create resources: * `terraform init` * `terraform apply -var billing_account_id=my-billing-account-id -var parent=folders/my-folder-id -var host_project_id=my-host-project-id -var fleet_project_id=my-fleet-project-id -var mgmt_project_id=my-mgmt-project-id` diff --git a/blueprints/cloud-operations/quota-monitoring/README.md b/blueprints/cloud-operations/quota-monitoring/README.md index 7b4e442f9..57c7fd909 100644 --- a/blueprints/cloud-operations/quota-monitoring/README.md +++ b/blueprints/cloud-operations/quota-monitoring/README.md @@ -18,7 +18,7 @@ The solution also creates a basic monitoring alert policy, to demonstrate how to ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fquota-monitoring), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fquota-monitoring), then go through the following steps to create resources: - `terraform init` - `terraform apply -var project_id=my-project-id` diff --git a/blueprints/cloud-operations/unmanaged-instances-healthcheck/README.md b/blueprints/cloud-operations/unmanaged-instances-healthcheck/README.md index 9fa8a98e3..fc5b820b7 100644 --- a/blueprints/cloud-operations/unmanaged-instances-healthcheck/README.md +++ b/blueprints/cloud-operations/unmanaged-instances-healthcheck/README.md @@ -33,7 +33,7 @@ Healthchecker cloud function has the following configuration options: ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Funmanaged-instances-healthcheck), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Funmanaged-instances-healthcheck), then go through the following steps to create resources: - `terraform init` - `terraform apply -var project_id=my-project-id` diff --git a/blueprints/cloud-operations/vm-migration/README.md b/blueprints/cloud-operations/vm-migration/README.md index 96d6ac7a6..909a02bdd 100644 --- a/blueprints/cloud-operations/vm-migration/README.md +++ b/blueprints/cloud-operations/vm-migration/README.md @@ -1,10 +1,10 @@ -# Migrate for Compute Engine (v5) examples +# Migrate for Compute Engine (v5) blueprints -The examples in this folder implement **Migrate for Compute Engine (v5)** environments for the main migration scenarios like the ones with host and target project, or with shared VPC. +The blueprints in this folder implement **Migrate for Compute Engine (v5)** environments for the main migration scenarios like the ones with host and target project, or with shared VPC. They are meant to be used as minimal but complete starting points to create migration environment **on top of existing cloud foundations**, and as playgrounds to experiment with specific Google Cloud features. -## Examples +## Blueprints ### M4CE on a single project @@ -31,4 +31,4 @@ The example shows how to implement a Migrate for Compute Engine (v5) environment This [example](./esxi/) implements a Migrate for Compute Engine (v5) environment on a VMWare ESXi cluster as source for VM migrations. -The example shows how to deploy the Migrate for Compute Engine (v5) connector and implement all the security prerequisites for the migration to GCP. \ No newline at end of file +The example shows how to deploy the Migrate for Compute Engine (v5) connector and implement all the security prerequisites for the migration to GCP. diff --git a/blueprints/cloud-operations/workload-identity-federation/README.md b/blueprints/cloud-operations/workload-identity-federation/README.md index 5ac94e8d3..9d8f092d5 100644 --- a/blueprints/cloud-operations/workload-identity-federation/README.md +++ b/blueprints/cloud-operations/workload-identity-federation/README.md @@ -33,7 +33,7 @@ The provided terraform configuration will set up the following architecture: ## Running the example -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fworkload-identity-federation), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fworkload-identity-federation), then go through the following steps to create resources: * `terraform init` * `terraform apply -var project_id=my-project-id` diff --git a/blueprints/data-solutions/README.md b/blueprints/data-solutions/README.md index 6217f2cbe..cd4c0d852 100644 --- a/blueprints/data-solutions/README.md +++ b/blueprints/data-solutions/README.md @@ -1,10 +1,10 @@ -# GCP Data Services examples +# GCP Data Services blueprints -The examples in this folder implement **typical data service topologies** and **end-to-end scenarios**, that allow testing specific features like Cloud KMS to encrypt your data, or VPC-SC to mitigate data exfiltration. +The blueprints in this folder implement **typical data service topologies** and **end-to-end scenarios**, that allow testing specific features like Cloud KMS to encrypt your data, or VPC-SC to mitigate data exfiltration. They are meant to be used as minimal but complete starting points to create actual infrastructure, and as playgrounds to experiment with specific Google Cloud features. -## Examples +## Blueprints ### GCE and GCS CMEK via centralized Cloud KMS @@ -38,4 +38,4 @@ This [example](./cloudsql-multiregion/) creates a [Cloud SQL instance](https://c This [example](./data-playground/) creates a [Vertex AI Notebook](https://cloud.google.com/vertex-ai/docs/workbench/introduction) running on a VPC with a private IP and a dedicated Service Account. A GCS bucket and a BigQuery dataset are created to store inputs and outputs of data experiments. -
\ No newline at end of file +
diff --git a/blueprints/foundations/README.md b/blueprints/foundations/README.md index b5b25954d..b31645783 100644 --- a/blueprints/foundations/README.md +++ b/blueprints/foundations/README.md @@ -1,32 +1,32 @@ -# Cloud foundation examples +# Cloud foundation blueprints -The examples in this folder deal with cloud foundations: the set of resources used to **create the organizational hierarchy** (folders and specific IAM roles), **implement top-level initial best practices** (audit log exports, policies) and **bootstrap infrastructure automation** (GCS buckets, service accounts and IAM roles). +The blueprints in this folder deal with cloud foundations: the set of resources used to **create the organizational hierarchy** (folders and specific IAM roles), **implement top-level initial best practices** (audit log exports, policies) and **bootstrap infrastructure automation** (GCS buckets, service accounts and IAM roles). -The examples are derived from actual production use cases, and are meant to be used as-is, or extended to create more complex hierarchies. The guiding principles they implement are: +The blueprints are derived from actual production use cases, and are meant to be used as-is, or extended to create more complex hierarchies. The guiding principles they implement are: - divide the hierarchy in separate partitions along environment/organization boundaries, to enforce separation of duties and decouple organization admin permissions from the day-to-day running of infrastructure - keep top-level Terraform code minimal and encapsulate complexity in modules, to ensure readability and allow using code as high level documentation -## Examples +## Blueprints ### Environment Hierarchy - This [example](./environments/) implements a simple one-level organizational layout, which is commonly used to bootstrap small infrastructures, or in situations where lower level folders are managed with separate, more granular Terraform setups. + This [blueprint](./environments/) implements a simple one-level organizational layout, which is commonly used to bootstrap small infrastructures, or in situations where lower level folders are managed with separate, more granular Terraform setups. -One authoritative service account, one bucket and one folder are created for each environment, together with top-level shared resources. This example's simplicity makes it a good starting point to understand and prototype foundational design. +One authoritative service account, one bucket and one folder are created for each environment, together with top-level shared resources. This blueprint's simplicity makes it a good starting point to understand and prototype foundational design.
### Business Unit / Environment Hierarchy - This [example](./business-units/) implements a two-level organizational layout, with a first level usually mapped to business units, and a second level implementing identical environments (prod, test, etc.) under each first-level folder. + This [blueprint](./business-units/) implements a two-level organizational layout, with a first level usually mapped to business units, and a second level implementing identical environments (prod, test, etc.) under each first-level folder. This approach maps well to medium sized infrastructures, and can be used as a starting point for more complex scenarios. Separate Terraform stages are then usually implemented for each business unit, implementing fine-grained project and service account creation for individual application teams.
## Operational considerations -These examples are always used manually, as they require very high-level permissions and are updated infrequently. +These blueprints are always used manually, as they require very high-level permissions and are updated infrequently. The IAM roles needed are: @@ -34,7 +34,7 @@ The IAM roles needed are: - Billing Account Administrator on the billing account or org - Organization Administrator if Shared VPC roles have to be granted to the automation service accounts created for each scope -State is local on the first run, then it should be moved to the GCS bucket created by the examples for this specific purpose: +State is local on the first run, then it should be moved to the GCS bucket created by the blueprints for this specific purpose: ```bash # first apply diff --git a/blueprints/gke-serverless/README.md b/blueprints/gke-serverless/README.md index b9e71e42a..040f69734 100644 --- a/blueprints/gke-serverless/README.md +++ b/blueprints/gke-serverless/README.md @@ -1,10 +1,10 @@ -# GKE and Serverless examples +# GKE and Serverless blueprints -The examples in this folder show implement **end-to-end scenarios** for GKE or Serveless topologies that show how to automate common configurations or leverage specific products. +The blueprints in this folder show implement **end-to-end scenarios** for GKE or Serveless topologies that show how to automate common configurations or leverage specific products. They are meant to be used as minimal but complete starting points to create actual infrastructure, and as playgrounds to experiment with Google Cloud features. -## Examples +## Blueprints ### Multitenant GKE fleet diff --git a/blueprints/networking/README.md b/blueprints/networking/README.md index 9a3bd8687..b35ec0574 100644 --- a/blueprints/networking/README.md +++ b/blueprints/networking/README.md @@ -1,50 +1,50 @@ -# Networking and infrastructure examples +# Networking and infrastructure blueprints -The examples in this folder implement **typical network topologies** like hub and spoke, or **end-to-end scenarios** that allow testing specific features like on-premises DNS policies and Private Google Access. +The blueprints in this folder implement **typical network topologies** like hub and spoke, or **end-to-end scenarios** that allow testing specific features like on-premises DNS policies and Private Google Access. They are meant to be used as minimal but complete starting points to create actual infrastructure, and as playgrounds to experiment with specific Google Cloud features. -## Examples +## Blueprints ### Hub and Spoke via Peering - This [example](./hub-and-spoke-peering/) implements a hub and spoke topology via VPC peering, a common design where a landing zone VPC (hub) is connected to on-premises, and then peered with satellite VPCs (spokes) to further partition the infrastructure. + This [blueprint](./hub-and-spoke-peering/) implements a hub and spoke topology via VPC peering, a common design where a landing zone VPC (hub) is connected to on-premises, and then peered with satellite VPCs (spokes) to further partition the infrastructure. The sample highlights the lack of transitivity in peering: the absence of connectivity between spokes, and the need create workarounds for private service access to managed services. One such workaround is shown for private GKE, allowing access from hub and all spokes to GKE masters via a dedicated VPN.
### Hub and Spoke via Dynamic VPN - This [example](./hub-and-spoke-vpn/) implements a hub and spoke topology via dynamic VPN tunnels, a common design where peering cannot be used due to limitations on the number of spokes or connectivity to managed services. + This [blueprint](./hub-and-spoke-vpn/) implements a hub and spoke topology via dynamic VPN tunnels, a common design where peering cannot be used due to limitations on the number of spokes or connectivity to managed services. -The example shows how to implement spoke transitivity via BGP advertisements, how to expose hub DNS zones to spokes via DNS peering, and allows easy testing of different VPN and BGP configurations. +The blueprint shows how to implement spoke transitivity via BGP advertisements, how to expose hub DNS zones to spokes via DNS peering, and allows easy testing of different VPN and BGP configurations.
### DNS and Private Access for On-premises - This [example](./onprem-google-access-dns/) uses an emulated on-premises environment running in Docker containers inside a GCE instance, to allow testing specific features like DNS policies, DNS forwarding zones across VPN, and Private Access for On-premises hosts. + This [blueprint](./onprem-google-access-dns/) uses an emulated on-premises environment running in Docker containers inside a GCE instance, to allow testing specific features like DNS policies, DNS forwarding zones across VPN, and Private Access for On-premises hosts. The emulated on-premises environment can be used to test access to different services from outside Google Cloud, by implementing a VPN connection and BGP to Google CLoud via Strongswan and Bird.
### Shared VPC with GKE and per-subnet support - This [example](./shared-vpc-gke/) shows how to configure a Shared VPC, including the specific IAM configurations needed for GKE, and to give different level of access to the VPC subnets to different identities. + This [blueprint](./shared-vpc-gke/) shows how to configure a Shared VPC, including the specific IAM configurations needed for GKE, and to give different level of access to the VPC subnets to different identities. -It is meant to be used as a starting point for most Shared VPC configurations, and to be integrated to the above examples where Shared VPC is needed in more complex network topologies. +It is meant to be used as a starting point for most Shared VPC configurations, and to be integrated to the above blueprints where Shared VPC is needed in more complex network topologies.
### ILB as next hop - This [example](./ilb-next-hop/) allows testing [ILB as next hop](https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview) using simple Linux gateway VMS between two VPCs, to emulate virtual appliances. An optional additional ILB can be enabled to test multiple load balancer configurations and hashing. + This [blueprint](./ilb-next-hop/) allows testing [ILB as next hop](https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview) using simple Linux gateway VMS between two VPCs, to emulate virtual appliances. An optional additional ILB can be enabled to test multiple load balancer configurations and hashing.
### Calling a private Cloud Function from On-premises - This [example](./private-cloud-function-from-onprem/) shows how to invoke a [private Google Cloud Function](https://cloud.google.com/functions/docs/networking/network-settings) from the on-prem environment via a [Private Service Connect endpoint](https://cloud.google.com/vpc/docs/private-service-connect#benefits-apis). + This [blueprint](./private-cloud-function-from-onprem/) shows how to invoke a [private Google Cloud Function](https://cloud.google.com/functions/docs/networking/network-settings) from the on-prem environment via a [Private Service Connect endpoint](https://cloud.google.com/vpc/docs/private-service-connect#benefits-apis).
### Decentralized firewall management - This [example](./decentralized-firewall/) shows how a decentralized firewall management can be organized using the [firewall factory](../factories/net-vpc-firewall-yaml/). + This [blueprint](./decentralized-firewall/) shows how a decentralized firewall management can be organized using the [firewall factory](../factories/net-vpc-firewall-yaml/).
diff --git a/blueprints/networking/ilb-next-hop/README.md b/blueprints/networking/ilb-next-hop/README.md index d25a74b20..e55691ebc 100644 --- a/blueprints/networking/ilb-next-hop/README.md +++ b/blueprints/networking/ilb-next-hop/README.md @@ -1,8 +1,8 @@ # Internal Load Balancer as Next Hop -This example bootstraps a minimal infrastructure for testing [ILB as next hop](https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview), using simple Linux gateway VMS between two VPCs to emulate virtual appliances. +This blueprint bootstraps a minimal infrastructure for testing [ILB as next hop](https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview), using simple Linux gateway VMS between two VPCs to emulate virtual appliances. -The following diagram shows the resources created by this example +The following diagram shows the resources created by this blueprint ![High-level diagram](diagram.png "High-level diagram") diff --git a/blueprints/networking/onprem-google-access-dns/README.md b/blueprints/networking/onprem-google-access-dns/README.md index cdf1f059b..fae563986 100644 --- a/blueprints/networking/onprem-google-access-dns/README.md +++ b/blueprints/networking/onprem-google-access-dns/README.md @@ -1,12 +1,12 @@ # On-prem DNS and Google Private Access -This example leverages the [on prem in a box](../../../modules/cloud-config-container/onprem) module to bootstrap an emulated on-premises environment on GCP, then connects it via VPN and sets up BGP and DNS so that several specific features can be tested: +This blueprint leverages the [on prem in a box](../../../modules/cloud-config-container/onprem) module to bootstrap an emulated on-premises environment on GCP, then connects it via VPN and sets up BGP and DNS so that several specific features can be tested: - [Cloud DNS forwarding zone](https://cloud.google.com/dns/docs/overview#fz-targets) to on-prem - DNS forwarding from on-prem via a [Cloud DNS inbound policy](https://cloud.google.com/dns/docs/policies#create-in) - [Private Access for on-premises hosts](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid) -The example has been purposefully kept simple to show how to use and wire the on-prem module, but it lends itself well to experimenting and can be combined with the other [infrastructure examples](../) in this repository to test different GCP networking patterns in connection to on-prem. This is the high level diagram: +The blueprint has been purposefully kept simple to show how to use and wire the on-prem module, but it lends itself well to experimenting and can be combined with the other [infrastructure blueprints](../) in this repository to test different GCP networking patterns in connection to on-prem. This is the high level diagram: ![High-level diagram](diagram.png "High-level diagram") @@ -197,7 +197,7 @@ curl www.onprem.example.org -s |grep h1 ## Operational considerations -A single pre-existing project is used in this example to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project. +A single pre-existing project is used in this blueprint to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project. The VPN-s used to connect to the on-premises environment do not account for HA, upgrading to use HA VPN is reasonably simple by using the relevant [module](../../../modules/net-vpn-ha). diff --git a/blueprints/serverless/api-gateway/README.md b/blueprints/serverless/api-gateway/README.md index 3b5cad381..fa350efb3 100644 --- a/blueprints/serverless/api-gateway/README.md +++ b/blueprints/serverless/api-gateway/README.md @@ -2,18 +2,18 @@ This tutorial shows you how to configure an HTTP(S) load balancer to enable multi-region deployments for API Gateway. For more details on how this set up work have a look at the article [here](https://cloud.google.com/api-gateway/docs/multi-region-deployment). -The diagram below depicts the architecture that this example sets up. +The diagram below depicts the architecture that this blueprint sets up. ![Architecture](architecture.png) -# Running the example +# Running the blueprint -Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fserverless%2Fapi-gateway), then go through the following steps to create resources: +Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fserverless%2Fapi-gateway), then go through the following steps to create resources: * `terraform init` * `terraform apply -var project_id=my-project-id` -## Testing the example +## Testing the blueprint 1. Copy the IP address returned as output diff --git a/blueprints/third-party-solutions/README.md b/blueprints/third-party-solutions/README.md index b3e2d5f61..10b7ced20 100644 --- a/blueprints/third-party-solutions/README.md +++ b/blueprints/third-party-solutions/README.md @@ -1,8 +1,8 @@ # Third Party Solutions -The examples in this folder show how to automate installation of specific third party products on GCP, following typical best practices. +The blueprints in this folder show how to automate installation of specific third party products on GCP, following typical best practices. -## Examples +## Blueprints ### OpenShift cluster bootstrap on Shared VPC