sscheib.satellite_publish_promote_content_views
satellite_content_view_version_publish_promote
提前警告:
这个角色非常复杂。我尽力进行了测试,但不能保证没有错误。由于存储库同步、内容视图发布和/或提升操作会改变您在卫星中的这些对象,因此我建议您在生产环境中使用之前先进行测试。该角色以“原样”提供,可能会有潜在的灾难性后果,我对此不承担责任。请记住这一点,并在您的卫星上或者实验室系统上进行快照测试。非常感谢 :slightly_smiling_face:
这个角色发布并可选择提升内容视图和复合内容视图版本,使用红帽认证的集合 redhat.satellite
。
该角色已在以下卫星版本上进行了测试:
- 6.15
- 6.14
- 6.13
要使用红帽认证的集合 redhat.satellite
,您需要成为红帽订阅用户。如果没有任何订阅,可以使用红帽提供的开发者订阅,此服务没有费用。
您也可以使用上游集合 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 定义,尽管我强烈建议将 YAML 定义迁移到更“现代”的定义,Foreman、卫星角色和本角色均可接受。
为简化此过程,您可以使用 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 解析本身就是一项复杂的工作。对于该角色的特定用例,提供的过滤器做得很好。
我强烈建议迁移出“遗留”YAML 定义的原因,是该角色需要以特定方式定义,以便正常工作。别担心,它会动态转换,但这会导致性能下降,因为需要遍历所有内容视图/复合内容视图定义并转换每个。如果内容视图/复合内容视图定义越大,性能影响越大。
该角色唯一不接受作为参数的内容是 current_lifecycle_environment
。该角色采取不同的方法,动态计算每个内容视图版本/复合内容视图版本的当前生命周期环境,因此不需要该参数。
在内容视图/复合内容视图定义中保留 current_lifecycle_environment
不会影响该角色,因为永远不会检索该属性。
该角色向 satellite_content_views
的定义添加了一些属性(其他角色不会关心):
patch_day_exclude
:借此,您可以永久将某个内容视图/复合内容视图排除在处理之外。这些通常是您仅在“特殊场合”处理的内容视图/复合内容视图。例如,当执行卫星更新时 :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
的情况下排除某些内容视图/复合内容视图。此外,我不希望该角色在不需要的情况下发布新的内容视图/复合内容视图版本,因为没有任何变化。提升也是如此。只有在必要时才应提升,因此仅在确实发生变化时报告 changed
状态。当然,我还希望限制可以提升的生命周期环境,而不是重新定义 satellite_content_views
中的定义。
听起来好得令人难以置信?好吧,有点。我已经在这个角色中实现了上述所有功能(还有更多),但这也有其缺点:复杂性和执行速度。
我尽力将执行速度降低到最低,但它显著比 redhat.satellite.content_view_publish
慢,但也更灵活。
为了实现上述要求,从技术上讲,我需要从卫星 API 中逐一检索每个内容视图/复合内容视图并提取所需数据。这当然可以在遍历所有内容视图/复合内容视图并对当前被遍历的内容视图/复合内容视图执行 redhat.satellite.resource_info
的同时完成。
或者,我们可以一次性检索所有内容视图/复合内容视图,并筛选出未在 satellite_content_views
中定义的内容。根据我的经验,从卫星 API 检索一大块数据通常比逐个检索更快。毕竟,您最有可能发布和/或提升卫星中存在的所有内容视图/复合内容视图,并可能只排除一小部分。因此,最终,我们无论如何都需要检索大多数内容视图/复合内容视图,那么为何不一次 性检索它们呢 :slightly_smiling_face:。
我还设置了大量检查,以确保提供给角色和从卫星 API 检索的数据都是预期的。我知道,这在 Ansible 中并不常见,但我想确保一切尽可能是预期的,从而防止意外结果。
上述所有内容使得该角色非常灵活,但同时也非常复杂。我已尽力在代码中对此复杂部分进行注释,以确保使用该角色的用户能够理解发生了什么。
但说实话。这个角色并不适合 Ansible 初学者。您甚至可以争辩说,该角色中的大多数代码应该由专门的 Ansible 模块处理,我所做的事情简直就是疯狂。您可能是对的。但我认为这种代码并不如人们想象的那样不常见。毕竟,Ansible 在连接不同系统方面表现出色,而为了实现这一目标,有时需要复杂性。不幸的是。
何时考虑使用此角色
当您想发布新内容视图版本/复合内容视图版本时,可以考虑使用此角色,而不是官方的 redhat.satellite.content_view_publish
:
- 您希望在发布新内容视图版本/复合内容视图版本时提升内容视图版本或复合内容视图版本。
- 您希望仅提升,而不发布新内容视图版本或复合内容视图版本,这种操作是幂等的。
- 您希望提升,但仅提升到定义的生命周期环境,以幂等的方式。
- 您需要在常规修补日排除某些内容视图或某些复合内容视图的发布或提升。
- 您不想担心定义内容视图或复合内容视图的顺序。
- 您希望“动态”限制内容视图版本提升的生命周期环境,而无需重新定义内容视图版本或复合内容视图版本的 YAML。这在您每周修补时非常有用。例如,星期一您只想提升到
dev
,星期二提升到qa
,星期四提升到prod
。 - 您希望基于最新内容视图版本是否早于包含的存储库的最后同步日期,发布并可选择提升内容视图。
- 您仅希望在包含的组件(内容视图版本)自上次发布以来有更新时发布和可选择提升复合内容视图。
- 您希望在发布之前确保所有存储库:
- 已同步
- 上一次同步成功完成
- 当前未在同步中
- 您希望在发布内容视图/复合内容视图之前同步存储库并可选择提升。
- 您希望排除某些存储库的检查和/或同步。
- 您希望在发布内容视图/复合内容视图之前,等待当前正在同步的存储库(当未通过此角色调用时)完成。
为什么没有对红帽认证的集合/上游 Foreman Ansible 集合做出贡献?
我可能会问,这样的角色是否值得贡献。从理论上讲,它可能是现有角色 content_view_publish
的替代品,但它复杂得多,并且在验证数据(用户提供或 API)方面采用了不同的方法。该角色验证所有内容,以确保在修补日不会出错,这在我看来比角色自身的执行速度更为重要。
它还包含相当多的复杂的 YAML 多行过滤器“疯狂”(虽然后我认为注释得很好),这可能是其他人不喜欢的地方。
我主要为自己编写此角色,因为我确实需要它的这种实现。它可能适合更广泛的受众,但红帽或 Foreman 社区是否愿意在长期内维护它(即使我为这个特定角色注册为维护者),这是另一个故事。
正如开源一样,我不能保证会在接下来的三年、五年、十年或更长时间内维护此角色,因此如果我因为某种原因消失,需要找到一个新维护者,以将其纳入 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'
- etc.
格式二,我称之为 legacy_b
satellite_content_views:
- content_view: 'content_view_name1'
- content_view: 'content_view_name2'
- content_view: 'content_view_name3'
- etc.
在我看来,这两种格式都不是很理想。
通常,当需要通过名称识别列表元素时,会使用属性 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'
- etc.
这有两个好处:
- 您可以使用与角色 (
redhat.satellite.content_views
) 相同的内容视图/复合内容视图定义 - 您避免了此角色的转换,从而大大提高了性能
角色变量
变量 | 默认值 | 是否必需 | 描述 |
---|---|---|---|
satellite_username |
未设置 | 是 | 用于通过卫星 API 身份验证的用户名 |
satellite_password |
未设置 | 是 | 用于通过卫星 API 身份验证的用户密码 |
satellite_server_url |
未设置 | 是 | 卫星 API 的 URL(包括 http/s://) |
satellite_organization |
未设置 | 是 | 要在其内执行操作的卫星组织名称 |
satellite_content_views |
未设置 | 是 | 要发布并可选择提升的内容视图和复合内容视图 |
satellite_validate_certs |
true |
否 | 连接卫星 API 时是否验证证书 |
sat_api_timestamp_format |
%Y-%m-%d %H:%M:%S %Z |
否 | 卫星 API 中时间戳表示的格式 |
sat_async_max_time |
3600 |
否 | 每个异步任务运行的最大超时时间(秒) |
sat_async_poll_time |
0 |
否 | 每个异步任务的轮询时间。设置为 0 以实现并发发布/提升行动 |
sat_async_retries |
1200 |
否 | 应检查异步任务的频率,直到确定为 failed |
sat_async_check_delay |
3 |
否 | 每次检查异步任务是否已完成之间的延迟 |
sat_quiet_assert |
true |
否 | 是否静默断言语句 |
sat_check_content_views_known |
true |
否 | 检查 satellite_content_views 中定义的所有 CV/CCV 是否为卫星所知 |
sat_check_synchronizing_repositories |
false |
否 | 是否检查当前正在同步的存储库 [^check_repositories] |
sat_check_successful_repository_synchronization |
false |
否 | 是否检查存储库的上一次同步是否成功 |
sat_check_unsynchronized_repositories |
false |
否 | 是否检查未同步的存储库 [^check_repositories] |
sat_composite_content_view_version_description |
Patch day YYYY-mm-dd |
否 | 与上面相同,但适用于复合内容视图版本。 |
sat_composite_content_views_allowed_lifecycle_environments |
未设置 | 否 | 限制可以提升的生命周期环境,对于 CCV。 |
sat_content_view_version_description |
Patch day YYYY-mm-dd |
否 | 内容视图版本的描述,而不是内容视图本身的描述。 |
sat_content_view_kinds |
both |
否 | 要处理的内容视图类型 [^content_view_kinds] |
sat_content_views_allowed_lifecycle_environments |
未设置 | 否 | 限制可以提升的生命周期环境,对于 CV。 |
sat_excluded_composite_content_views |
未设置 | 否 | 从任何活动中排除复合内容视图 |
sat_excluded_content_views |
未设置 | 否 | 从任何活动中排除内容视图 |
sat_excluded_repositories |
未设置 | 否 | 从任何活动/检查中排除存储库 |
sat_ignore_missing_needs_publish_attribute |
false |
否 | 忽略缺失的 needs_publish 属性 [^needs_publish] |
sat_publish_based_on_repository |
未设置 | 否 | 是否基于存储库同步日期发布内容视图 |
sat_publish_based_on_component |
未设置 | 否 | 是否基于所包含组件发布复合内容视图 |
sat_show_summary |
true |
否 | 是否在角色执行结束时显示汇总,列出所有变更对象 |
sat_skip_legacy_conversion |
false |
否 | 是否跳过遗留 CV/CCV 定义的实时转换 |
sat_skip_legacy_assert |
false |
否 | 禁用检查遗留格式是否可以转换的断言 |
sat_skip_assert |
false |
否 | 是否跳过检查所有变量(assert.yml )的断言语句 |
sat_wait_for_repository_synchronization |
false |
否 | 是否等待存储库完成同步 |
sat_synchronize_repositories |
false |
否 | 是否在发布之前同步存储库 |
sat_convert_yaml_file |
未设置 | 否 | 如果请求,转换后的 YAML 定义将写入的文件 |
sat_convert_yaml_indent |
2 |
否 | 转换后的 YAML 应采用的缩进(空格数) |
sat_convert_yaml_sort_keys |
false |
否 | 导出 YAML 时是否按字母顺序排序键 |
sat_convert_yaml_explicit_start |
true |
否 | 转换文件中是否添加显式 YAML 开头标签(--- ) |
sat_convert_yaml_explicit_end |
true |
否 | 转换文件中是否添加显式 YAML 结束标签(... ) |
sat_convert_yaml_use_custom_yaml_filter |
true |
否 | 是否使用本角色捆绑的自定义 YAML 过滤器 |
sat_convert_yaml_top_key |
name |
否 | 是否将特定的键值放在表示 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
仅对复合内容视图相关,因为复合内容视图由一个或多个组件(=内容视图版本)组成。
依赖关系
此角色使用红帽认证的集合 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: '补丁日'
sat_composite_content_view_version_description: '补丁日'
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
Publishes and optionally promotes Content View versions and Composite Content View versions.
ansible-galaxy install sscheib.satellite_publish_promote_content_views