Pull to refresh

Comments 2

Слишком сложная штука даже на уровне чтения статьи о ней. А про использование - вообще молчу, так это ад кромешный.

Связка Katello и Foreman брендированные под Redhat называются Redhat Satelite. Тот же интерфейс, с теми же возможностями, просто логотип от Redhat висит вместо Foreman. Без пол-литра не разберёшься, т.к. всё очень запутано и нелогично.

У нас был именно вариант Redhat Satelite, который был установлен и настроен вендором (RedHat) и использовался для 2-х целей:

1. Правильное лицензирование RedHat.

2. Управление обновлениями.

Проблем огромное количество.

1. Серверы должны быть специально добавлены в эту шляпу, чтобы с неё обновляться. На серверы для этого ставится агент katello. Периодически оно перестаёт работать, поэтому надо процесс сопряжения повторять заново для "отвалившихся" серверов.

2. Если сервер удалён из инфраструктуры, но остался в Redhat Satelite, то его сложно оттуда удалить. Из-за этого со временем там остаются мёртвые души, которые мешают работать и, например, выполнять групповые операции.

2. Периодически в Redhat Satelite там что-то под капотом ломалось и весь процесс управления обновления для всей компании становился на паузу, пока гуру админы не исправляли косяки самого Redhat Satelite. А в эпоху DevOps и микросервисов желающих копаться в таком исполинском го...не откровенно немного.

3. Вариант разделения обновлений на эпохи\исторические срезы хорош лишь на бумаге. В реальности всем нужны лишь самые последние обновления. Когда серверов много, то приходилось держать по 5-6 разных эпох для разных групп серверов, что очень неудобно.

4. Анальная привязка к манифестам и сертификатам RedHat доставляла также много головной боли. Изменилось что-то в лицензиях или их распределении на портале redhat (access.redhat.com)? Формируй новый файлик и заливай его в свой Satelite руками и молись, чтобы у тебя там ничего не поломалось. Сами манифеста на портале redhat тоже не всегда корректно формируются, поэтому иногда по 2 раза приходилось повторять процедуру.

Ещё до санкций 2022 года мы отказались от RedHat Satelite и перешли на свои локальные репозитории. Это сэкономило нам сотни часов и кучу нервных клеток.

В 2022 году начались санкции, к которым присоединилась компания Redhat, и все локальные порталы RedHat Satelite перестали нормально работать, т.к. они периодически требовали синхронизации с порталом redhat (access.redhat.com) для обновления манифестов. Так что мы удачно спрыгнули и не особо пострадали от санкций, хотя жалко корпоративных денег, т.к. они были заплачены на 3 года вперёд, а Redhat просто нас кинул, не вернув нам ни копейки.

Довольно резко, но в целом, справедливо, хотя я всё-таки по пунктам пройдусь для проформы:

  1. Агент не нужен (и депрекейтнут) уже несколько лет - сейчас используется remote execution для этого. В 6.15 (вышел недавно) так его полностью выпилили.

  2. Клин-ап скрипт там на 4-5 строк с hammer-ом

  3. В реальности очень разношёрстные инфраструктуры есть. А если у вас ещё есть SAP тулзы для RHEL вместо SLES - так там без этого никак, поставил ластовый kernel - словил дохлый апп.

  4. Слышал о таком, но у нас уже несколько лет ансибл плейбук на "что-то-типа-satellite-configuration-as-a-code" обновляет все манифесты через theforeman.foreman.redhat_manifest и theforeman.foreman.subscription_manifest. Я знаю, что звучит "у меня тоже нога, но не болит", однако работает.

С тем, что продукт очень запутанный и в нём нагромождено много всего - согласен, но у нас много используется из этого тулкита - ремедиейшоны, эррата-чеки, капсули, чтобы траффик зря не гонять между крупными узлами сети. Мы через него и 3rd-party репы (кастомные тулзы) проксируем и репы, которые не только для RHEL, но и для другого дистра. До перехода на пакер несколько лет назад, на нём образы ещё собирали.

Sign up to leave a comment.

Articles