# Project root moduleterraform{backend"gcs"{bucket="BUCKET"}}module"project"{source="terraform-google-modules/project-factory/google"...}output"project_id"{value=module.project.project_iddescription="The ID of the created project"}
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eRoot modules, the directories from which Terraform CLI commands are run, should adhere to specific standards, often superseding general Terraform guidelines.\u003c/p\u003e\n"],["\u003cp\u003eEach root module should contain a limited number of resources, ideally no more than a few dozen and certainly not exceeding 100, to avoid slow execution during Terraform runs.\u003c/p\u003e\n"],["\u003cp\u003eOrganize Terraform configurations by placing resources for each application or project in their own separate directories, and further divide these into \u003ccode\u003emodules\u003c/code\u003e and \u003ccode\u003eenvironments\u003c/code\u003e subdirectories for managing different service configurations and environments (dev, qa, prod).\u003c/p\u003e\n"],["\u003cp\u003eEach environment directory should include a \u003ccode\u003ebackend.tf\u003c/code\u003e file specifying the Terraform state location and a \u003ccode\u003emain.tf\u003c/code\u003e file instantiating the service module, while refraining from using multiple CLI workspaces within an environment.\u003c/p\u003e\n"],["\u003cp\u003eRoot modules should export useful outputs via remote state, pin provider versions to minor releases using a \u003ccode\u003eversions.tf\u003c/code\u003e file, and store variable values in a \u003ccode\u003eterraform.tfvars\u003c/code\u003e file while checking the \u003ccode\u003e.terraform.lock.hcl\u003c/code\u003e file into source control.\u003c/p\u003e\n"]]],[],null,["# Best practices for root modules\n\nThis document provides guidelines and recommendations to consider\nwhen using root modules.\n\nRoot configurations or root modules are the working directories from which you\nrun the Terraform CLI. Make sure that root configurations adhere to the\nfollowing standards (and to the previous Terraform guidelines where applicable).\nExplicit recommendations for root modules supersede the general guidelines.\n\nThis guide is not an introduction to Terraform. For an introduction to using\nTerraform with Google Cloud, see [Get started with\nTerraform](/docs/terraform/get-started-with-terraform).\n\nMinimize the number of resources in each root module\n----------------------------------------------------\n\nIt is important to keep a single root configuration from growing too large, with\ntoo many resources stored in the same directory and state. *All* resources in a\nparticular root configuration are refreshed every time Terraform is run. This\ncan cause slow execution if too many resources are included in a single state. A\ngeneral rule: Don't include more than 100 resources (and ideally only a few\ndozen) in a single state.\n\nUse separate directories for each application\n---------------------------------------------\n\nTo manage applications and projects independently of each other, put resources\nfor each application and project in their own Terraform directories. A service\nmight represent a particular application or a common service such as shared\nnetworking. Nest all Terraform code for a particular service under *one*\ndirectory (including subdirectories).\n\nSplit applications into environment-specific subdirectories\n-----------------------------------------------------------\n\nWhen deploying services in Google Cloud, split the Terraform\nconfiguration for the service into two top-level directories: a `modules`\ndirectory that contains the actual configuration for the service, and an\n`environments` directory that contains the root configurations for each\nenvironment. \n\n -- SERVICE-DIRECTORY/\n -- OWNERS\n -- modules/\n -- \u003cservice-name\u003e/\n -- main.tf\n -- variables.tf\n -- outputs.tf\n -- provider.tf\n -- README\n -- ...other...\n -- environments/\n -- dev/\n -- backend.tf\n -- main.tf\n\n -- qa/\n -- backend.tf\n -- main.tf\n\n -- prod/\n -- backend.tf\n -- main.tf\n\nUse environment directories\n---------------------------\n\nTo share code across environments, reference modules. Typically, this might be a\nservice module that includes the base shared Terraform configuration for the\nservice. In service modules, hard-code common inputs and only require\nenvironment-specific inputs as variables.\n\nEach environment directory must contain the following files:\n\n- A `backend.tf` file, declaring the Terraform [backend](https://www.terraform.io/docs/backends/) state location (typically, [Cloud Storage](/storage))\n- A `main.tf` file that instantiates the service module\n\nEach environment directory (`dev`, `qa`, `prod`) corresponds to a default\n[Terraform workspace](https://www.terraform.io/docs/state/workspaces)\nand deploys a version of the service to that environment. These workspaces\nisolate environment-specific resources into their own contexts. *Use only the\ndefault workspace*.\n\nHaving multiple\n[CLI workspaces](https://developer.hashicorp.com/terraform/language/state/workspaces)\nwithin an environment isn't recommended for the following reasons:\n\n- It can be difficult to inspect the configuration in each workspace.\n- Having a single shared backend for multiple workspaces isn't recommended because the shared backend becomes a single point of failure if it is used for environment separation.\n- While code reuse is possible, code becomes harder to read having to switch based on the current workspace variable (for example, `terraform.workspace == \"foo\" ? this : that`).\n\nFor more information, see the following:\n\n- [Workspaces](https://www.terraform.io/language/state/workspaces#when-to-use-multiple-workspaces)\n- [When Not to Use Multiple Workspaces](https://developer.hashicorp.com/terraform/cli/workspaces#when-not-to-use-multiple-workspaces)\n\nExpose outputs through remote state\n-----------------------------------\n\nMake sure you're exposing useful outputs of module instances from a root module.\n\nFor example, the following code snippet passes through the project ID output\nfrom the project factory module instance as an output of the root module. \n\n # Project root module\n terraform {\n backend \"gcs\" {\n bucket = \"BUCKET\"\n }\n }\n\n module \"project\" {\n source = \"terraform-google-modules/project-factory/google\"\n ...\n }\n\n output \"project_id\" {\n value = module.project.project_id\n description = \"The ID of the created project\"\n }\n\nOther Terraform environments and applications can reference root module-level\noutputs only.\n\nBy using\n[remote state](https://www.terraform.io/language/state/remote-state-data),\nyou can reference root module outputs. To allow use by other dependent apps for\nconfiguration, make sure you're exporting information that's related to a\nservice's endpoints, to remote state. \n\n # Networks root module\n data \"terraform_remote_state\" \"network_project\" {\n backend = \"gcs\"\n\n config = {\n bucket = \"BUCKET\"\n }\n }\n\n module \"vpc\" {\n source = \"terraform-google-modules/network/google\"\n version = \"~\u003e 9.0\"\n\n project_id = data.terraform_remote_state.network_project.outputs.project_id\n network_name = \"vpc-1\"\n ...\n }\n\nSometimes, such as when invoking a shared service module from environment\ndirectories, it is appropriate to re-export the entire child module, as follows: \n\n output \"service\" {\n value = module.service\n description = \"The service module outputs\"\n }\n\nPin to minor provider versions\n------------------------------\n\nIn root modules, declare each provider and pin to a *minor* version. This\nallows automatic upgrade to new patch releases while still keeping a solid\ntarget. For consistency, name the versions file `versions.tf`. \n\n terraform {\n required_providers {\n google = {\n source = \"hashicorp/google\"\n version = \"~\u003e 4.0.0\"\n }\n }\n }\n\nStore variables in a `tfvars` file\n----------------------------------\n\nFor root modules, provide variables by using a `.tfvars` variables file. For\nconsistency, name variable files `terraform.tfvars`.\n\nDon't specify variables by using alternative\n[`var-files`](https://www.terraform.io/language/values/variables#variable-definitions-tfvars-files)\nor `var='key=val'` command-line options. Command-line options are ephemeral and\neasy to forget. Using a default variables file is more predictable.\n\nCheck in `.terraform.lock.hcl` file\n-----------------------------------\n\nFor root modules, the `.terraform.lock.hcl` [dependency lock](https://www.terraform.io/language/files/dependency-lock)\nfile should be checked into source control. This allows for tracking and\nreviewing changes in provider selections for a given configuration.\n\nWhat's next\n-----------\n\n- Learn about [general style and structure best practices for Terraform on Google Cloud](/docs/terraform/best-practices/general-style-structure).\n- Learn about [best practices when using reusable modules](/docs/terraform/best-practices/reusable-modules)."]]