Как настроить Git для управления конфигурациями сервера

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

Когда на сервере или VPS всё работает как надо, кажется, что конфиги можно просто хранить как есть. Но стоит внести пару правок, и вот уже что-то сломалось, а сделать откат нельзя. Или вдруг нужно повторить ту же настройку на другом сервере, а вы не помните, что и где исправляли. С Git таких проблем не возникает. Обсудим, как подключить Git для управления конфигурацией, сохранить историю изменений и быстро переносить настройки между машинами.

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Арендовать VPS

Что такое Git и зачем он нужен

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

Хранение конфигов в репозитории — это ещё и страховка. Даже если сервер откажет, вы сможете восстановить файлы с удалённой копии. Также Git позволяет синхронизировать настройки между машинами. Репозиторий можно клонировать на другой сервер, а потом просто обновлять его через git pull, чтобы получить последние правки.

Как настроить Git-репозиторий на сервере

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

Сначала нужно установить сам Git. На Ubuntu это делается одной командой, но перед этим лучше обновить список пакетов:

sudo apt update
sudo apt install git

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

git config --global user.name "Имя"
git config --global user.email "you@example.com"

Теперь выберите папку, где хранятся ваши конфигурации. Это может быть /etc, если вы хотите отслеживать системные настройки, или, скажем, /home/user/configs, если всё собрано в отдельной директории. Перейдите туда:

cd /путь/к/каталогу

Чтобы Git начал следить за содержимым папки, инициализируйте репозиторий:

git init

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

Дальше скажите Git, какие файлы нужно сохранить:

git add

Это добавит все текущие файлы в очередь на коммит. Зафиксируйте изменения:

git commit -m "Первый коммит конфигураций"

Теперь у вас есть локальный репозиторий с сохранённой версией конфигов. Но на одном сервере такая копия, как бекап на флешке, лежащей в этом же шкафу. Чтобы быть уверенным в сохранности, создайте удалённый репозиторий на GitHub, GitLab или своём Git-сервере. Подключите его так:

git remote add origin https://ваш-репозиторий.git

А затем отправьте туда изменения:

git push -u origin master

Если у вас основная ветка называется main, используйте её:

git push -u origin main

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

Как убрать секреты из Git и не забыть, что и где лежит

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

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

config.env
*.key
*.pem
secrets.json

Но тут есть нюанс. Если просто игнорировать файл, потом сложно вспомнить, какие переменные там вообще должны быть. Поэтому принято хранить не сами конфиги, а их шаблоны. Например, вы создаёте файл config.env.example, в котором указаны только имена переменных без значений. Этот шаблон кладёте в репозиторий, а настоящий config.env добавляете в .gitignore. Шаблон подсказывает, что должно быть в файле, а секреты остаются только на сервере.

Если нужно передавать переменные окружения безопасно, Git — не единственный инструмент. Есть утилиты вроде git-crypt, которые умеют шифровать отдельные файлы. В истории коммитов будет храниться только зашифрованная версия, а на нужной машине содержимое расшифруется автоматически.

Этот способ хорош для продакшен-настроек и чувствительных данных. Даже если кто-то случайно получит доступ к репозиторию, он не увидит, что внутри. Но в большинстве случаев .gitignore и шаблонов вроде .env.example вполне достаточно.

Как не потеряться в истории изменений

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

Старайтесь писать внятные сообщения к коммитам. Не «обновление» и не «пофиксил конфиг», а конкретно: добавил правило для fail2ban, сменил порт SSH, временно отключил ssl-редирект. Такие сообщения экономят кучу времени, когда нужно быстро разобраться, что происходило и почему всё перестало работать.

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

Если в истории пошла путаница, используйте git log --oneline — команда покажет список коммитов в кратком виде. А git diff поможет сравнить содержимое между версиями, чтобы понять, что именно изменилось. Это как иметь под рукой подробный журнал администратора, только удобнее и нагляднее.

Как перенести настройки на другой сервер и не потерять ничего важного

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

git clone https://ваш-репозиторий.git

В результате вы получаете копию всех конфигов, как они были на основном сервере. Никаких скачиваний по SFTP, пересылок по почте или копипасты через терминал.

Когда на исходном сервере что-то поменялось, например, вы обновили nginx.conf или поправили настройки файрвола, просто заходите на другие машины и запускаете:

git pull

Это подтянет все последние изменения. Так вы синхронизируете конфигурации между серверами, не бегая по ним вручную.

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

Конечно, Git не заменяет полноценные бекапы. Он не поможет, если у вас пропадёт база данных или слетит вся система. Но как способ сохранить и восстановить настройки — это быстрый, понятный и надёжный инструмент, который работает на любом сервере.

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

Читайте в блоге:

• Как настроить кластер Kubernetes на нескольких VPS для запуска масштабируемых приложений
• Развёртывание Node.js-приложения на VPS с PM2: практическое руководство
• Как перенести сайт WordPress на новый VPS без простоев