Alloy DB Terraform Module
This blog gives an high level overview of terraform-google-alloy-db module. Apart from this we will show some examples of usage of the module in different configurations.
Introduction
AlloyDB is a completely managed, PostgreSQL-compatible database for demanding OLTP and OLAP Systems. This product delivers enterprise-grade performance and availability, without sacrificing compatibility with open-source PostgreSQL. That means you can get the best of both worlds: the power and reliability of a commercial database, with the flexibility and cost-effectiveness of open source software.
Clusters
An Alloy DB cluster contains all the resources for a PostgreSQL deployment.As the top-level resource in AlloyDB, clusters are the main unit of resource management, enabling administrators to monitor performance and configure policies and features across multiple instances simply.
Primary instances
A primary instance provides the read/write connection point for the databases in a cluster. Every cluster has one primary instance.
Read pool instances
A read pool instance provides a read only connection point for database data in a cluster. You can create multiple read pool instances in a cluster, and you can scale each one’s computing capacity individually.
You are not required to have any read pool instances in a cluster, but they provide better support for data analytics workloads than do primary instances.
Pre Requisites
- Basic Understanding of Terraform
- Access to Google Cloud Platform .
- Enable the APIs , AlloyDB, Compute Engine, Resource Manager, and Service Networking APIs.
Terraform Module Details
Below are the variables necessary to run the terraform alloy-db module.
Refer this tutorial which shows how use a terraform module in your terraform code.
Configuring AlloyDB Primary Instance
Terraform variable schema to configure the AlloyDB Primary Instance is shown below.
object({
instance_id = string, # Name of Alloy DB Instance
instance_type = string, # Instance type PRIMARY || READ_POOL
machine_cpu_count = number, # The number of CPU's in the VM instance.
display_name = string, # Display Name of Alloy DB Instance
database_flags = map(string) # Database flags. Set at instance level. * They are copied from primary instance on read instance creation. * Read instances can set new or override existing flags that are relevant for reads, e.g. for enabling columnar cache on a read instance. Flags set on read instance may or may not be present on primary.
}Example : Below is an example to configure the primary instance variable.
{
instance_id = "primary-instance",
instance_type = "PRIMARY",
machine_cpu_count = 2,
database_flags = {},
display_name = "alloydb-primary-instance"
}Configuring AlloyDB ReadPool Instance
Terraform variable schema to configure the AlloyDB Read-Pool Instances is shown below.
list(object({
instance_id = string, # Name of Alloy DB Instance
display_name = string, # Display Name of Alloy DB Instance
instance_type = string, # Instance type PRIMARY || READ_POOL
node_count = number, # Read capacity, i.e. number of nodes in a read pool instance.
database_flags = map(string), # Database flags. Set at instance level. * They are copied from primary instance on read instance creation. * Read instances can set new or override existing flags that are relevant for reads, e.g. for enabling columnar cache on a read instance. Flags set on read instance may or may not be present on primary.
availability_type = string, # Availability type of an Instance. Defaults to REGIONAL for both primary and read instances. Note that primary and read instances can have different availability types. Possible values are AVAILABILITY_TYPE_UNSPECIFIED, ZONAL, and REGIONAL.
ZONE = string, # The Compute Engine zone that the instance should serve from,
machine_cpu_count = number # The number of CPU's in the VM instance.
})Example : Below is an example to configure the read pool instances variable.
[
{
instance_id = "read-instance-1",
display_name = "read-instance-1",
instance_type = "READ_POOL",
node_count = 1,
database_flags = {},
availability_type = "ZONAL",
ZONE = "us-central1-a",
machine_cpu_count = 1
}
]Configuring Backup
Terraform variable schema for configuring AlloyDB Cluster backup is shown below.
object({
location = optional(string), # Backup Location
backup_window = optional(string), # Backup Windows in Seconds
enabled = optional(bool), # Backup Enabled Flag
weekly_schedule = object({. # Backup Weekly Schedule
days_of_week = optional(list(string)),
start_times = list(string),
}),
quantity_based_retention_count = optional(number), # Number of Backups to retain
time_based_retention_count = optional(string), # Number of Backups to retain by time
labels = optional(map(string)) # Labels for Backup
}Example : Below is an example to configure the backup variable.
{
location = "us-central1"
backup_window = "1800s",
enabled = true,
weekly_schedule = {
days_of_week = ["FRIDAY"],
start_times = ["2:00:00:00", ]
}
quantity_based_retention_count = 1,
time_based_retention_count = null,
labels = {
test = "alloydb-cluster"
},
}Module Usage Examples
AlloyDB with Primary Instance only
Refer the below repo for the example usage of the module to deploy AlloyDB cluster with primary instance only.
Below is the architecture of the alloy db with primary instance only .
AlloyDB with Multiple Read Pool Instances
Refer the below repo for the example usage of the module to deploy AlloyDB cluster with primary instance and multiple read-pool instances.
Below is the architecture of the AlloyDB with primary instance and multiple read-pool instances.
AlloyDB with Backup Enabled
Refer the below repo for the example usage of the module to deploy AlloyDB cluster with primary instance and Backup enabled.
Conclusion
In conclusion users can use terraform-google-alloy-db to deploy an alloy DB Cluster. Examples shown above should help users implement the Alloy DB Cluster with different configuration.
If there are any concerns or issues with terraform-google-alloy-db module kindly raise an issue here.
