Docker: деплой master-slave конфігурації PostgreSQL



У попередньому матеріалі я розповідав про проект автоматизації деплоя Docker контейнерів, розробка якого стартувала на початку цього року. Минуло кілька місяців, Fabricio був значно поліпшений і допрацьований, і сьогодні я хочу розповісти про одне з останніх нововведень — про автоматичному деплое master-slave конфігурацій для PostgreSQL.

Запуск PostgreSQL в контейнерах — не найпопулярніша ідея, і тому є розумне пояснення: ні до чого додавати додаткові мережеві затримки до і без того досить завантажений сервісу. Але існує ряд випадків коли таке рішення все ж можна застосувати. Наприклад, коли ви повністю довіряєте Docker БД не відчуває серйозних навантажень, але при цьому важлива можливість дублювання/реплицирования збережених даних на кілька серверів. Або просто для тестування і налагодження установок перед застосуванням їх на бойових серверах.

Щоб не втомлювати читача (і користувача великою кількістю текстової інформації, я вирішив, що непогано було б привести «живі» приклади використання Fabricio на реально працюючих контейнерах — погодьтеся — краще один раз побачити.

Приклад конфігурації master-slave для PostgreSQL реалізований на трьох віртуальних машинах, в яких встановлено Docker. Створення та первісна настройка цих віртуальних машин повністю автоматизовані за допомогою Vagrant, тому складнощів з запуском прикладу бути не повинно.

Реалізовані сценарії
Найбільш важливим сценарієм у випадку з master-slave конфігурацією, безсумнівно, є відновлення працездатності БД після відмови майстер (провідного) сервера. Як правило, на бойових системах це налаштовується за допомогою систем постійного моніторингу серверів та автоматичного перемикання/виключення вийшли з ладу хостів — failover. Наприклад, для цих цілей можна використовувати популярний сьогодні інструмент pgpool-II. Однак, параметри таких систем — завдання не з тривіальних (та й покладатися повністю на автоматику вирішуються не всі), тому часто можна зустріти конфігурації, які обходяться без автоматичного відновлення після збою. Якщо збій в таких системах все ж відбувається, то усувається він, як правило, в ручному або напівавтоматичному режимі шляхом відновлення БД з резервної копії та/або перемиканням конфіги додатки на адресу нового майстра БД.

Fabricio пропонує підлозі-автоматичний спосіб відновлення працездатності після збою майстра. Для цього потрібно виконати всього одну команду, попередньо переконавшись, що вийшов з ладу сервер був замінений на новий, або видалений з налаштувань конфігурації деплоя:
fab --parallel db

Мало чим відрізняється від описаного вище варіанти, сценарій додати в конфігурацію нового підлеглого (slave) сервера, для цього достатньо прописати адресу цього сервера в списку хостів Fabricio і заново запустити команду деплоя. Початковий стан БД при цьому буде скопійовано з актуального ведучого (master) сервера.

Тест на идемпотентность
[vagrant@192.168.1.85] Executing task 'update'
 
[vagrant@192.168.1.86] Executing task 'update'
 
[vagrant@192.168.1.87] Executing task 'update'
 
[vagrant@192.168.1.85] Found master: 192.168.1.85
 
[vagrant@192.168.1.85] download: <file obj> <- /data/postgresql.conf
 
[vagrant@192.168.1.85] /data/postgresql.conf not changed
 
[vagrant@192.168.1.85] download: <file obj> <- /data/pg_hba.conf
 
[vagrant@192.168.1.86] Waiting for master info (10 seconds)...
 
[vagrant@192.168.1.85] /data/pg_hba.conf not changed
 
[vagrant@192.168.1.85] run: docker inspect --type container postgres
 
[vagrant@192.168.1.87] Waiting for master info (10 seconds)...
 
[vagrant@192.168.1.85] run: docker inspect --type image postgres:9.6
 
[vagrant@192.168.1.85] run: docker start postgres
 
[vagrant@192.168.1.86] download: <file obj> <- /data/recovery.conf
 
[vagrant@192.168.1.87] download: <file obj> <- /data/recovery.conf
 
[vagrant@192.168.1.87] /data/recovery.conf not changed
 
[vagrant@192.168.1.86] /data/recovery.conf not changed
 
[vagrant@192.168.1.87] download: <file obj> <- /data/postgresql.conf
 
[vagrant@192.168.1.86] download: <file obj> <- /data/postgresql.conf
 
[vagrant@192.168.1.87] /data/postgresql.conf not changed
 
[vagrant@192.168.1.86] /data/postgresql.conf not changed
 
[vagrant@192.168.1.86] download: <file obj> <- /data/pg_hba.conf
 
[vagrant@192.168.1.87] download: <file obj> <- /data/pg_hba.conf
 
[vagrant@192.168.1.87] /data/pg_hba.conf not changed
 
[vagrant@192.168.1.86] /data/pg_hba.conf not changed
 
[vagrant@192.168.1.87] run: docker inspect --type container postgres
 
[vagrant@192.168.1.86] run: docker inspect --type container postgres
 
[vagrant@192.168.1.87] run: docker inspect --type image postgres:9.6
 
[vagrant@192.168.1.86] run: docker inspect --type image postgres:9.6
 
[vagrant@192.168.1.87] run: docker start postgres
 
[vagrant@192.168.1.86] run: docker start postgres
 
[vagrant@192.168.1.87] No changes detected, update skipped.
 
[vagrant@192.168.1.85] No changes detected, update skipped.
 
[vagrant@192.168.1.86] No changes detected, update skipped.
 

 
Done.
 
Disconnecting from vagrant@127.0.0.1:2222... done.
 
Disconnecting from vagrant@127.0.0.1:2200... done.
 
Disconnecting from vagrant@127.0.0.1:2201... done.
 


Для тестових потреб Fabricio підтримує також розгортання конфігурації «з нуля», вибираючи майстра випадковим чином зі списку хостів.

Особливості реалізації
Автоматичне визначення майстра вимагає запуску Fabricio в режимі паралельного виконання, який типово вимкнено. Саме для цього в команді деплоя застосовується опція --parallel.

Якщо хоча б у одного з відомих є своя не пустий папка з даними (визначається по наявності файлу PG_VERSION), автоматичний вибір (promotion) нового майстра по-замовчуванню не проводиться (скрипт завершується з відповідною помилкою). І хоча ця процедура цілком безпечна, рекомендується ознайомитися з алгоритмом вибору нового майстри перш, ніж включати цю опцію. А вибирається майстер в такому випадку випадковим чином серед тих хостів, у яких є хоч якісь дані, при цьому на «порожні» хости (тобто не мають своєї БД) дані будуть скопійовані вже з нового майстра.

Також без спеціального вказівки не працює відкат до попереднього стану, з-за того, що master-slave конфігурація взагалі не передбачає наявність такого сценарію — адже автоматично майстер не починится, а якщо сталася якась помилка, то її краще лагодити вручну, а не покладатися на автоматику. Якщо опція відкату все ж буде увімкнено, то буде використовуватися логіка відкату, успадкована від батьківського класу (одиночної конфігурації PostgreSQL) — повернення попередніх конфіги і/або попереднього контейнера (або контейнерів) в залежності від того, що було поновлено під час останнього вдалого деплоя.

Подальші плани
В самому найближчому майбутньому, швидше за все до кінця року, буде реалізована підтримка режиму Swarm Docker версії 1.12 або вище. Що дасть можливість за допомогою Fabricio деплоить не тільки окремі контейнери, але відразу цілі сервіси з автоматичним масштабуванням і відмовостійкість.

Після впровадження рішення для Swarm, буде логічно зайнятися підтримкою Kubernetes та/або Mesos. Але окремої задачі на це поки немає, і все буде залежати від складності реалізації.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.