Modules

Basics

The Cloud Foundation modules are standard Terraform modules. They can be re-used by reference in multiple solutions, environments, and in other modules. The Library includes some of the most frequently used OCI resources, and this supported resources will grow over time.

The best way to see an up-to-date list of modules is to go direct to github as modules are released frequently: Cloud Foundation Modules on GitHub.

A technical README is included in the library documentation, and this covers the technical details of how to get started with Terraform, OCI and the module library.

Module Structure

We have introduced a few terms to help explain the constituent partys of the library and how it can be used.

The Solution Orchestrator is the main.tf file, supported by the other various tf files in the same folder. The orchestrator can include cloud foundation resource modules, local modules or straightforward additional Terraform files.

A Resource Module is a “leaf” Terraform module that only references OCi resources and does not reference any other modules. They provide a module wrapper to an OCI resource. Examples are :

A Composite Module is a module that calls other modules. This is typically used to group together a set of resources into a larges re-usable unit. Composite modules will typically define additional conditional parameters - e.g. number of instances to deply.

We will cover these in the next Solutions section.

module structure

Which OCI resources are included in the Library

The module library focuses on providing modules for the most commonly used resources that are used in OCI workload deployments. A typical solution built with the library may look a little like the diagram below.

Solution Example

Solutions can be assembled by referencing the modules in the Solution Orchestrator and providing the required parameters. In many cases the Solution Orchestrator may include only module calls, and no other Terraform blocks.

Here’s and example of a module call that deploys an autonomous database. It provides all the essential parameters for the deployment as declared variables - with no hard-coded values.

module "database-atp" {

  source = "../../../cloud-foundation/modules/cloud-foundation-library/database/atp"

  count = local.create_atp_db ? 1 : 0 

  tenancy_ocid     = var.tenancy_ocid
  compartment_ocid = local.compartment_ocid

  autonomous_database_cpu_core_count = var.autonomous_database_cpu_core_count
  autonomous_database_db_name = var.autonomous_database_db_name
  autonomous_database_admin_password = var.autonomous_database_admin_password
  autonomous_database_data_storage_size_in_tbs = var.autonomous_database_data_storage_size_in_tbs
}

What they don’t cover

The Cloud Foundation modules only cover the core aspects of a solution. They do not cover the creation of resources that would typically be shared across multiple deployment or more broadly across the organization. For example while an application deployment solution would deploy compute, storage, databases, and even subnets, it would not include typically include global security policies, core networking, physical external connectivity etc.

These shared resources are defined in a “landing zone”, and for these, the Cloud Foundation relies on the CIS OCI Benchmark Landing zone. This is a templated fully secure landing zone implementation with supporting modules.

We have to include a copy of the landing zone modules in the Cloud Foundation so that we could easily re-use modules from the landing zone with local relative URLs. This allowed the cloud foundation modules to re-use the landing zone modules without needing a full landing zone deployment. Feel free to download your own copy of the landing zone and re-direct the module calls if you decide to use the CIS OCI Landing Zone.