Как может я управление версиями зеркальный восходящий репозиторий?
Я управляю многими серверами, которые охватывают несколько сред (dev, обеспечение качества, подготовка и производство). Чтобы помочь управлять ими, у нас есть несколько репозиториев на локальном веб-сервере для наших приложений (например, app_1_el6, app_2_el7, и т.д.). Мы также зеркально отражаем несколько восходящих repos, которые обеспечивают зависимости для нашего пользовательского rpms (например, EL Repo [1], EPEL [2], и т.д.) для сокращения времени загрузки пакета.
В настоящее время задание крона синхронизирует наше локальное с восходящими репозиториями. Время от времени мы вытянем в обновлении, которое вызывает проблему (например, несовместимость с одним из наших пакетов). Это заканчивает тем, что вызвало много боли, которой я хотел бы избежать.
То, что было бы я любить делать, создают своего рода управление версиями для нашего локального зеркала восходящего потока repos. Я хотел бы удостовериться, например, что, если новый пакет представлен в восходящем потоке repo, который повреждает наш пользовательский rpms, который у меня есть способ откатывать или так или иначе изолировать тот пакет. Что лучший способ состоит в том, чтобы пойти об этом?
Майкл Хэмптон сослался на ответ, который называет Katello и Spacewalk , Satellite - продукт, который RedHat предлагает для этого.
Katello для Satellite то же, что Fedora для RedHat (согласно this )
Среда жизненного цикла и представления содержимого - это то, что вы ищете в Katello:
Представление содержимого
Изначально представление содержимого публикуется в библиотеке как версия 1. Если в других средах есть хосты содержимого, которые хотели бы использовать это представление содержимого, версия представления содержимого должна быть продвинута в эти среды. Например, с учетом представления содержимого «Новое представление содержимого», версия 1 которого была переведена в среду разработки. Все хосты контента в Dev, прикрепленные к Content View, будут оставаться в версии 1 до тех пор, пока версия 2 не будет опубликована и продвинута в среду Dev.
Чтобы расширить ответ fuero, мы используем RedHat Satellite для достижения этой цели. Satellite представляет собой комбинацию инструментов с открытым исходным кодом Foreman и Katello .В частности, аспект Katello - это то, что обеспечивает это «Управление жизненным циклом».
В Katello вы определяете вышестоящие репозитории для синхронизации: репозитории yum, марионеточные кузницы, серверы git и т. Д. Затем вы синхронизируете контент с библиотекой и продвигать его через различные среды. Типичным примером может быть «Библиотека -> Разработка -> Тест -> Производство».
Некоторое время назад на одной из конференций Puppet был хороший доклад, где некоторые разработчики представили демо Katello / Foreman. Ссылка на YouTube .
Одно замечание: в настоящее время мы пытаемся решить проблему двоичного распределения и отслеживания, которую Katello не решает. Я имею в виду, что у нас есть набор модулей Puppet и связанные с ними RPM / двоичные файлы, но Katello не предоставляет возможности «сделать снимок» для экспорта в другую систему. Katello будет сохранять статическое «представление» об этих вещах, но нет никакого способа подтвердить, что находится в этом представлении - я не могу сказать заказчику, что у него есть «версия X» системы, и я не могу подтвердить, что представление Используются точно такие же, как у меня. Все зависит от того, когда они синхронизировались и что было в репозиториях в то время.
В настоящее время мы рассматриваем такие инструменты, как Nexus / Artifactory, чтобы обеспечить эту функциональность, так что вы, возможно, захотите взглянуть и на них.
Что ж, вы можете легко настроить свою собственную систему для этого.
Уже существует инструмент под названием reposync, который можно использовать для синхронизации всего репозитория.
Теперь единственное недостающее звено - как не загромождать дисковое пространство вещами.
Сделайте небольшое чтение по дедупликации данных с помощью brtfs (например, когда он был объединен в основном ядре, проверьте этот проект ) / Вы можете использовать любую другую файловую систему с дедупликацией данных, например Lessfs /
Оттуда вы можете настроить пространство для хранения данных, используя любую файловую систему, которая допускает дедупликацию, а затем использовать задание cron для синхронизации, но на этот раз отметьте время новой синхронизации, так что, допустим, вы можете легко получить следующую структуру:
2016-05-15
2016-05-16
17 мая 2017 г.
производство -> 15.05.2016 (символическая ссылка)
постановка -> 17.05.2016 (символическая ссылка)
Теперь, поскольку у вас уже есть дедупликация этих данных, вам не будет не хватать места.
Конечно, это добавляет накладные расходы, связанные с необходимостью поддерживать вашу собственную символическую ссылку и многое другое, но, используя Katello, вам все равно придется щелкать мышью: )