configs2git

15 февраля 2018

Для файлов конфигурации процедура резервного копирования имеет две особенности:

  • важна не только последняя рабочая версия, но и история изменений;
  • т.к. 99% файлов конфигурации являются текстовыми, желательно, чтобы история изменений имела построчный вид.

Вывод: для резервного копирования файлов конфигурации нужен специальный инструмент, например, как innobackupex для MySQL или slapcat для OpenLDAP.

Системы контроля версий наподобие Git или Subversion не вполне эффективны для этой цели:

  • кроме /etc, файлы конфигурации могут быть раскиданы по десяткам других каталогов;
  • внутри /etc подавляющее большинство файлов не представляет интереса, т.к. никогда не изменялось с момента установки из инсталляционных пакетов.

Выводы:

  • утилита резервного копирования должна собирать нужные файлы из рабочих каталогов в один временный, и уже из него сохранять их в Git;
  • единственным способом отсеять лишний мусор является явное ручное перечисление файлов и каталогов, которые представляют интерес.

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

  • трудозатраты на составление списка;
  • риск упустить что-то нужное.

Очевидные достоинства ручного перечисления:

  • риск упустить что-то нужное дисциплинирует и заставляет проверять составляемые данные более тщательно;
  • тщательная проверка составляемого списка даёт администратору более полное представление об обслуживаемой системе.

Результат:

  • Утилита Configs2git: https://github.com/ilyaevseev/configs2git
  • В отличие от систем Configuration Management наподобие Puppet или Ansible, configs2git не заставляет администратора отказываться от ручной правки настроек, а предоставляет легковесный механизм их фиксации.
  • Иными словами, configs2git предназначен не для наведения полного порядка, а для сведения беспорядка до приемлемого уровня с минимальными усилиями.
  • Для сопровождения простых штучных конфигураций такой подход представляется более оптимальным — меньший порог вхождения, меньше дополнительных действий.

Установка и подготовка к запуску

Устанавливаем необходимые пакеты:

yum install git rsync mail

Создаём каталог и сразу закрываем доступ к нему от всех, кроме суперпользователя:

mkdir /home/configs2git
chmod 700 /home/configs2git

Все остальные команды выполняются в каталоге /home/configs2git:

cd /home/configs2git

Скачиваем https://github.com/ilyaevseev/configs2git/blob/master/configs2git

Делаем его исполняемым:

chmod +x configs2git

Создаём пустой git-репозиторий:

git init myconfigs

Создаём новый файл myconfigs.lst и перечисляем в нём файлы и каталоги, которые хотим отслеживать, например:

/boot/grub/grub.cfg
/etc/fstab
/etc/group
/etc/passwd
/etc/shadow

/var/named/

Создаем файл Update:

#!/bin/sh
cd "$(dirname "$0")" && ./configs2git myconfigs.lst myconfigs

Делаем его исполняемым:

chmod +x Update

Сохранение во внешнем Git-репозитории

Создаём приватный и публичный SSH-ключи:

ssh-keygen

На Git-сервере:

  • создаём учётную запись;
  • копируем в неё /root/.ssh/id_rsa.pub (созданный командой ssh-keygen);
  • создаём репозиторий configs2git/server1.git;
  • назначаем учётную запись её владельцем.

Синхронизируем локальный репозитарий на Git-сервер:

cd /home/configs2git/myconfigs
git remote add git@git.example.lan:configs2git/server1.git
git push -u origin master

Создаём файл /home/configs2git/Push (и делаем исполняемым через chmod +x):

#!/bin/sh

find "$(dirname "$0")/" -mindepth 2 -maxdepth 2 -type d -name ".git" \
    -printf "echo -n '%h ...  ' && cd %h && git push\n" | sh -`

Порядок использования

  • Редактируем отслеживаемые файлы;
  • cd /home/configs2git
  • ./Update
  • ./Push

Поддержка Mercurial

Если переименовать утилиту из configs2git в configs2hg, она станет использовать Mercurial вместо Git.

Что может быть добавлено в будущем?

  • поддержка масок в именах файлов;
  • поддержка виртуальных контейнеров.

← Назад в Блог