Автоматизация PostgreSQL — Ansible и Terraform
Infrastructure as Code для БД
Ручная настройка «зайду по SSH и поправлю conf» не масштабируется и не аудируется. IaC даёт:
- версионирование параметров;
- повторяемость dev/stage/prod;
- code review изменений
max_connectionsтак же, как кода приложения.
Общая теория — IaC, Terraform, Ansible.
Ansible — bare metal и VM
Типовая role структура:
roles/postgresql/
tasks/main.yml
templates/postgresql.conf.j2
templates/pg_hba.conf.j2
handlers/main.yml
defaults/main.yml
tasks/main.yml (фрагмент):
- name: Install PostgreSQL
ansible.builtin.package:
name: postgresql-16
state: present
- name: Deploy postgresql.conf
ansible.builtin.template:
src: postgresql.conf.j2
dest: "/etc/postgresql/16/main/postgresql.conf"
notify: Restart postgres
- name: Ensure PostgreSQL started
ansible.builtin.service:
name: postgresql
state: started
enabled: true
defaults/main.yml:
postgresql_shared_buffers: 2GB
postgresql_max_connections: 200
postgresql_work_mem: 16MB
Patroni + etcd часто разворачивают отдельными roles (community patroni, etcd). Idempotency — повторный play не ломает данные, если tasks guarded creates: / when:.
Terraform — managed PostgreSQL
Пример AWS RDS (упрощённо):
resource "aws_db_instance" "app" {
identifier = "app-postgres"
engine = "postgres"
engine_version = "16.3"
instance_class = "db.r6g.large"
allocated_storage = 100
max_allocated_storage = 500
storage_encrypted = true
db_name = "appdb"
username = "app"
password = var.db_password
multi_az = true
backup_retention_period = 14
backup_window = "03:00-04:00"
parameter_group_name = aws_db_parameter_group.app.name
vpc_security_group_ids = [aws_security_group.db.id]
db_subnet_group_name = aws_db_subnet_group.db.name
deletion_protection = true
skip_final_snapshot = false
final_snapshot_identifier = "app-postgres-final"
}
resource "aws_db_parameter_group" "app" {
family = "postgres16"
parameter {
name = "log_min_duration_statement"
value = "500"
}
parameter {
name = "shared_preload_libraries"
value = "pg_stat_statements"
}
}
Output для приложения:
output "database_url" {
value = "postgres://${aws_db_instance.app.username}:${var.db_password}@${aws_db_instance.app.endpoint}/${aws_db_instance.app.db_name}"
sensitive = true
}
Аналоги — yandex_mdb_postgresql_cluster, google_sql_database_instance, azurerm_postgresql_flexible_server.
Terraform + Kubernetes operator
CloudNativePG cluster как CR через kubernetes_manifest или Helm provider:
resource "helm_release" "cnpg" {
name = "cloudnative-pg"
repository = "https://cloudnative-pg.github.io/charts"
chart = "cloudnative-pg"
namespace = "database"
}
GitOps (Argo CD) хранит manifest Cluster в Git; Terraform создаёт только cluster K8s / VPC / S3 bucket для Wal-G.
Секреты
| Anti-pattern | Pattern |
|---|---|
| password в terraform.tfvars в Git | Vault, AWS Secrets Manager, SOPS |
| plain Secret YAML в repo | External Secrets Operator |
| один password навсегда | rotation job |
Ansible Vault для group_vars/production.yml.
CI/CD для миграций схемы
IaC не заменяет Flyway/Liquibase/Alembic для DDL приложения:
- Terraform/Ansible — инстанс, users, extensions, GUC.
- Migration tool — schema версионирование в pipeline приложения.
Порядок deploy — migration до rollout app, совместимость backward (expand-contract).
Drift detection
terraform planв CI — изменения в managed DB.- Ansible
--checkили tools вродеdatabagдля сравнения live GUC с template. pg_settings.source— что задано через file vs session.
Практика
- Ansible play — установка Postgres 16 на VM, deploy custom
postgresql.conf. - Terraform module — RDS или Yandex MDB в dev account, output endpoint.
- Pipeline —
terraform planon MR,applyon merge to main с approval.
Связанные материалы
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). MVCC, XID, снимки данных, системные поля xmin/xmax, VACUUM и autovacuum, bloat, wraparound, процессы postmaster, Shared Buffers и WAL. pg_dump, pg_basebackup, PITR, pg_probackup, Wal-G, стратегия 3-2-1, восстановление в Kubernetes и после failover. pg_stat_statements, pg_stat_activity, auto_explain, pgBadger, Prometheus postgres_exporter, типовые метрики SLA и алерты. EXPLAIN и EXPLAIN ANALYZE, B-tree, GiST, SP-GiST, GIN, BRIN, частичные и составные индексы, типовые ошибки планировщика. Тонкая настройка памяти (shared_buffers, work_mem, maintenance_work_mem), I/O (effective_cache_size, random_page_cost), WAL, checkpoint и autovacuum. Документная модель в Postgres, операторы и индексы JSONB, declarative partitioning по range/list/hash, связь с оконными функциями и CTE. Хранимые функции и процедуры PL/pgSQL, row-level и statement triggers, event triggers, асинхронные события через NOTIFY и LISTEN без polling. Streaming replication, logical replication, read replicas и Hot Standby, failover, connection pooling через PgBouncer — transaction и session pooling. Официальный образ postgres, volumes для PGDATA, переменные окружения, docker-compose с healthcheck, типовые ошибки контейнеризации СУБД. Managed PostgreSQL (RDS, Cloud SQL, Yandex Managed), StatefulSet, PersistentVolume, секреты, операторы Crunchy/Zalando, anti-patterns stateful в K8s. Patroni и DCS, сравнение с Greenplum и CockroachDB, когда нужен sharding, Citus, выбор архитектуры под OLTP и аналитику. Краткое резюме раздела 8.11 — архитектура, оптимизация, эксплуатация в контейнерах и Kubernetes, HA, бэкапы и автоматизация.Архитектура PostgreSQL и внутреннее устройство
Бэкапы PostgreSQL и восстановление
Профилирование и мониторинг PostgreSQL
Продвинутая оптимизация PostgreSQL и индексы
Конфигурация PostgreSQL — postgresql.conf
JSONB, партиционирование и расширения SQL в PostgreSQL
PL/pgSQL, триггеры и NOTIFY/LISTEN в PostgreSQL
Репликация PostgreSQL, Hot Standby и PgBouncer
PostgreSQL в Docker
PostgreSQL в облаке и Kubernetes
HA-кластеры PostgreSQL и распределённые СУБД
Практикум PostgreSQL — итоги