Skip to content

Latest commit

 

History

History
 
 

4-projects

README.md

4-projects

This repo is part of a multi-part guide that shows how to configure and deploy the example.com reference architecture described in Google Cloud security foundations guide. The following table lists the parts of the guide.

0-bootstrap Bootstraps a Google Cloud organization, creating all the required resources and permissions to start using the Cloud Foundation Toolkit (CFT). This step also configures a CI/CD Pipeline for foundations code in subsequent stages.
1-org Sets up top level shared folders, monitoring and networking projects, and organization-level logging, and sets baseline security settings through organizational policy.
2-environments Sets up development, non-production, and production environments within the Google Cloud organization that you've created.
3-networks-dual-svpc Sets up base and restricted shared VPCs with default DNS, NAT (optional), Private Service networking, VPC service controls, on-premises Dedicated Interconnect, and baseline firewall rules for each environment. It also sets up the global DNS hub.
3-networks-hub-and-spoke Sets up base and restricted shared VPCs with all the default configuration found on step 3-networks-dual-svpc, but here the architecture will be based on the Hub and Spoke network model. It also sets up the global DNS hub
4-projects (this file) Sets up a folder structure, projects, and application infrastructure pipeline for applications, which are connected as service projects to the shared VPC created in the previous stage.
5-app-infra Deploys Service Catalog Pipeline and Custom Artifacts Pipeline.

For an overview of the architecture and the parts, see the terraform-google-enterprise-genai README.

Purpose

The purpose of this step is to set up the folder structure, projects, and infrastructure pipelines for applications that are connected as service projects to the shared VPC created in the previous stage.

For machine learning business unit, a shared infra-pipeline project is created along with Cloud Build triggers, CSRs for application infrastructure code and Google Cloud Storage buckets for state storage.

This step follows the same conventions as the Foundation pipeline deployed in 0-bootstrap. A custom workspace (bu1-example-app) is created by this pipeline and necessary roles are granted to the Terraform Service Account of this workspace by enabling variable sa_roles as shown in this example.

This pipeline is utilized to deploy resources in projects across development/non-production/production in step 5-app-infra. Other Workspaces can also be created to isolate deployments if needed.

Prerequisites

  1. 0-bootstrap executed successfully.

  2. 1-org executed successfully.

  3. 2-environments executed successfully.

  4. 3-networks executed successfully.

  5. For the manual step described in this document, you need Terraform version 1.5.7 or later to be installed.

    Note: Make sure that you use version 1.5.7 or later of Terraform throughout this series. Otherwise, you might experience Terraform state snapshot lock errors.

    Note 2: As mentioned in 0-bootstrap README note 2 at the end of Cloud Build deploy section, make sure that you have requested at least 50 additional projects for the projects step service account, otherwise you may face a project quota exceeded error message during the following steps and you will need to apply the fix from this entry of the Troubleshooting guide in order to continue.

Troubleshooting

Please refer to troubleshooting if you run into issues during this step.

Usage

Note: If you are using MacOS, replace cp -RT with cp -R in the relevant commands. The -T flag is needed for Linux, but causes problems for MacOS.

Deploying with Cloud Build

  1. Clone the gcp-projects repo based on the Terraform output from the 0-bootstrap step. Clone the repo at the same level of the terraform-google-enterprise-genai folder, the following instructions assume this layout. Run terraform output cloudbuild_project_id in the 0-bootstrap folder to get the Cloud Build Project ID.

    export CLOUD_BUILD_PROJECT_ID=$(terraform -chdir="terraform-google-enterprise-genai/0-bootstrap/" output -raw cloudbuild_project_id)
echo ${CLOUD_BUILD_PROJECT_ID}

gcloud source repos clone gcp-projects --project=${CLOUD_BUILD_PROJECT_ID}

  2. Change to the freshly cloned repo, change to the non-main branch and copy contents of foundation to new repo.

    cd gcp-projects
git checkout -b plan

cp -RT ../terraform-google-enterprise-genai/4-projects/ .
cp ../terraform-google-enterprise-genai/build/cloudbuild-tf-* .
cp ../terraform-google-enterprise-genai/build/tf-wrapper.sh .
chmod 755 ./tf-wrapper.sh

  3. Rename auto.example.tfvars files to auto.tfvars.

    mv common.auto.example.tfvars common.auto.tfvars
mv shared.auto.example.tfvars shared.auto.tfvars
mv development.auto.example.tfvars development.auto.tfvars
mv non-production.auto.example.tfvars non-production.auto.tfvars
mv production.auto.example.tfvars production.auto.tfvars

  4. See any of the envs folder README.md files for additional information on the values in the common.auto.tfvars, development.auto.tfvars, non-production.auto.tfvars, and production.auto.tfvars files.

  5. See any of the shared folder README.md files for additional information on the values in the shared.auto.tfvars file.

  6. Use terraform output to get the backend bucket value from 0-bootstrap output.

    export remote_state_bucket=$(terraform -chdir="../terraform-google-enterprise-genai/0-bootstrap/" output -raw gcs_bucket_tfstate)
echo "remote_state_bucket = ${remote_state_bucket}"

export projects_gcs_bucket_tfstate=$(terraform -chdir="../terraform-google-enterprise-genai/0-bootstrap/" output -raw projects_gcs_bucket_tfstate)
echo "projects_gcs_bucket_tfstate = ${projects_gcs_bucket_tfstate}"

sed -i "s/REMOTE_STATE_BUCKET/${remote_state_bucket}/" ./common.auto.tfvars
for i in `find -name 'backend.tf'`; do sed -i "s/UPDATE_PROJECTS_BACKEND/${projects_gcs_bucket_tfstate}/" $i; done

  7. Commit changes.

    git add .
git commit -m 'Initialize projects repo'

  8. You need to manually plan and apply only once the ml_business_unit/shared environments since development, non-production, and production depend on them.

  9. To use the validate option of the tf-wrapper.sh script, please follow the instructions to install the terraform-tools component.

  10. Use terraform output to get the Cloud Build project ID and the projects step Terraform Service Account from 0-bootstrap output. An environment variable GOOGLE_IMPERSONATE_SERVICE_ACCOUNT will be set using the Terraform Service Account to enable impersonation.

    export CLOUD_BUILD_PROJECT_ID=$(terraform -chdir="../terraform-google-enterprise-genai/0-bootstrap/" output -raw cloudbuild_project_id)
echo ${CLOUD_BUILD_PROJECT_ID}

export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT=$(terraform -chdir="../terraform-google-enterprise-genai/0-bootstrap/" output -raw projects_step_terraform_service_account_email)
echo ${GOOGLE_IMPERSONATE_SERVICE_ACCOUNT}

  11. Run init and plan and review output for environment shared.

    ./tf-wrapper.sh init shared
./tf-wrapper.sh plan shared

  12. Run validate and check for violations.

    ./tf-wrapper.sh validate shared $(pwd)/../gcp-policies ${CLOUD_BUILD_PROJECT_ID}

  13. Run apply shared.

    ./tf-wrapper.sh apply shared

  14. Push your plan branch to trigger a plan for all environments. Because the plan branch is not a named environment branch), pushing your plan branch triggers terraform plan but not terraform apply. Review the plan output in your Cloud Build project https://console.cloud.google.com/cloud-build/builds;region=DEFAULT_REGION?project=YOUR_CLOUD_BUILD_PROJECT_ID

    git push --set-upstream origin plan

  15. Merge changes to production. Because this is a named environment branch, pushing to this branch triggers both terraform plan and terraform apply. Review the apply output in your Cloud Build project. https://console.cloud.google.com/cloud-build/builds;region=DEFAULT_REGION?project=YOUR_CLOUD_BUILD_PROJECT_ID

    git checkout -b production
git push origin production

  16. After production has been applied, apply development.

  17. Merge changes to development. Because this is a named environment branch, pushing to this branch triggers both terraform plan and terraform apply. Review the apply output in your Cloud Build project https://console.cloud.google.com/cloud-build/builds;region=DEFAULT_REGION?project=YOUR_CLOUD_BUILD_PROJECT_ID

    git checkout -b development
git push origin development

  18. After development has been applied, apply non-production.

  19. Merge changes to non-production. Because this is a named environment branch, pushing to this branch triggers both terraform plan and terraform apply. Review the apply output in your Cloud Build project. https://console.cloud.google.com/cloud-build/builds;region=DEFAULT_REGION?project=YOUR_CLOUD_BUILD_PROJECT_ID

    git checkout -b non-production
git push origin non-production

  20. Before executing the next step, unset the GOOGLE_IMPERSONATE_SERVICE_ACCOUNT environment variable.

    unset GOOGLE_IMPERSONATE_SERVICE_ACCOUNT

  21. You can now move to the instructions in the 5-app-infra step.

Deploying with Jenkins

See 0-bootstrap README-Jenkins.md.

Deploying with GitHub Actions

See 0-bootstrap README-GitHub.md.

Run Terraform locally

  1. The next instructions assume that you are at the same level of the terraform-google-enterprise-genai folder. Change into 4-projects folder, copy the Terraform wrapper script and ensure it can be executed.

    cd terraform-google-enterprise-genai/4-projects
cp ../build/tf-wrapper.sh .
chmod 755 ./tf-wrapper.sh

  2. Rename auto.example.tfvars files to auto.tfvars.

    mv common.auto.example.tfvars common.auto.tfvars
mv shared.auto.example.tfvars shared.auto.tfvars
mv development.auto.example.tfvars development.auto.tfvars
mv non-production.auto.example.tfvars non-production.auto.tfvars
mv production.auto.example.tfvars production.auto.tfvars

  3. See any of the envs folder README.md files for additional information on the values in the common.auto.tfvars, development.auto.tfvars, non-production.auto.tfvars, and production.auto.tfvars files. See any of the shared folder README.md files for additional information on the values in the shared.auto.tfvars file. Use terraform output to get the remote state bucket (the backend bucket used by previous steps) value from 0-bootstrap output.

    export remote_state_bucket=$(terraform -chdir="../0-bootstrap/" output -raw gcs_bucket_tfstate)
echo "remote_state_bucket = ${remote_state_bucket}"

sed -i "s/REMOTE_STATE_BUCKET/${remote_state_bucket}/" ./common.auto.tfvars

We will now deploy each of our environments(development/production/non-production) using the tf-wrapper.sh script. When using Cloud Build or Jenkins as your CI/CD tool each environment corresponds to a branch is the repository for 4-projects step and only the corresponding environment is applied. Environment shared must be applied first because development, non-production, and production depend on it.

To use the validate option of the tf-wrapper.sh script, please follow the instructions to install the terraform-tools component.

  1. Use terraform output to get the Cloud Build Project ID and the environment step Terraform Service Account from 0-bootstrap output. An environment variable GOOGLE_IMPERSONATE_SERVICE_ACCOUNT will be set using the Terraform Service Account to enable impersonation.

    export CLOUD_BUILD_PROJECT_ID=$(terraform -chdir="../0-bootstrap/" output -raw cloudbuild_project_id)
echo ${CLOUD_BUILD_PROJECT_ID}

export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT=$(terraform -chdir="../0-bootstrap/" output -raw projects_step_terraform_service_account_email)
echo ${GOOGLE_IMPERSONATE_SERVICE_ACCOUNT}

  2. Run init and plan and review output for environment shared.

    ./tf-wrapper.sh init shared
./tf-wrapper.sh plan shared

  3. Run validate and check for violations.

    ./tf-wrapper.sh validate shared $(pwd)/../policy-library ${CLOUD_BUILD_PROJECT_ID}

  4. Run apply shared.

    ./tf-wrapper.sh apply shared

  5. Run init and plan and review output for environment production.

    ./tf-wrapper.sh init production
./tf-wrapper.sh plan production

  6. Run validate and check for violations.

    ./tf-wrapper.sh validate production $(pwd)/../policy-library ${CLOUD_BUILD_PROJECT_ID}

  7. Run apply production.

    ./tf-wrapper.sh apply production

  8. Run init and plan and review output for environment non-production.

    ./tf-wrapper.sh init non-production
./tf-wrapper.sh plan non-production

  9. Run validate and check for violations.

    ./tf-wrapper.sh validate non-production $(pwd)/../policy-library ${CLOUD_BUILD_PROJECT_ID}

  10. Run apply non-production.

    ./tf-wrapper.sh apply non-production

  11. Run init and plan and review output for environment development.

    ./tf-wrapper.sh init development
./tf-wrapper.sh plan development

  12. Run validate and check for violations.

    ./tf-wrapper.sh validate development $(pwd)/../policy-library ${CLOUD_BUILD_PROJECT_ID}

  13. Run apply development.

    ./tf-wrapper.sh apply development

If you received any errors or made any changes to the Terraform config or any .tfvars, you must re-run ./tf-wrapper.sh plan <env> before running ./tf-wrapper.sh apply <env>.

Before executing the next stages, unset the GOOGLE_IMPERSONATE_SERVICE_ACCOUNT environment variable.

unset GOOGLE_IMPERSONATE_SERVICE_ACCOUNT