Как я могу управлять версиями зеркального вышестоящего репозитория?
Я управляю многими серверами, которые охватывают несколько сред (dev, qa, staging и production). Чтобы помочь им управлять, у нас есть несколько репозиториев на локальном веб-сервере для наших приложений (например, app_1_el6, app_2_el7 и т. Д.). Мы также отражаем несколько исходящих репозиториев, которые предоставляют зависимости для наших пользовательских rpms (например, EL Repo [1], EPEL [2] и т. Д.), Чтобы сократить время загрузки пакета.
В настоящее время задание cron синхронизирует наше локальное хранилище с вышестоящими репозиториями. Время от времени мы выпускаем обновление, которое вызывает проблему (например, несовместимость с одним из наших пакетов). Это в конечном итоге вызывает много боли, которую я хотел бы избежать.
То, что я хотел бы сделать, - это создать какой-то контроль версий для нашего локального зеркала репозиториев. Я хотел бы, например, убедиться, что если в репозитории upstream будет представлен новый пакет, который нарушает наши пользовательские rpms, у меня есть способ откатить или каким-то образом изолировать этот пакет. Какой лучший способ пойти по этому поводу?
3 ответа
Майкл Хэмптон сослался на ответ, в котором названы Katello и Spacewalk. Satellite - продукт, который RedHat предлагает для этого.
Katello для Satellite, что Fedora для RedHat (согласно этому)
Среды жизненного цикла и представления контента - это то, что вы ищете в Katello:
Продвижение просмотра контента
Изначально представление контента публикуется в библиотеке как версия 1. Если в других средах есть хосты контента, которые хотели бы использовать это представление контента, версию представления контента необходимо будет продвигать в эти среды. Например, с учетом представления контента "Представление нового контента", версия 1 которого была переведена в среду разработки. Любые хосты контента в Dev, присоединенные к представлению контента, будут оставаться в версии 1, пока версия 2 не будет опубликована и переведена в среду Dev.
http://www.katello.org/docs/2.3/user_guide/content_views/promote_content_view2.png
http://www.katello.org/docs/2.3/user_guide/content_views/promote_content_view3.png
Чтобы расширить ответ fuero, мы используем RedHat Satellite для достижения этой цели. Satellite представляет собой сочетание инструментов с открытым исходным кодом Foreman и Katello. В частности, именно аспект Katello обеспечивает "управление жизненным циклом".
В Katello вы определяете исходные репозитории для синхронизации из репозиториев yum, марионеточных кузниц, git-серверов и т. Д. Затем вы синхронизируете контент в Библиотеке и "продвигаете" его в различных средах. Типичным примером будет "Библиотека -> Dev -> Тест -> Производство".
Некоторое время назад был хороший разговор на одной из конференций Puppet, где некоторые разработчики представили демо-версию Katello/Foreman. Ссылка на YouTube.
Стоит отметить одну вещь: в настоящее время мы пытаемся решить проблему двоичного распределения и отслеживания, которую Кейтелло не решает. Под этим я подразумеваю, что у нас есть набор модулей Puppet и связанных с ними RPM / двоичных файлов, но Katello не предоставляет способа "сделать снимок" для экспорта в другую систему. Katello будет сохранять статичное "представление" об этих вещах, но нет никакого способа подтвердить, что в этом представлении - я не могу сказать клиенту, что у них есть "версия X" системы, и я не могу подтвердить, что представление, которое они представляют Использую точно так же, как у меня. Все зависит от того, когда они синхронизировались и что было в репо в то время.
В настоящее время мы рассматриваем такие инструменты, как Nexus/Artifactory, чтобы обеспечить эту функциональность, поэтому вы можете захотеть взглянуть и на них.
Ну, вы можете легко настроить свою собственную систему для этого.
Уже есть инструмент под названием reposync, который вы можете использовать для синхронизации всего репозитория.
Теперь единственное недостающее звено - как не загромождать свое дисковое пространство вещами.
Немного перечитайте дедупликацию данных с помощью brtfs (например, как это было объединено в основном ядре, проверьте этот проект) / Вы можете использовать любую другую файловую систему с дедупликацией данных, такую как Lessfs /
Оттуда вы можете настроить пространство хранения данных, используя любую файловую систему, которая позволяет дедупликацию, а затем использовать cronjob для выполнения синхронизации, но на этот раз отметьте время новой синхронизации, поэтому предположим, что вы легко можете получить следующую структуру:
2016-05-15
2016-05-16
2017-05-17
производство -> 2016-05-15 (символическая ссылка)
постановка -> 2016-05-17 (символическая ссылка)
Теперь, поскольку у вас уже есть дедупликация этих данных, вам не будет не хватать места.
Конечно, это добавляет накладных расходов на необходимость поддерживать ваши собственные символические ссылки, а что нет, но с помощью Katello вам все равно придется кликать вокруг:)