Резервное копирование для Consul

Consul — это отказоустойчивое распределённое клиент-серверное приложение (одно из многих), предназначенное для двух основных целей:

service discovery, то есть хранение списка сервисов, с возможностью явной регистрации или автоматического обнаружения по настраиваемым правилам, с проверкой состояния и реакцией на появление-отключение-сбой;
key-value storage, то есть хранение древовидной базы ключ-значение с настройками для сервисов.

В идеале содержимое такой базы должно формироваться исключительно через Configuration Management — например, через Ansible.

Резервное копирование для неё в таком случае выглядит излишним дублированием, потому что в первую очередь предназначено для аварийного восстановления, а здесь эта задача вполне решается повторной настройкой через CM.

Однако у этого правила есть исключения:

Во-первых, в реальной жизни идеал редко достижим и даже на production иногда вносятся горячие правки, которые не фиксируются в CM. От резервного копирования при этом требуется не столько сохранение изменений, сколько уведомление о самом факте их возникновения (в том числе с целью пресечения подобных рецидивов).

Во-вторых, в тестовых окружениях разработчикам обычно позволяется работать с базой Консула напрямую, дабы не замедлять творческий процесс производственной дисциплиной. Когда база формируется «на живую нитку» параллельно с использующим её приложением — резервные копии становятся единственным источником данных для отката при крупных ошибках.

В-третьих (хотя такой подход выглядит порочным, иногда он оказывается меньшим из зол), достаточно сложному приложению может потребоваться самостоятельно обновлять свои настройки в Consul'e, а не только читать их из него. Без резервных копий снова не обойтись.

И в-четвёртых, CM обычно неторопливы, поэтому если счёт идёт на секунды — восстановление из резервной копии предпочтительнее, потому что выполнится быстрее.

Какие инструменты предоставляет Consul?

snapshot
kv export
kv get

Snapshots

Достоинства:

скорость
атомарность
полнота сведений (кроме базы ключей-значений, в снимок сохраняются списки сервисов, сессии, права доступа и так далее)

Недостатки:

нечитабельность
невозможность сравнения изменений между двумя снимками
требуется авторизация

Рабочий пример:

#!/bin/sh -e

 DIR="/opt/consul-snapshots"
DUMP="consul-$(date +%Y-%m-%d-%H%M).snap"
AUTH="$(awk -F'"' '$2 == "acl_master_token" { print $4; exit; }' /etc/consul/config.json)"

mkdir -p -m700 "$DIR"
consul snapshot save -token "$AUTH" -stale "$DIR/$DUMP"
find "$DIR" -type f -mtime +2 -delete

Не забудьте добавить в него копирование на удалённый сервер, чтобы в случае аварии резервная копия не пропала вместе с оригиналом.

Export

Достоинства:

cоздаётся JSON-файл, который можно использовать для сохранения в Git и обнаружения изменений;
полученный JSON можно импортировать обратно в Consul.

Недостатки:

открытым текстом записаны только ключи, значения закодированы в Base64, поэтому для ручного просмотра непригодны.

Get

Достоинства:

полная читабельность — текстовый файл состоит из строк с парами «ключ: значение».

Недостатки:

невозможность загрузки обратно в Consul, так как значения могут содержать любые байты, в том числе служебные символы — двоеточие, перевод строки и так далее.

Рабочий пример (сразу для export и get):

#!/bin/sh -e

mkdir -pm700 /opt/consul-git
cd           /opt/consul-git

test -d .git || git init

A="$(consul catalog datacenters)"

test "$A" = "" && exit 1

for a in $A; do consul kv export       -datacenter="$a" > "$a.json"; done
for a in $A; do consul kv get -recurse -datacenter="$a" > "$a.txt" ; done

git add -A

LANG=C git status | grep -q '^nothing to commit' && exit 0 || :

git commit -am "AutoCommit-$(date +%Y-%m-%d-%H%M)"