Как организована работа с базами данных на проекте

Организация работы с базами данных на проекте

Работа с базами данных (БД) в современном DevOps.

Жизненный цикл управления базами данных

1. Проектирование и версионирование схемы. Схема БД (таблицы, индексы, представления) управляется как код. Мы используем инструменты миграций (например, Flyway, Liquibase или Alembic для Django). Файлы миграций хранятся в репозитории вместе с кодом приложения.

    Пример структуры каталога для Flyway:

```sql
-- V1__create_users_table.sql
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) NOT NULL
);

-- V2__add_created_at_column.sql
ALTER TABLE users ADD COLUMN created_at TIMESTAMP DEFAULT NOW();
```

2. Автоматизация развертывания изменений. Миграции интегрируются в CI/CD пайплайн. При создании Pull Request можно запускать миграции на изолированной тестовой БД для проверки. Слияние в основную ветку инициирует деплой, который включает последовательное применение миграций на соответствующих этапах (staging, production).

    Пример этапа в GitLab CI:

```yaml
deploy_migrations:
  stage: deploy
  script:
    - flyway -url=$DATABASE_URL -user=$DB_USER -password=$DB_PASSWORD migrate
  only:
    - main
```

3. Управление окружениями. Для каждого этапа (development, testing, staging, production) разворачивается своя изолированная БД. Это позволяет безопасно тестировать изменения. Часто используются:

    *   **Докер-контейнеры** или легкие инстансы для разработки и CI.
    *   **Управляемые облачные сервисы** (AWS RDS, Google Cloud SQL, Yandex Managed Service for PostgreSQL) для staging и production.
    *   Инфраструктура БД описывается как код (**Terraform**, **Pulumi**).

    Пример описания RDS инстанса в Terraform:

```hcl
resource "aws_db_instance" "production" {
  identifier     = "app-prod-db"
  engine         = "postgresql"
  instance_class = "db.t3.micro"
  allocated_storage = 20
  username       = var.db_username
  password       = var.db_password
  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name
}
```

Ключевые DevOps-практики для БД

• Конфигурация как код: Параметры БД (настройки памяти, пулов соединений) хранятся в конфигурационных файлах (например, в Ansible ролях или Terraform модулях) и применяются автоматически.
• Резервное копирование и восстановление (Backup & Restore): Полностью автоматизированные процессы. Бэкапы делаются регулярно (ежедневно, ежечасно в зависимости от RPO) с помощью нативных инструментов СУБД или облачных сервисов. Процедура восстановления регулярно тестируется на staging-окружении.

  # Пример cron задачи для дампа PostgreSQL
  0 2 * * * pg_dump -U $USER -h $HOST $DB_NAME | gzip > /backups/db-$(date +\%Y\%m\%d).sql.gz
  

• Мониторинг и оповещение: Ключевые метрики отслеживаются в системах типа Prometheus/Grafana или через облачные мониторинги:

    *   Загрузка CPU/IOPS/памяти.
    *   Количество активных соединений.
    *   Запросы с высокой задержкой (slow queries).
    *   Статус репликации.
    *   Настроены алерты при достижении пороговых значений.

• Обеспечение безопасности:

    *   Управление секретами (учетные данные БД) через специализированные хранилища (**Hashicorp Vault**, **AWS Secrets Manager**). Они никогда не хранятся в коде.
    *   Шифрование данных на rest и in transit (использование TLS).
    *   Строгое управление доступом на основе ролей (RBAC) как на уровне СУБД, так и на уровне облачной инфраструктуры.

• Работа с данными в продакшене: Для выполнения разовых операций (обновление большого объема данных, исправление) используются предварительно согласованные и проверенные скрипты, которые также версионируются и запускаются через CI/CD, чтобы иметь аудит-лог.

Проблемы и их решения

Основная сложность — деплой миграций, меняющих схему на лету в продакшене без простоя (zero-downtime deployments). Для этого применяются стратегии, например, для переименования колонки:

1. Добавить новую колонку параллельно со старой.
2. Написать триггер/изменить код приложения для двойной записи в обе колонки.
3. Перенести данные из старой колонки в новую фоновым процессом.
4. Перевести чтение на новую колонку, убедиться в корректности.
5. Удалить старую колонку и триггер.

Таким образом, в DevOps-подходе база данных перестает быть "магическим чёрным ящиком" и становится полностью управляемым, версионируемым, тестируемым и наблюдаемым компонентом инфраструктуры, жизненный цикл которого интегрирован в общий поток доставки приложения.