💵 Monthly estimates based on Infracost baseline costs.
Terraform example module for a Google Cloud Platform Subnet.
Note
We do not recommend consuming this module like you might a public module. It is a baseline, something you can fork, potentially maintain, and modify to fit your organization's needs. Using public modules vs. writing your own has various drivers and trade-offs that your organization should evaluate.
Tip
You can check the tests/fixtures directory for example configurations. These fixtures set up the system for testing by providing all the necessary initial code, thus creating good examples on which to base your configurations.
Our focus is on the core fundamental practice of platform engineering, Infrastructure as Code.
Open Source Infrastructure (as Code) is a development model for infrastructure that focuses on open collaboration and applying relative lessons learned from software development practices that organizations can use internally at scale. - Open Source Infrastructure (as Code)
To avoid slowing down stream-aligned teams, we want to open up the possibility for contributions. The Open Source Infrastructure (as Code) model allows team members external to the platform team to contribute with only a slight increase in cognitive load. This section is for developers who want to contribute to this repository, describing the tools used, the skills, and the knowledge required, along with Terraform documentation.
See the documentation for setting up a local development environment here.
Links to documentation and other resources required to develop and iterate in this repository successfully.
You'll need to be a member of the platform-contributors Google Group to run the tests. This group manages access to the resource hierarchy's Testing/Sandbox folder. You can request access to this group by opening an issue here.
cd fixtures/default
terraform init
terraform test
cd fixtures/internal_load_balancer
terraform init
terraform test
A child module automatically inherits default (un-aliased) provider configurations from its parent. The provider versions below are informational only and do not need to align with the provider configurations from its parent.
No requirements.
No providers.
No modules.
No resources.
No inputs.
No outputs.