github.com/wikibal01/hashicorp-terraform@v0.11.12-beta1/website/docs/internals/graph.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Resource Graph" 4 sidebar_current: "docs-internals-graph" 5 description: |- 6 Terraform builds a dependency graph from the Terraform configurations, and walks this graph to generate plans, refresh state, and more. This page documents the details of what are contained in this graph, what types of nodes there are, and how the edges of the graph are determined. 7 --- 8 9 # Resource Graph 10 11 Terraform builds a 12 [dependency graph](https://en.wikipedia.org/wiki/Dependency_graph) 13 from the Terraform configurations, and walks this graph to 14 generate plans, refresh state, and more. This page documents 15 the details of what are contained in this graph, what types 16 of nodes there are, and how the edges of the graph are determined. 17 18 ~> **Advanced Topic!** This page covers technical details 19 of Terraform. You don't need to understand these details to 20 effectively use Terraform. The details are documented here for 21 those who wish to learn about them without having to go 22 spelunking through the source code. 23 24 For some background on graph theory, and a summary of how 25 Terraform applies it, see the HashiCorp 2016 presentation 26 [_Applying Graph Theory to Infrastructure as Code_](https://www.youtube.com/watch?v=Ce3RNfRbdZ0). 27 This presentation also covers some similar ideas to the following 28 guide. 29 30 ## Graph Nodes 31 32 There are only a handful of node types that can exist within the 33 graph. We'll cover these first before explaining how they're 34 determined and built: 35 36 * **Resource Node** - Represents a single resource. If you have 37 the `count` metaparameter set, then there will be one resource 38 node for each count. The configuration, diff, state, etc. of 39 the resource under change is attached to this node. 40 41 * **Provider Configuration Node** - Represents the time to fully 42 configure a provider. This is when the provider configuration 43 block is given to a provider, such as AWS security credentials. 44 45 * **Resource Meta-Node** - Represents a group of resources, but 46 does not represent any action on its own. This is done for 47 convenience on dependencies and making a prettier graph. This 48 node is only present for resources that have a `count` 49 parameter greater than 1. 50 51 When visualizing a configuration with `terraform graph`, you can 52 see all of these nodes present. 53 54 ## Building the Graph 55 56 Building the graph is done in a series of sequential steps: 57 58 1. Resources nodes are added based on the configuration. If a 59 diff (plan) or state is present, that meta-data is attached 60 to each resource node. 61 62 1. Resources are mapped to provisioners if they have any 63 defined. This must be done after all resource nodes are 64 created so resources with the same provisioner type can 65 share the provisioner implementation. 66 67 1. Explicit dependencies from the `depends_on` meta-parameter 68 are used to create edges between resources. 69 70 1. If a state is present, any "orphan" resources are added to 71 the graph. Orphan resources are any resources that are no 72 longer present in the configuration but are present in the 73 state file. Orphans never have any configuration associated 74 with them, since the state file does not store configuration. 75 76 1. Resources are mapped to providers. Provider configuration 77 nodes are created for these providers, and edges are created 78 such that the resources depend on their respective provider 79 being configured. 80 81 1. Interpolations are parsed in resource and provider configurations 82 to determine dependencies. References to resource attributes 83 are turned into dependencies from the resource with the interpolation 84 to the resource being referenced. 85 86 1. Create a root node. The root node points to all resources and 87 is created so there is a single root to the dependency graph. When 88 traversing the graph, the root node is ignored. 89 90 1. If a diff is present, traverse all resource nodes and find resources 91 that are being destroyed. These resource nodes are split into two: 92 one node that destroys the resource and another that creates 93 the resource (if it is being recreated). The reason the nodes must 94 be split is because the destroy order is often different from the 95 create order, and so they can't be represented by a single graph 96 node. 97 98 1. Validate the graph has no cycles and has a single root. 99 100 ## Walking the Graph 101 <a id="walking-the-graph"></a> 102 103 To walk the graph, a standard depth-first traversal is done. Graph 104 walking is done in parallel: a node is walked as soon as all of its 105 dependencies are walked. 106 107 The amount of parallelism is limited using a semaphore to prevent too many 108 concurrent operations from overwhelming the resources of the machine running 109 Terraform. By default, up to 10 nodes in the graph will be processed 110 concurrently. This number can be set using the `-parallelism` flag on the 111 [plan](/docs/commands/plan.html), [apply](/docs/commands/apply.html), and 112 [destroy](/docs/commands/destroy.html) commands. 113 114 Setting `-parallelism` is considered an advanced operation and should not be 115 necessary for normal usage of Terraform. It may be helpful in certain special 116 use cases or to help debug Terraform issues. 117 118 Note that some providers (AWS, for example), handle API rate limiting issues at 119 a lower level by implementing graceful backoff/retry in their respective API 120 clients. For this reason, Terraform does not use this `parallelism` feature to 121 address API rate limits directly.