Я управляю множеством серверов, которые охватывают несколько сред (dev, qa, staging и production). Чтобы помочь им управлять, у нас есть несколько репозиториев на локальном веб-сервере для наших приложений (например, app_1_el6, app_2_el7 и т. Д.). Мы также зеркалируем несколько исходных репозиториев, которые предоставляют зависимости для наших пользовательских rpms (например, EL Repo [1], EPEL [2] и т. Д.), Чтобы сократить время загрузки пакета.
В настоящее время задание cron синхронизирует наш локальный репозиторий с вышестоящими репозиториями. Время от времени мы будем загружать обновления, которые вызывают проблемы (например, несовместимость с одним из наших пакетов). Это в конечном итоге вызывает сильную боль, которой я бы хотел избежать.
Что бы я хотел сделать, так это создать своего рода контроль версий для нашего локального зеркала исходных репозиториев. Я хотел бы, например, убедиться, что если новый пакет вводится в репозиторий восходящего потока, который нарушает наши пользовательские rpms, у меня есть способ откатить или каким-то образом изолировать этот пакет. Как лучше всего это сделать?
Майкл Хэмптон сослался на ответ, в котором имена Кателло и Выход в открытый космос, спутниковое RedHat предлагает для этого продукт.
Кателло для Satellite то же, что Fedora для RedHat (согласно этот)
Среды жизненного цикла и просмотры контента то, что вы ищете в Кателло:
Продвижение представления содержимого
Первоначально представление содержимого публикуется в библиотеке как версия 1. Если в других средах есть хосты содержимого, которые хотели бы использовать это представление содержимого, версия представления содержимого должна быть продвинута в эти среды. Например, с учетом представления содержимого «Новое представление содержимого», версия 1 которого была переведена в среду разработки. Любые хосты контента в Dev, прикрепленные к Content View, будут оставаться в версии 1 до тех пор, пока версия 2 не будет опубликована и переведена в среду Dev.
Чтобы расширить ответ fuero, мы используем RedHat Satellite для достижения этой цели. Satellite - это комбинация инструментов с открытым исходным кодом мастер и Кателло. В частности, аспект 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
2017-05-17
производство -> 15.05.2016 (символическая ссылка)
постановка -> 17.05.2016 (символическая ссылка)
Теперь, когда у вас уже есть дедупликация этих данных, вам не будет не хватать места.
Конечно, это увеличивает накладные расходы, связанные с необходимостью поддерживать собственную символическую ссылку, а что нет, но, эй, используя Katello, вам все равно придется щелкать мышью :)
