Способ организации и развертывания выпусков подсистемы связанных компонентов с использованием yum - PullRequest
0 голосов
/ 30 марта 2019

У нас есть распределенная подсистема, состоящая из нескольких компонентов, каждый компонент развертывается в своем собственном RPM-пакете в различных средах RHEL / CentOS.Например, компоненты могут называться:

  • JL_batman,
  • JL_superman и
  • JL_wonderwoman.

И они развернуты какследует:

  • host1:
    • JL_batman
    • JL_wonderwoman
  • host2:
    • JL_superman

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

  • SR1:
    • JL_batman-1.0-hg123.rpm
    • JL_superman-2.7-hg651.rpm
    • JL_wonderwoman-1.1-hg101.rpm
  • SR2:
    • JL_batman-2.0-hg137.rpm
    • JL_superman-2.7-hg651.об / мин
    • JL_wonderwoman-1.1-hg101.rpm
  • SR3:
    • JL_batman-2.0-hg137.rpm
    • JL_superman-2.8-hg655.rpm
    • JL_wonderwoman-1.1-hg101.rpm

Поэтому в каждом выпуске системы обновляются не все пакеты.В настоящее время мы используем символические ссылки в репозитории YUM для пакетов, которые не обновляются между выпусками:

  • SR1:
    • JL_batman-1.0-hg123.rpm
    • JL_superman-2,7-hg651.rpm
    • JL_wonderwoman-1,1-hg101.rpm
  • SR2:
    • JL_batman-2.0-hg137.rpm
    • JL_superman-2.7-hg651.rpm -> ../SR1/superman-2.7-hg651.rpm
    • JL_wonderwoman-1.1-hg101.rpm -> ..SR1 / wonderwoman-1.1-hg101.rpm
  • SR3:
    • JL_batman-2.0-hg137.rpm -> ../SR2/batman-2.0-hg137.rpm
    • JL_superman-2,8-hg655.rpm
    • JL_wonderwoman-1.1-hg101.rpm -> ..SR1 / wonderwoman-1.1-hg101.rpm

Каждый выпусккаталог (SR1, SR2, SR3, ...) является хранилищем YUM.Мы также используем символические ссылки для ссылки на следующие скользящие репозитории:

  • JL-old-stable -> SR1
  • JL-stable -> SR2
  • JL-testing -> SR3

Все это выполняется на сервере репозитория YUM с использованием некоторых собственных сценариев для извлечения пакетов из Jenkins и помещения их в репозиторий JL-тестирования (заменяя там все старые версии),Когда тестирование SR3 завершено и оно переведено в стабильный режим, мы переключаем символические ссылки следующим образом:

  • JL-old-stable -> SR2
  • JL-stable -> SR3
  • JL-тестирование -> SR4

В каждой производственной среде установлен файл .repo yum для JL-old-stable.repo и JL-stable.repo.Тестовые среды также имеют файл JL-testing.repo.Затем yum upgrade 'JL_*' используется в каждой среде, чтобы поддерживать его в актуальном состоянии.Работает нормально, но имеет некоторые проблемы, в основном:

  1. Когда SR3 повышен до стабильного, но нам нужно откатиться к SR2, нам нужно использовать что-то вроде yum --disablerepo='JL-*' --enablerepo='JL-old-stable' downgrade 'JL-*'.

  2. Невозможно легко выполнить откат с SR3 (стабильного) на SR1, кроме установки нового файла JL-SR1.repo и последующего использования yum --disablerepo='JL-*' --enablerepo='JL-SR1' downgrade 'JL-*'.

Есть ли лучший способ?

1 Ответ

0 голосов
/ 30 марта 2019

Я бы вместо этого использовал один RPM, который не предоставляет файлов, но Requires различные другие пакеты с точным контролем версий . «Версия» каждого RPM-файла конфигурации - это просто номер выпуска.

OurConfig_SR_1.noarch требуется:

  • JL_batman = 1,0
  • JL_superman = 2,7
  • JL_wonderwoman = 1.1

OurConfig_SR_2.noarch требуется:

  • JL_batman = 2,0
  • JL_superman = 2,7
  • JL_wonderwoman = 1.1

Затем вы можете иметь их все в одном репо и versionlock OurConfig на машине, пока вы не будете готовы переместить его. Быстрая проверка с помощью rpm -qi OurConfig может сказать вам, чего ожидает эта система. Требование точных версий должно помешать системе SR1 автоматически обновить JL_batman до 2.0 (я, конечно, не проверял!).

...