publishing_promoting_views

Предупреждение:

Этот модуль чрезвычайно сложен. Я протестировал его наилучшим образом, но не могу гарантировать, что в нем нет ошибок. Поскольку синхронизация репозиториев, публикация и/или продвижение контентных представлений изменят эти объекты в вашем Satellite, я настоятельно рекомендую протестировать его перед использованием в производственной среде. Этот модуль предоставляется "как есть", и я не несу ответственности за любые возможные разрушительные последствия. Пожалуйста, имейте это в виду и тестируйте на снимке вашей системы Satellite или в лаборатории. Большое спасибо :slightly_smiling_face:

Этот модуль публикует и, при желании, продвигает версии как Контентных представлений, так и Композитных Контентных представлений. Он использует сертифицированную коллекцию Red Hat redhat.satellite.

Он был протестирован на следующих версиях Satellite:

• 6.15
• 6.14
• 6.13

Чтобы использовать сертифицированную коллекцию redhat.satellite, вам необходимо быть подписчиком Red Hat. Если у вас нет подписок, вы можете воспользоваться Разработческой подпиской Red Hat, которая предоставляется бесплатно.

Вы также можете использовать коллекцию theforeman.foreman, но вам нужно будет изменить названия модулей с redhat.satellite на theforeman.foreman, - но я этого не тестировал.

Модуль написан так, чтобы он принимал определение переменных Контентных представлений так же, как и модуль redhat.satellite.content_view_publish.

Он также поддерживает Общие переменные ролей для коллекции redhat.satellite. Репозиторий redhat.satellite на GitHub не содержит раздела о том, какие общие переменные ролей могут быть использованы, но их можно проверить в коде.

Общие переменные ролей:

• SATELLITE_SERVER_URL, SATELLITE_SERVER, SATELLITE_URL
• SATELLITE_USERNAME, SATELLITE_USER
• SATELLITE_PASSWORD
• SATELLITE_VALIDATE_CERTS

Использование того же определения Контентного представления, что и в коллекции redhat.satellite, позволяет вам сохранять одно и то же определение YAML для ваших Контентных представлений/Композитных Контентных представлений, хотя я настоятельно рекомендую перейти на более 'современное' определение, которое поддерживают как роли Foreman и Satellite, так и этот модуль.

Чтобы облегчить этот процесс, вы можете запустить этот модуль с тегом convert (--tags convert), который сохранит преобразованный YAML в файл по вашему выбору, что вам также нужно будет указать с помощью переменной sat_convert_yaml_file.

Конвертация выполняется по умолчанию с помощью пользовательского фильтра, который идет в комплекте с этим модулем (list_of_dicts_to_indented_yaml). Этот фильтр, по сути, правильно отступает списки на две пробелы, в отличие от ansible.builtin.to_nice_yaml (что является известным ограничением, решить которое, вероятно, не так легко). Фильтр list_of_dicts_to_indented_yaml также добавляет возможность помещать определенный ключ и значение в начало списка словарей (по умолчанию name).

Обратите внимание, что этот фильтр не предназначен для использования вне этого модуля (поэтому я выбрал худшее имя, какое мог :slightly_smiling_face:). Он будет принимать только список словарей (так как именно это создаст конвертация) и выдаст ошибку для любого другого типа данных. Реализация парсинга YAML для различных типов данных - это отдельная задача. Для этой конкретной задачи, которую решает модуль, поставленный фильтр подходит отлично.

Я настоятельно рекомендую перейти от 'устаревших'[^legacy] определений YAML, поскольку этому модулю нужно, чтобы определение имело определенный формат, чтобы он работал. Не переживайте, он конвертирует его на лету, но это приводит к снижению производительности, так как нужно пройтись по всем определениям Контентных представлений/Композитных Контентных представлений и конвертировать каждое из них. Чем больше ваше определение Контентного представления/Композитного Контентного представления, тем больше будет влияние на производительность.

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

Оставление current_lifecycle_environment, определенного в вашем определении Контентного представления/Композитного Контентного представления, не беспокоит этот модуль, так как этот атрибут никогда не извлекается.

Модуль добавляет некоторые атрибуты в определение satellite_content_views (которые другие модули не будут учитывать):

• patch_day_exclude: С помощью этого вы можете постоянно исключить Контентное представление/Композитное Контентное представление из обработки. Это будут те Контентные представления/Композитные Контентные представления, с которыми вы работаете только в "особых случаях". Например, при выполнении обновления Satellite :slightly_smiling_face:. Этот атрибут является необязательным.
• lifecycle_environments: Список жизненных окружений (также по Контентному представлению/Композитному Контентному представлению) для продвижения Контентного представления/Композитного Контентного представления. Этот список можно сократить (см. раздел переменных ниже) по необходимости. Этот атрибут является необязательным для публикации, но обязательным для продвижения.

Различия с redhat.satellite.content_view_publish

Способ работы этого модуля совершенно отличается от способа работы модуля redhat.satellite.content_view_publish.

Модуль redhat.satellite.content_view_publish максимально простой: Опубликованы все Контентные представления, определенные в satellite_content_views, путем прохождения по этому списку и их публикации. Либо асинхронно (async), либо одно за другим. Никаких излишеств. Не поймите меня неправильно, в этом модуле абсолютно нет ничего плохого. Его работа, вероятно, именно то, что оценят 98% пользователей.

Я один из 2%, которые требуют большего. Я хочу, чтобы модуль динамически решал, какие Контентные представления/Композитные Контентные представления публиковать и куда их продвигать, а также чтобы исключать Контентные представления/Композитные Контентные представления без переопределения satellite_content_views. Более того, я не хочу, чтобы модуль публиковал новую версию Контентного представления/Композитного Контентного представления, если в этом нет необходимости, потому что ничего не изменилось. То же самое касается продвижения. Он должен продвигать только при необходимости и поэтому сообщать статус изменено только если что-то действительно изменилось. Конечно, я также хочу ограничить жизненные окружения, к которым он продвигается, и не переопределять определение в satellite_content_views.

Звучит слишком хорошо, чтобы быть правдой? Ну, в некотором роде. Я реализовал все вышеописанное (и больше) в этом модуле, но это имеет свои недостатки: сложность и скорость выполнения.

Я сделал все возможное, чтобы снизить скорость выполнения до минимума, но она значительно медленнее, чем у redhat.satellite.content_view_publish, хоть и более универсальна.

Чтобы реализовать вышеописанные требования, мне технически нужно извлечь каждое Контентное представление/Композитное Контентное представление по одному из API Satellite и извлечь необходимые данные. Это можно сделать, проходя по всем Контентным представлениям/Композитным Контентным представлениям и выполняя redhat.satellite.resource_info для того Контентного представления/Композитного Контентного представления, по которому в данный момент происходит итерирование.

Или же мы просто извлекаем все Контентные представления/Композитные Контентные представления сразу и фильтруем те, которые не определены в satellite_content_views. Извлечение "большого блока" данных из API Satellite, как правило, быстрее, чем извлечение мелких кусочков по одному. В конце концов, вы, скорее всего, будете публиковать и/или продвигать все Контентные представления/Композитные Контентные представления, которые присутствуют в Satellite и возможно, только несколько из них исключите. Так что в конечном итоге, нам нужно извлечь большинство Контентных представлений/Композитных Контентных представлений, так почему бы не извлекать их все сразу :slightly_smiling_face:.

У меня также есть множество проверок, чтобы убедиться, что как данные, подаваемые в модуль, так и данные, извлекаемые из API Satellite, соответствуют ожидаемым. Я знаю, это не совсем по правилам Ansible, но я хочу быть абсолютно уверенным, что всё соответствует ожиданиям, что предотвратит неожиданные результаты.

Все вышеперечисленные факторы делают модуль очень универсальным, но в то же время очень сложным. Я постарался прокомментировать сложные разделы кода, как только мог, чтобы пользователи этого модуля понимали, что происходит.

Но давайте будем честными. Этот модуль не для новичков в Ansible. Можно даже утверждать, что большая часть кода в этом модуле должна обрабатываться отдельным модулем Ansible, и то, что я делаю с этим модулем, - это чистое безумие. Вы можете быть правы. Но я также думаю, что подобный код не так уж и uncommon, как можно было бы предположить. В конце концов, Ansible отлично соединяет различные системы, и для этого иногда требуется сложность. К сожалению.

Когда стоит подумать о использовании этого модуля

Вы можете подумать о использовании этого модуля вместо официального redhat.satellite.content_view_publish, если:

1. Вы хотите продвигать версии Контентных представлений или версии Композитных Контентных представлений, пока публикуете новую версию Контентного представления/Композитного Контентного представления.
2. Вы хотите продвигать только, без публикации новой версии Контентного представления или Композитного Контентного представления, что является идемпотентным.
3. Вы хотите продвигать, но только в определенные жизненные окружения в идемпотентном режиме.
4. У вас есть необходимость исключать определенные Контентные представления или определенные Композитные Контентные представления из публикации или продвижения во время обычных дней обновлений.
5. Вы не хотите беспокоиться о порядке, в котором вы определяете Контентные представления или Композитные Контентные представления.
6. Вы хотите 'динамически' ограничить жизненные окружения, в которые версии Контентных представлений продвигаются, без переопределения YAML для версий Контентных представлений или Композитных Контентных представлений. Это полезно, если вы обновляете, скажем, каждую неделю. Но по понедельникам вы хотите продвигать только в dev, по вторникам - в qa, а по четвергам - в prod.
7. Вы хотите публиковать и при необходимости продвигать Контентное представление на основе того, что последняя версия Контентного представления старше даты последней синхронизации включенных репозиториев.
8. Вы хотите публиковать и при необходимости продвигать Композитные Контентные представления только тогда, когда включенные Компоненты (версия Контентного представления) были обновлены с момента последней публикации Композитного Контентного представления.
9. Вы хотите убедиться, что перед публикацией все Репозитории:
   • Синхронизированы
   • Завершили последнюю синхронизацию успешно
   • В настоящее время не синхронизируются
10. Вы хотите синхронизировать Репозитории перед публикацией и при необходимости продвижением Контентных представлений/Композитных Контентных представлений.
11. Вы хотите исключить определенные Репозитории из проверки и/или синхронизации.
12. Вы хотите дождаться завершения в данный момент синхронизируемых Репозиториев (когда не запускается через этот модуль) перед публикацией и при необходимости продвижением Контентных представлений/Композитных Контентных представлений.

Почему вы не внесли свой вклад в сертифицированную коллекцию Red Hat/коллекцию Ansible Foreman?

Я могу задать вопрос, стоит ли такой модуль вообще выносить. Теоретически он мог бы быть заменой для существующего модуля content_view_publish, но он значительно сложнее и имеет другой подход к проверке данных (данных от пользователя или API). Этот модуль проверяет всё, чтобы убедиться, что во время дней обновления ничего не сломается, о чем я беспокоюсь больше, чем о скорости выполнения самого модуля. Он также содержит довольно много довольно сложного "безумия" с многострочным YAML-фильтром (хотя, на мой взгляд, очень хорошо прокомментированным), что может не понравиться другим.

Я написал этот модуль в первую очередь для себя, поскольку он нужен мне именно в том виде, в каком он есть. Он может подойти более широкой аудитории, но считает ли это что-то, чем Red Hat или сообщество Foreman хочет заниматься надолго (даже если я подпишусь как поддерживающий этот модуль), это другая история.

Как всегда с Open Source, я не могу гарантировать, что буду поддерживать этот модуль следующие три, пять, десять или более лет, поэтому новый куратор должен быть найден, когда он станет частью коллекции redhat.satellite и/или theforeman.foreman, если я пропаду по любой причине. Хотя я совершенно планирую поддерживать этот модуль еще некоторое время, я определенно не могу этого гарантировать. Если он будет признан слишком сложным для поддержки другими, он, вероятно, не войдет ни в одну из коллекций.

Честно: не держите надежду на это, так как это определенно слишком сложно, к сожалению :pensive:.

Что этот модуль считает 'устаревшим' определением

[^legacy]: Модули redhat.satellite.content_view_publish и также модуль theforeman.foreman.content_view_publish принимают определения Контентных представлений/Композитных Контентных представлений в следующих форматах:

Формат один, который я называю legacy_a

satellite_content_views:
- 'content_view_name1'
- 'content_view_name2'
- 'content_view_name3'
- и так далее.

Формат два, который я называю legacy_b

satellite_content_views:
- content_view: 'content_view_name1'
- content_view: 'content_view_name2'
- content_view: 'content_view_name3'
- и так далее.

Оба формата, на мой взгляд, неудачны.

Как правило, когда необходимо идентифицировать элемент списка по имени, используется атрибут name, а не что-либо, что описывает тип определяемого объекта. Особенно, учитывая, что другой модуль из тех же коллекций (redhat.satellite.content_views или theforeman.foreman.content_views) требует атрибут name.

Не поймите меня неправильно, я не утверждаю, что абсолютно не бывает ситуации, при которой атрибут name не определен, но я бы сказал, что это довольно распространенная практика использовать name вместо чего-либо другого, когда дело касается идентификации объектов по имени.

Формат 'списка строк' (legacy_a) еще более ограничен, так как вы можете предоставить только список Контентных представлений/Композитных Контентных представлений, которые хотите опубликовать. Ничего больше, нет других атрибутов. Я понимаю, почему это может показаться простым способом начать работу с модулем, но, честно говоря, не намного ли сложнее/нее неудобства просто добавить name: перед каждым Контентным представлением/Композитным Контентным представлением? Я так не думаю :slightly_smiling_face:.

Правильный формат для использования

В основном, вы указываете свои Контентные представления/Композитные Контентные представления так:

satellite_content_views:
- name: 'content_view_name1'
- name: 'content_view_name2'
- name: 'content_view_name3'
- и так далее.

Это имеет два преимущества:

• Вы можете использовать одно и то же определение Контентных представлений/Композитных Контентных представлений, что и для модуля (redhat.satellite.content_views).
• Вы избегаете преобразования этого модуля, что значительно улучшает производительность.

Переменные модуля

переменная	значение по умолчанию	требуется	описание
satellite_username	не установлен	true	Имя пользователя для аутентификации через API Satellite
satellite_password	не установлен	true	Пароль пользователя для аутентификации через API Satellite
satellite_server_url	не установлен	true	URL к API Satellite (включая http/s://)
satellite_organization	не установлен	true	Имя организации Satellite, где будут выполняться операции
satellite_content_views	не установлен	true	Контентные представления и Композитные Контентные представления для публикации и, при желании, продвижения
satellite_validate_certs	true	false	Нужно ли проверять сертификаты при подключении к API Satellite
sat_api_timestamp_format	%Y-%m-%d %H:%M:%S %Z	false	Формат, в котором временные метки представлены в API Satellite
sat_async_max_time	3600	false	Время в секундах, в течение которого выполняется каждая асинхронная задача до истечения срока
sat_async_poll_time	0	false	Время опроса каждой асинхронной задачи. Установите в 0 для одновременных публикаций/продвижений
sat_async_retries	1200	false	Как часто следует проверять асинхронную задачу до определения, что она не удалась
sat_async_check_delay	3	false	Задержка между каждой проверкой завершения асинхронной задачи
sat_quiet_assert	true	false	Нужно ли отключать утверждающие операторы
sat_check_content_views_known	true	false	Проверить, известны ли все CV/CCVs, определенные через satellite_content_views
sat_check_synchronizing_repositories	false	false	Нужно ли проверять текущие синхронизируемые репозитории [^check_repositories]
sat_check_successful_repository_synchronization	false	false	Нужно ли проверять, завершилась ли последняя синхронизация репозиториев успешно
sat_check_unsynchronized_repositories	false	false	Нужно ли проверять несинхронизированные репозитории [^check_repositories]
sat_composite_content_view_version_description	Patch day YYYY-mm-dd	false	То же самое, но для версий Композитных Контентных представлений.
sat_composite_content_views_allowed_lifecycle_environments	не установлен	false	Ограничить жизненные окружения, в которые может происходить продвижение. Для CCVs.
sat_content_view_version_description	Patch day YYYY-mm-dd	false	Описание версии Контентного представления. Не описание самого CV.
sat_content_view_kinds	both	false	Какие виды Контентных представлений обрабатывать [^content_view_kinds]
sat_content_views_allowed_lifecycle_environments	не установлен	false	Ограничить жизненные окружения, в которые может происходить продвижение. Для CVs.
sat_excluded_composite_content_views	не установлен	false	Исключить Композитные Контентные представления из любой деятельности
sat_excluded_content_views	не установлен	false	Исключить Контентные представления из любой деятельности
sat_excluded_repositories	не установлен	false	Исключить Репозитории из любой проверки или деятельности
sat_ignore_missing_needs_publish_attribute	false	false	Игнорировать отсутствующий атрибут needs_publish [^needs_publish]
sat_publish_based_on_repository	не установлен	false	Нужно ли публиковать Контентные представления на основе даты синхронизации репозитория
sat_publish_based_on_component	не установлен	false	Нужно ли публиковать Композитные Контентные представления на основе их включенных компонентов
sat_show_summary	true	false	Нужно ли показывать сводную информацию в конце выполнения модуля, в которой перечислены все изменённые объекты
sat_skip_legacy_conversion	false	false	Нужно ли пропустить конвертацию устаревших определений CV/CCV на лету
sat_skip_legacy_assert	false	false	Отключить проверку, если устаревший формат может быть конвертирован
sat_skip_assert	false	false	Нужно ли пропустить утверждения, проверяющие все переменные (assert.yml)
sat_wait_for_repository_synchronization	false	false	Нужно ли ждать завершения синхронизации Репозиториев
sat_synchronize_repositories	false	false	Нужно ли синхронизировать Репозитории перед публикацией
sat_convert_yaml_file	не установлен	false	Файл, в который будет записано преобразованное определение YAML (если запрашивается)
sat_convert_yaml_indent	2	false	Какой отступ (количество пробелов) должен иметь преобразованный YAML
sat_convert_yaml_sort_keys	false	false	Нужно ли лексикографически сортировать ключи при экспорте YAML
sat_convert_yaml_explicit_start	true	false	Нужно ли добавлять явный тег начала YAML (---) в преобразованный файл
sat_convert_yaml_explicit_end	true	false	Нужно ли добавлять явный тег конца YAML (...) в преобразованный файл
sat_convert_yaml_use_custom_yaml_filter	true	false	Нужно ли использовать пользовательский YAML-фильтр, упакованный с этим модулем
sat_convert_yaml_top_key	name	false	Нужно ли поместить конкретный ключ и значение в начало словаря, представляющего CV/CCV

[^check_repositories]: Все проверки репозиториев будут проводиться только для Репозиториев, которые включены в любое Контентное представление (и Композитное Контентное представление, по сути) и специально не исключены через sat_excluded_repositories.

[^content_view_kinds]: Эта переменная может иметь значение content_views, чтобы обрабатывать только Контентные представления, composite_content_views, чтобы обрабатывать только Композитные Контентные представления, или both для обработки обоих. Так вы можете ограничить действия, чтобы относиться к Контентным представлениям или Композитным Контентным представлениям, если это необходимо.

[^needs_publish]: Когда никаких действий не производилось в течение длительного времени (я не знаю точного времени), атрибут needs_publish пустой (null) для Композитных Контентных представлений. По умолчанию этот модуль выдает ошибку о том, что атрибут needs_publish не определен. При включении переменной sat_ignore_missing_needs_publish_attribute, Композитные Контентные представления, у которых отсутствует атрибут needs_publish или у которого значение выставлено в null, будут добавлены к Композитным Контентным представлениям, которые требуют публикации. Это фактически отключает 'публикацию на основе компонентов' для этих Композитных Контентных представлений. Все другие Композитные Контентные представления с существующим и заполненным атрибутом needs_publishing не будут затронуты и будут оцениваться как обычно.

Заметки

• sat_publish_based_on_repository имеет смысл только для Контентных представлений. Поэтому он будет пропущен для Композитных Контентных представлений.
• sat_publish_based_on_component имеет значение только для Композитных Контентных представлений, так как Композитные Контентные представления состоят из одного или нескольких Компонентов (=версии Контентного представления).

Зависимости

Этот модуль использует сертифицированную коллекцию Red Hat redhat.satellite, которая указана в collections/requirements.yml.

Пример плейбука

Обратите внимание, что приведенный ниже пример также содержит Репозитории и Компоненты. Это не требуется и не используется этим модулем. Включение этих просто показывает, что вы можете использовать ту же определение Контентного представления/Композитного Контентного представления для этого модуля, что и для redhat.satellite.content_views.

Сложный пример

---
- hosts: 'localhost'
  gather_facts: false
  roles:
    - name: 'satellite_content_view_publish_promote'
  vars:
    sat_async_max_time: 3900
    sat_async_poll_time: 0
    sat_async_retries: 2000
    sat_async_check_delay: 2
    sat_content_view_version_description: 'Patch day'
    sat_composite_content_view_version_description: 'Patch day'
    satellite_server_url: 'https://satellite.example.com'
    satellite_organization: 'org-example'
    sat_only_promote_content_views: false
    sat_only_promote_composite_content_views: false
    sat_publish_based_on_repository: true
    sat_check_unsynchronized_repositories: true
    sat_wait_for_repository_synchronization: true
    sat_check_successful_repository_synchronization: true
    sat_check_synchronizing_repositories: true
    sat_content_view_kinds: 'both'
    sat_synchronize_repositories: false
    sat_check_content_views_known: true
    sat_publish_based_on_component: true
    satellite_content_views:
      - name: 'cv-rhcdn-base-rhel-8'
        lifecycle_environments:
          - 'lce-default-dev'
          - 'lce-default-prod'

        repositories:
          - name: 'Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - AppStream RPMs 8'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - BaseOS Kickstart 8.9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - AppStream Kickstart 8.9'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-base-rhel-9'
        lifecycle_environments:
          - 'lce-default-dev'

        repositories:
          - name: 'Red Hat Enterprise Linux 9 for x86_64 - BaseOS RPMs 9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs 9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - BaseOS Kickstart 9.3'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - AppStream Kickstart 9.3'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-satellite_6_client-rhel-8'
        patch_day_exclude: true
        repositories:
          - name: 'Red Hat Satellite Client 6 for RHEL 8 x86_64 RPMs'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-satellite_6_client-rhel-9'
        patch_day_exclude: true
        repositories:
          - name: 'Red Hat Satellite Client 6 for RHEL 9 x86_64 RPMs'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'ccv-default-rhel-8'                                                                                                                                               
        lifecycle_environments:
          - 'lce-default-dev'
          - 'lce-default-prod'

        components:
          - content_view: 'cv-rhcdn-base-rhel-8'
            latest: true

          - content_view: 'cv-rhcdn-satellite_6_client-rhel-8'
            latest: true

      - name: 'ccv-default-rhel-9'
        lifecycle_environments:
          - 'lce-default-dev'

        components:
          - content_view: 'cv-rhcdn-base-rhel-9'
            latest: true

          - content_view: 'cv-rhcdn-satellite_6_client-rhel-9'
            latest: true

Лицензия

GPL-2.0-or-later