etckeeper


| Следующая

Настройка etckeeper с автоматическим пушем изменений и просмотром в gitlist

 

Довольно давно я храню конфигурации серверов которые администрирую в git, с помошью etckeeper. Etckeeper - это, если кто не знает, набор скриптов, надстройка над git, которая автоматизирует проверку изменений, их коммит в репозиторий и встраивается в pre-install и post-install менеджера пакетов apt.
В этом посте я хочу рассказать об использовании etckeeper совместно с gitlist для более удобного, и наглядного просмотра изменений.

Установим необходимое:

sudo apt-get install etckeeper git-core nginx php-fpm

 

При установке, etckeeper сам инициализирует репозиторий в директории /etc/, и сделает первый коммит.

Для начала нам необходимо определится куда мы будем "пушить" изменения. У меня для этих целей есть отдельный небольшой "инстанс" в digitalocean в который собираются изменения со всех серверов и доступ к gitlist только через шифрованный VPN, но, в принципе, ничего не мешает хранить их на том же сервере, где etckeeper. Для упрощения далее будем считать, что всё это на одном сервере, но я ещё раз заострю внимание на том, что делать так крайне не рекомендуется, т.к. в репозитории будут файлы shadow, passwd и groups в которых есть список всех групп, пользователей и их зашифрованные пароли.

Настроим возможность делать push на сервер:

useradd -m -s /bin/bash git 
su - git
mkdir ~/.ssh/
chmod -R 700 ~/.ssh/
touch ~/.ssh/authorized_keys
mkdir repositories/ # здесь будут все репозитории
chmod 0755 repositories/ # gitlist будет работать с правами nginx 
chown git:www-data repo/ # поэтому необходимо дать права на чтение группе www-data

 

В файл ~/.ssh/authorized_keys пользователя git, необходимо добавить публичный ключ пользователя который будет пушить изменения. В случае с etckeeper - это root.
Создадим сразу на сервере пустой репозиторий для конфигов. Всё тем же пользователем git выполняем:

cd repositories/
mkdir servername-etc.git/
cd servername-etc.git/
git init --bare

 

Теперь на сервере, с которого необходимо отправлять изменения укажем git куда следует пушить изменение в репозитории:

cd /etc/
git remote add origin git@host-with-git-server.com:~/repositories/servername-etc.git
git push origin master

 

Настроим etckeeper чтобы в дальнейшем он автоматически делал push на удалённый сервер. Для этого откроем его конфигурационный файл /etc/etckeeper/etckeeper.conf и изменим/добавим там следующее:

VCS="git"
PUSH_REMOTE="origin"

 

Почти всё. Осталось настроить nginx и gitlist. Я уже описывал этот процесс в другом посте - Установка простого просмоторщика git репозиториев - gitlist на CentOS 6 с Nginx, поэтому здесь я на этом останавливаться не буду - настройка аналогична.

С настройкой всего этого добра разобрались. Теперь хочу немного рассказать об использовании etckeeper.
Как я уже писал выше, во время установки будут автоматически выполнены etckeeper initи etckeeper commit 'initial commit'. В принципе, после этого можно вообще забыть про существование etckeeper. Дальше можно работать с директорией /etc как с обычным git-репозиторием. Раз в сутки будут запускаться скрипты etckeeper, проверять изменения и делать коммиты при их обнаружении. Так же, при установке или удалении какого либо пакета, если будут изменения в /etc - они будут автоматически добавлены. В комментарии к коммиту будет указан хеш. Хорошего в этом мало, поэтому когда администратором сервера вносятся изменения, лучше их вручную добавлять в репозиторий, и давать коммиту осмысленный комментарий:

cd /etc
git add changed_file.conf # либо git add -A - для добавления всех изменённых файлов
git commit -m 'Change blah-blah-blah.."
git push origin master

 

Как видите, ничем не отличается от обычной работы с git-репозиторием. К сожалению, не все администраторы знакомы с git, поэтому ниже несколько примеров. Напоминаю, что все команды вводятся находясь в директории /etc. Изменения так же можно вносить из любого места, только с помощью самого etckeeper который в данном случае, является набором "алиасов" к VCS (Version Control System - система контроля версий), однако, лично мне, удобнее работать как с обычным git-репозиторием.

Посмотреть текущие, не добавленные изменения:

#> git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   etckeeper/etckeeper.conf
#
no changes added to commit (use "git add" and/or "git commit -a")

 

Просмотр коммитов:

#> git log
commit 398ddc1211bb95c4d1881938014c789f2c182a56
Author: root 
Date:   Fri Oct 10 17:53:47 2013 +0400    Before system updatecommit 9bb869f4ef76fe8ffc49b8873d3354ed16e9edf0
Author: root 
Date:   Fri Oct 10 11:45:09 2013 +0400    added config to nginx for gitlistcommit a9dcfbf2e57782c6b184183854c170e6893a1968
Author: root 
Date:   Fri Oct 10 08:10:09 2013 +0400    added site-name.com to nginxcommit 9e89351dd57df642b0c616d0d4edb01878183b98
Author: root 
Date:   Sun Oct 5 15:33:50 2013 +0400    cleared up site-name.com configuration file

 

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

:::git #> git diff 9f679369ffbd8191d6e028f59f736ca9319c25f8 diff --git a/etckeeper/etckeeper.conf b/etckeeper/etckeeper.conf index c95f377..400cffe 100644 --- a/etckeeper/etckeeper.conf +++ b/etckeeper/etckeeper.conf @@ -36,3 +36,5 @@ HIGHLEVEL_PACKAGE_MANAGER=apt # The low-level package manager that's being used. # (dpkg, rpm, pacman-g2, etc) LOWLEVEL_PACKAGE_MANAGER=dpkg + +PUSH_REMOTE="origin"

 

Просмотр коммитов и изменений определённого файла:

#> git log -p path/to/file

 

Для более детального изучения, рекомендую прочитать "книгу git" - http://git-scm.com/book/ru.