Patroni GitOps Config Manager

Назначение роли

Эта роль предназначена для безопасного управления конфигурацией кластера Patroni. Она предоставляет следующие возможности:

• Создание резервных копий текущей конфигурации с timestamp
• Валидация изменений конфигурации перед применением
• Наглядное отображение различий между текущей и новой конфигурацией
• Безопасное применение изменений через REST API Patroni
• Проверка состояния кластера после изменений
• Уведомление о необходимости перезагрузки нод (если требуется)
• Автоматическое управление историей конфигурационных файлов

Требования

• Ansible 2.9+
• Доступ к Patroni REST API (порт 8008)
• Python 3 для валидации YAML
• Утилита diff с поддержкой цветного вывода

Переменные роли

Основные переменные, которые можно переопределить:

• config_dir (по умолчанию: "/ansible/history") - директория для хранения истории конфигураций
• config_file (по умолчанию: "/ansible/patroni_config.yaml") - путь к файлу с изменениями конфигурации
• patroni_host (по умолчанию: "10.14.0.180") - хост кластера Patroni

Как внести изменения в конфиг кластера?

1. Для начала создайте новый branch по имени кластера.

   # Переключиться на основную ветку (если нужно)
   git checkout main  
   
   # Получить последние изменения
   make git pull
   
   # Создать новую ветку
   make git new
   

2. Сбилдите образ Ansible для локальной работы, тестов и линта.

   make docker build
   

3. Внесите изменения в файл patroni_config.yaml. Все изменения буду добавлены в конфиг кластера. Если такие переменные в конфиге существуют, они будут заменены. Если переменных нет, будут добавлены.

   postgresql:
     parameters:
       max_connections: 100
       shared_buffers: "1GB"
     use_pg_rewind: true
   

4. Линт, тесты и пуш в гит

   # Внести изменения в secret.yaml
   make vault edit
   
   # Проверить роль
   make role lint 
   
   # Протестировать роль
   make role test
   
   # Пушим в гит...
   make git push
   

5. Если у вас GitLab - смотрим и наслаждаемся. Не забудьте нажать кнопочку в GitLab на deploy изменений конфига в кластере. Ну, или закомментируйте в gitlab-ci.yml строку

   when: manual
   

   что бы можно было деплоить автоматом...

Анализ результатов

После выполнения этапа подготовки:

• Будет показан цветной diff изменений
• В директории config_dir появятся:
• Резервная копия текущей конфигурации с timestamp
• Файл last.yaml с новой конфигурацией

После выполнения этапа применения:

• Будет выведен статус кластера
• Появится предупреждение, если требуется перезагрузка нод
• Старые конфигурации будут автоматически удалены (остаются последние 10)

Особенности работы

Безопасность:

• Конфигурация всегда сохраняется перед изменениями
• Изменения проверяются на валидность перед применением
• Показывается подробный diff перед применением

Информирование:

• Явное предупреждение о необходимости перезагрузки
• Подробный вывод статуса кластера после изменений
• Сохранение истории изменений

Автоматизация:

• Управление историей конфигураций (автоочистка старых файлов)
• Проверка состояния кластера после изменений

Важные примечания

• Роль не выполняет автоматическую перезагрузку нод Patroni, так как это потенциально опасная операция
• При необходимости перезагрузки будет показана команда для ручного выполнения
• Все изменения конфигурации сохраняются с timestamp для возможности отката
• Для работы требуется доступ к API Patroni (порт 8008)