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

То есть, можно описать свои действия с устройством с помощью кода, а затем его применить, а не использовать интерфейс командной строки или GUI интерфейс. Это существенно уменьшает вероятность ошибки при каких-либо манипуляциях при управлении устройством. В связи с этим возникла другая задача – как отслеживать актуальность и историю изменений в данном коде. Центр информационных технологий РТ стал использовать систему контроля версий, так же как её используют большинство программистов.

Сегодня речь пойдет про Git.

Что такое «система контроля версий» и почему это важно? Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая позже вернуться к определённой версии.

Сам Git является распределенной системой контроля версий (Distributed Version Control System, далее DVCS). В DVCS клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) – они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.

Краткая история Git

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

Ядро Linux – это достаточно большой проект с открытым исходным кодом. Большую часть времени разработки ядра Linux (1991-2002 гг.) изменения передавались между разработчиками в виде патчей и архивов. В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную систему контроля версий BitKeeper.

В 2005 году отношения между сообществом разработчиков ядра Linux и коммерческой компанией, которая разрабатывала BitKeeper, прекратились, и бесплатное использование утилиты стало невозможным. Это сподвигло сообщество разработчиков ядра Linux, в частности, Линуса Торвальдса – создателя Linux, разработать свою собственную утилиту, учитывая знания, полученные при работе с BitKeeper.

Некоторыми целями, которые преследовала новая система, были:

• скорость

• простая архитектура

• хорошая поддержка нелинейной разработки (тысячи параллельных веток)

• полная децентрализация

• возможность эффективного управления большими проектами, такими как ядро Linux (скорость работы и разумное использование дискового пространства).

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

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

Снимки, а не различия

Основное отличие Git от любой другой системы контроля версий, включая Subversion и её собратьев, это подход к работе со своими данными. Концептуально большинство других систем хранят информацию в виде списка изменений в файлах. Эти системы (CVS, Subversion, Perforce, Bazaar и т.д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, основанным на различиях).

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

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

Почти все операции выполняются локально

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

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

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

Целостность Git

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

Git обычно только добавляет данные

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

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

Вот наглядный пример использования Git:

       Последние активные ветки:

Список файлов одной из веток:

Вывод выдержки из конфигурационного файла terraform:

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