Коллеги, а кто как решает такую задачу:Есть, скажем, два окружения (в AWS, если это важно): UAT и Prod. В каждом - пачка линукс-серверов (виртуалки, скажем, redhat- и debian-based). Требуется накатывать системные обновления на прод только после установки их на уат и тестирования, что ничего не посыпалось. Между установкой на уат и аппрувом установки на прод пройдет какое-то время, так что "yum update", выполненный на проде, с большой вероятностью установит не [только] те обновления, что ставились на уате, а надо обновить только то, что протестировано.
> Коллеги, а кто как решает такую задачу:
> Есть, скажем, два окружения (в AWS, если это важно): UAT и Prod.
> В каждом - пачка линукс-серверов (виртуалки, скажем, redhat- и debian-based). Требуется
> накатывать системные обновления на прод только после установки их на уат
> и тестирования, что ничего не посыпалось. Между установкой на уат и
> аппрувом установки на прод пройдет какое-то время, так что "yum update",
> выполненный на проде, с большой вероятностью установит не [только] те обновления,
> что ставились на уате, а надо обновить только то, что протестировано.Снимайте с тестового окружения список установленного и ставьте по этому списку конкретные версии.
Можно с тестового на прод продублировать кэш пакетов.
Можно организовать собственные репозитории с жизненным циклом дев-тест-уат-прод через "pulp". Он умеет и деб и рпм и ещё всякое.
А на серверах в качестве репозиториев оставляешь только адрес своего pulp сервера.
На dev будут всегда свежие пакеты, на остальных репозитории будут обновляться только по команде.