When multiple infrastructure tools need to exchange metadata, a configuration manager provides a shared abstraction: it stores named fields and values for automation to consume. It can hide differences between tool-state formats, but it must be maintained and remain accessible to infrastructure code. section 4.2.2
Apply the pattern when coordinating infrastructure automation:
- Store values such as network addresses or other resource metadata in a key-value-style interface. section 4.2.2
- Let network automation and other consumers read those values without parsing each provisioning tool’s state format. section 4.2.2
- Maintain access from infrastructure code and weigh the manager against querying a provider API directly. section 4.2.2
- Split a monolithic configuration manager by extracting independent automation first, injecting dependencies, and testing resource state after each change. section 10.2.3
Installing a shared server dependency
For a promotions application, use a configuration manager to push the Cloud SQL Auth proxy installation to every applicable server. This makes the package and process configuration repeatable instead of leaving it in a one-off startup script. section 11.3.1
Figure 4.4 Dependency inversion returns an abstraction of the low-level resource metadata to the resource that depends on it.
See how dependency inversion returns an abstraction of low-level resource metadata to the resource that depends on it. section 4.2.2
