2.3 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform | cloud-learning | video | DevOps & SRE/03_Terraform |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Cloud Transformation Programme-Deploying RDS via Terraform.mp4 | summarized (Gemini 摘要) |
Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform
Source: NAS /volume2/work/Public Cloud Learning Sessions/Learning Sessions _ Cloud Transformation Programme-Deploying RDS via Terraform.mp4
Type: VIDEO | Category: 03_Terraform
Status: 🟡 Awaiting Whisper transcription → Summary
Greg from the DBRE team discusses deploying RDS via Terraform, advocating its use over the console for deploying any size RDS into Amazon. The presentation covers why infrastructure as code is helpful, clarifies the use of grunt work modules, and introduces SRE core modules. It also includes technical details, live demos of deployment, maintenance, upgrades, and monitoring/alarming.
Key benefits of infrastructure as code include speed, flexibility, consistency, disaster recovery, documentation, and automation. The code is the documentation. There are two main options for deploying RDS: the bare-bones RDS module and the more comprehensive RDS service. The grunt work RDS service is recommended due to its pre-built features like KMS key encryption and CloudWatch alarming. The SRE core modules are less fully featured than the grunt work service.
To deploy an RDS database, use Terragrunt, a wrapper around Terraform, to keep code clean and avoid repeating variables. We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time. Use a tagged release instead of the master branch for stability. Basic variables include VPC, database type (Oracle, Postgres), port, and license model. For day two operations like scaling, patching, and major version upgrades, changes are made in the TerraGrant file and applied via GitHub pull requests and Atlantis. Monitoring is achieved through CloudWatch dashboards and alarms, with considerations for burstable instance shapes and CPU credits.