1.3.1. How to Design a Terraform Module

In the previous chapter, we provided a broad overview of what a reusable Terraform module should contain and the standards it should adhere to. However, that only described what a module should look like. The next question is: How do we decide on the design of a module? How do we determine which resources to declare within it?

1.3.1.1. Three Types of Module Classifications

Here, we can roughly categorize modules into three major types:

We will explore these types further in their respective sections.

1.3.1.2. Interface Specifications

Public cloud platforms provide features that can be integrated with various services. For example, both AWS and Azure support PrivateLink, allowing users to access PaaS services hosted on the public cloud via VPC traffic for additional security. Another example is Managed Identity, which is currently the recommended method on the Azure platform for configuring permissions for deployed applications. You can configure Managed Identities on many different services and then assign relevant permissions to that Identity. This enables authentication and authorization between different services without the need to store any credentials or secrets. Similar cases include Customer Managed Keys, Private Endpoints, etc.

Given these circumstances, it is necessary to design a unified module interface specification for all modules.

  • Enhancing Module Reusability and Consistency

    By using a unified interface specification, module developers can follow consistent structures and naming conventions, ensuring module reusability across different environments and projects. For instance, the interface specification for diagnostic settings defines parameters such as log categories, storage account resource IDs, and Event Hub authorization rule resource IDs, ensuring consistent behavior when the module is applied to different resources.

  • Improving Module Maintainability

    Unified interface specifications make module maintenance more efficient. When Azure service APIs or features change, module callers only need to modify the code related to the interface change, rather than modifying every resource definition within the module individually. This centralized management approach reduces maintenance costs and improves module maintainability.

  • Facilitating Module Automation and Integration

    Unified interface specifications make it easier to integrate modules with automation tools and CI/CD pipelines. For example, interface specifications for role assignments and managed identities define the required parameters and structures. Automation tools can automatically generate corresponding configurations based on these specifications, reducing manual configuration errors and time costs.

  • Elevating Module Compliance and Security

    Unified interface specifications ensure that modules follow Azure best practices and security requirements during implementation. For example, the Private Endpoint interface specification defines relevant parameters and structures to ensure that the module meets network security and access control requirements upon deployment.

In this chapter, we will explain an Interface Specification from AVM to give readers an intuitive understanding of interface specifications.

results matching ""

    No results matching ""