Управление конфигурационными файлами с помощью Git

Cloud Server, Linux, VPS | Amber | Комментировать запись

Работая с машиной Linux, пользователь должен настроить среду в соответствии со своими требованиями. Некоторые распространенные приложения (например, текстовые редакторы) настолько конфигурируемы, что иногда их настроенные по умолчанию версии кажутся совершенно другими программами.

Отлаживание конфигураций – весьма объемная работа, занимающая немало времени; кроме того, по мере использования сервера конфигурации будут требовать внесения небольших правок. Это бывает достаточно сложно выполнить на одном компьютере, а при попытке синхронизировать конфигурации нескольких машин все может стать еще более сложным и запутанным.

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

Для демонстрации действий используется сервер Ubuntu 12.04, но любой современный дистрибутив будет работать таким же образом.

Основные понятия

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

Предположим, что есть компьютер с достаточно сложными конфигурациями в стадии разработки. Эту систему нужно использовать для создания репозитория Git. В данный репозиторий нужно добавить соответствующие файлы, которые позже нужно будет толкнуть в удаленный репозиторий Git.

Удаленный репозиторий Git – удобное место для хранения конфигурационных данных, поскольку позже к нему можно будет получить доступ с любой машины, которой нужны эти файлы. Некоторые пользователи предпочитают хранить свои файлы на платформах совместной разработки (например, GitHub), но это достаточно рискованно, поскольку можно случайно разместить конфиденциальные данные в общедоступном для чтения месте.

Данное руководство использует GitLab, аналогичную GitHub платформу для хостинга git-репозиториев, которую можно запустить на собственном сервере.

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

Какие файлы можно хранить в git-репозитории?

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

Файлы, содержащие сильно зависящие от системы значения, вероятно, лучше обработать вручную или с помощью системы управления конфигурациями (как Chef, Puppet или Ansible).

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

Использование Git – отличное решение для хранения конфигураций инструментов и файлов пользовательской среды (таких, как vim, emacs, screen, tmux, bash, etc.).

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

Настройка ведущего сервера

Данное руководство использует машину с уже отредактированными конфигурационными файлами. Машина, измененные конфигурации которой нужно распространить между другими машинами, называется ведущей (или порождающей).

Прежде чем перейти к синхронизации конфигураций, убедитесь, что git установлена. Установить git можно из репозитория дистрибутива. Для установки на Ubuntu используйте команды:

sudo apt-get update
sudo apt-get install git

После установки git нужно отладить некоторые детали конфигураций, которые будут чистить коммиты. Внесите свои имя и адрес электронной почты в следующие команды:

git config --global user.name "имя"
git config --global user.email "электронный@адрес.com"

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

Использование домашнего каталога как Git-репозитория

Вероятно, самый простой подход – это инициализировать git-репозиторий в домашнем каталоге. Преимуществом данного подхода является его простота, но такой репозиторий очень быстро засоряется в процессе работы.

Итак, чтобы инициализировать git-репозиторий в домашнем каталоге, наберите:

cd ~
git init

Это создаст репозиторий в домашнем каталоге. Обратите внимание, многие файлы отмечены как «untracked» («неотслеживаемые») :

git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   .bash_history
#   .bash_logout
#   .bashrc
#   .gitconfig
#   .profile
#   .screenrc
#   .ssh/
#   .viminfo
#   .vimrc
nothing added to commit but untracked files present (use "git add" to track)

Конечно, это хорошо, что git видит все файлы, но в дальнейшем этот длинный список из неотслеживаемых файлов будет мешать.

Если вам это не мешает, можете просто добавить нужные файлы в git-репозиторий следующим образом:

git add .bashrc
git add .vimrc
. . .

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

Чтобы сделать это, нужно создать файл  .gitignore в каталоге с подстановочным знаком:

echo "*" > .gitignore

Выполнив это и проверив состояние репозитория, можно увидеть, что теперь он пуст:

git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

Теперь можно добавить в него необходимые файлы, добавив к команде add флаг –f:

git add -f .bashrc
git add -f .vimrc
. . .

Обратите внимание: всякие внесенные изменения должны быть подтверждены:

git commit -m "Initial configuration commit"

Создание конфигурационного каталога для хранения файлов

Еще один подход к созданию git-репозитория, полностью охватывающего домашний каталог – создать специальный каталог для отслеживания этих файлов.

В данном руководстве такой каталог называется configs:

cd ~
mkdir configs

Теперь можно войти в данный каталоги и инициировать в нем git-репозиторий:

cd configs
git init

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

Чтобы выполнить обе эти задачи одновременно, скопируйте нужные файлы в данный каталог, а затем создайте системные ссылки на основной каталог.

Это выглядит так:

mv ~/.vimrc .
ln -s .vimrc ~/
mv ~/.bashrc .
ls -s .vimrc ~/
. . .

Теперь все конфигурационные файлы с актуальными настройками находятся в ~/configs, а символические ссылки на эти файлы расположены в домашнем каталоге.

Этот способ немного сложнее предыдущего, но он немного упрощает работу с git. Чтобы добавить в репозиторий все файлы, наберите:

git add .

Затем нужно подтвердить внесенные изменения:

git commit -m "Initial configuration commit"

Как уже было сказано, данный подход упрощает работу с git, но при этом немного усложняет фактическое управление файлами.

Отделение Git-каталога из рабочего дерева

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

Это удобно, если версию домашнего каталога нужно подверждать сразу же, но наличие других хранилищ Git усложняет этот процесс.

В целом, при инициализации git-репозитория по умолчанию текущий каталог считается рабочим каталогом, в котором будут размещаться и изменяться файлы. В этом каталоге будет создан git-репозиторий под названием .git.

Тем не менее, можно заставить git использовать отдельный рабочий каталог.

Начать можно так же, как и в предыдущий раз – с создания отдельного каталога для конфигураций:

cd ~
mkdir configs

Опять же, откройте каталог и инициализируйте git-репозиторий.

cd configs
git init

Теперь проверьте статус git:

git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

На данный момент рабочим каталогом является ~/configs, в котором находится репозиторий. В нем нет никаких файлов, потому подтверждать нечего.

Теперь нужно указать другой рабочий каталог, используя опцию core.worktree:

git config core.worktree "../../"

Эта команда установит рабочий каталог относительно пути каталога .git. Первая последовательность «../» ссылается на каталог ~/configs, а вторая указывает на один шаг дальше от домашнего каталога.

В целом, это говорит git «репозиторий находится здесь, а нужные файлы – на два уровня выше».

Проверьте состояние хранилища, чтобы убедиться, что все было выполнено верно.

git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       ../.bash_history
#       ../.bash_logout
#       ../.bashrc
#       ../.gitconfig
#       ../.lesshst
#       ../.profile
#       ../.screenrc
#       ../.ssh/
#       ../.viminfo
#       ../.vimrc
nothing added to commit but untracked files present (use "git add" to track)

Как видно, теперь git ссылается на файлы домашнего каталога.

Теперь нужно добавить файлы, сославшись на эти файлы в домашнем каталоге:

git add ~/.vimrc
git add ~/.screenrc
git add ~/.bashrc
. . .

Подтвердите внесенные изменения:

git commit -m "Initial configuration commit"

В данном  каталоге нужно создать файл /.git, чтобы git соединил все элементы на случай, если позже их нужно будет извлечь.

cd ~
nano .git

Внести в данный файл нужно всего одну строку, направляющую git в файл репозитория:

gitdir: /home/your_user/configs/.git

Настройка удаленного сервера Git

Существует множество способов настройки удаленного репозитория для хранения файлов.

Проще всего толкнуть репозиторий конфигураций на GitHub.  Для некоторых пользователей это отличное решение; но имейте в виду, что это действие представляет риск случайного разоблачения конфиденциальных данных.

Избежть этого можно путем использования закрытого git-репозитория, отличным примером которого является GitLab.

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

Создав пустой репозиторий,  GitHub или GitLab выведет страницу с командами-подсказками, как переместить конфигурационные файлы в репозиторий. Если SSH-ключи еще не были добавлены, с помощью специальной клавиши можно переключиться с команд SSH на команды HTTP.

Используйте рекомендации, чтобы переместить конфигурационные файлы в удаленный репозиторий. Это делается примерно так:

cd configs      # or "cd ~" if you are using your home directory
git remote add origin http://git_lab_ip/your_gitlab_user/repo_name.git
git push -u origin master

Это толкнет файлы в репозиторий GitLab.

Извлечение конфигураций из удаленного репозитория

Теперь, когда конфигурационные файлы перемещены в удаленный репозиторий, их можно извлечь на другие машины. Для этого нужно сослаться на сервер, на который нужно извлечь конфигурационные файлы, как на целевую машину.

Убедитесь, что на целевой машине установлена система gitю Опять же, на Ubuntu это делается так:

sudo apt-get update
sudo apt-get install git

После установки нужно установить основные переменные конфигураций:

git config --global user.name "your name"
git config --global user.email "email@domain.com"

Дальнейшие действия зависят от того, как данная машина должна взаимодействовать с файлами git-репозитория.

Контроль версий домашнего каталога

При необходимости контролировать версии домашнего каталога создайте в нем пустой git-репозиторий:

cd ~
git init

Теперь укажите репозиторий GitHub или GitLab как источник данного репозитория:

git remote add origin http://git_lab_ip/your_gitlab_user/repo_name.git

На целевой машине могут оказаться файлы, вступающие в конфликт с файлами из репозитория. К примеру, файл ~/.bashrc создается для каждого пользователя по умолчанию.

Как вариант, можно просто удалить или переместить все файлы, конфликтующие с файлами репозитория. Также можно сказать Git заменить все конфликтующие файлы новыми версиями.

Это делается путем извлечения удаленных файлов, после чего нужно сказать git вернуться к самым последним версиям (то есть, к удаленным файлам):

git fetch --all
git reset --hard origin/master

Это действие переместит все удаленные файлы на целевую машину.

Файлы можно легко отредактировать и вернуть в удаленный репозиторий.

echo "# a comment" >> .bashrc
git add .bashrc
git commit -m "test"
git push origin master

Использование отдельного конфигурационного каталога

Если для хранения актуальных конфигурационных файлов используется отдельный каталог, и теперь нужно связать его ссылками с домашним каталогом, просто клонируйте репозиторий.

Для этого нужен URL, ссылающийся на удаленный репозиторий. Теперь вместо инициализации нового git-репозитория нужно использовать его клон.

git clone http://git_lab_ip/gitlab_пользователь/configs.git

Перейдите в клонированный каталог:

cd configs

Он содержит все конфигурационные файлы. Затем можно связать их с домашним каталогом по отдельности:

ln -s .vimrc ~/
ln -s .screenrc ~/

Опять же, может понадобиться переместить или удалить конфликтующие файлы:

rm ~/.bashrc
ln -s .bashrc ~/

Данный процесс выполняется почти полностью вручную, но это дает возможность более тонко отслеживать файлы, которые нужно активировать на данной машине.

Использование отдельных Git-репозитория и каталога

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

Отличие данного метода от предыдущего состоит в том, что файлы репозитория не нужно проверять во время клонирования, поскольку  они будут загружены непосредственно в домашнеий каталог:

git clone --no-checkout http://git_lab_ip/your_gitlab_user/configs.git

Теперь нужно сказать git распаковать файлы в каталог, расположенный двумя уровнями выше каталога ~/configs/.git (домашнего каталога):

cd configs
git config core.worktree "../../"

Теперь можно тщательно проверить файлы. Опять же, может возникнуть необходимость перезаписать текущие файлы. Это делается путем «перезагрузки» состояния файлов, что возвращает их в состояние, в котором они были в репозитории.

git reset --hard origin/master

Теперь нужные конфигурации действительны на целевой машине.

Итоги

Данное руководство описывает несколько способов контроля версий конфигурационных файлов. Благодаря необходимости  постоянно подтверждать внесенные в файлы репозитория изменения появляется возможность быстро и без особых усилий восстановить самые важные части среды на удаленной машине.