2024年 6月 27日Nuno Martins
Automation and management自动化和管理 Linux Migration迁移
CentOS Linux 7的生命周期即将结束，更新将于2024年6月30日结束。这一即将到来的最后期限意味着安全更新和维护的结束，为继续依赖过时操作系统的组织带来了重大风险。需要升级到更新且受支持的平台，如Red Hat Enterprise Linux（RHEL），以保持最新的安全状态和持续的功能。
这些系统可能在您组织的IT基础设施中发挥关键作用，迁移这些系统并非易事。红帽Ansible自动化平台可以帮助简化和自动化此流程，降低复杂性，同时实现可扩展性，并能够协调对周围基础设施的更改，以支持迁移。
在本文中，我将探讨使用Ansible Automation Platform在整个组织中大规模推动这种迁移的可能性，以及实现这一目标所需的步骤。
从CentOS Linux迁移到RHEL
当然，登录到CentOS Linux系统并启动Convert 2 RHEL命令行过程非常容易。但是，如何在多个系统中实现这一点呢？那么可能存在的所有基础设施依赖性呢？
使用Ansible Automation Platform进行此过程可帮助您解决规模和依赖关系，同时允许您为迁移构建逻辑工作流。还有什么比大规模转化更强大的呢？大规模整治！我们可以自动修复所有这些阻断剂。
我们经常将Ansible Automation Platform称为简单而强大的平台，但它真正的强大功能是覆盖多个领域和用例。我们可以自动化迁移过程，但我们也可以使用多域方面来解决基础设施和平台依赖性。
让我们来看一个典型的系统示例，我们现在希望将其迁移到RHEL。我有一组应用程序服务器托管我的流应用程序。这些系统并不是孤立运行的，可能会有防火墙、负载平衡甚至与数据库的连接。还可能需要其他的前期工作。我可能需要：
- Update dependent systems 更新依赖系统
- 备份数据或快照系统
- 在我们的监控解决方案中从通知中删除系统
- 在我们开始之前，在我们的ITSM中打开服务票证
有了我们需要做的一切操作知识，我们可以构建我们的Ansible Playbook并标准化流程以实现一致性。使用Ansible自动化平台，通过提供红帽Ansible Lightspeed（我们用于剧本创建的生成式AI），我们可以实现终极“ops-life”破解。我们可以利用我们的知识，让Ansible Lightspeed帮助我们更快地构建剧本，同时遵循最佳实践。
一旦我们创建了我们的内容，我们就可以使用自动化控制器来构建自动化工作流，并在我们继续自动化实际的Convert2RHEL流程之前逻辑地绘制流程。
在我们继续之前，我想指出这个工作流的一个关键组成部分：自动化系统快照的能力。这对于CentOS Linux到RHEL的迁移和RHEL的自动升级都很重要。当我们讨论RHEL升级时，我将向您展示一个Ansible验证的infra.lvm_snapshots内容的示例。
那么，转换我们系统的实际过程是怎样的呢？通过我们的Ansible自动化平台订阅，我们可以访问Ansible验证的内容，这些内容提供专家，固执己见的自动化内容，所有内容都位于console.redhat.com上的Ansible自动化中心。
我们将使用infra.convert2rhel集合开始。这个集合提供了我们可以用来使用Convert 2 RHEL框架执行转换的角色。使用Ansible验证内容中提供的示例剧本，我可以简单地将其添加到我的工作流程中，并在完成前期工作任务后启动迁移。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
--- - name: Convert CentOS Linux to RHEL hosts: centos strategy: free become: true force_handlers: true vars: rhsm_username: "{{ rhsm_username }}" rhsm_password: "{{ rhsm_password }}" rhsm_org: "{{ rhsm_org }}" rhsm_activation_key: "{{ rhsm_activation_key }}" tasks: - name: Perform OS conversion ansible.builtin.import_role: name: infra.convert2rhel.convert |
如果你看了示例剧本，注意策略的使用是很重要的。如果您不熟悉这一点，这使我们能够控制如何跨主机执行任务。在我们的示例中，我们使用strategy：free -允许任务尽快执行而无需等待其他主机，并且它独立运行每个主机。这是大规模升级多台机器的理想选择。
一旦我们迁移系统，我们就可以利用Ansible Automation Platform自动化测试和检查端口和配置，作为迁移到RHEL工作流程的最后一步。
“RHEL-come” to Enterprise Linux!
“RHEL-来”到企业Linux！
一旦我们的CentOS Linux系统已经迁移，我们现在将在RHEL 7。建议使用类似的过程升级到RHEL 8-我们使用LEAPP升级工具框架来帮助我们。Red Hat还为RHEL 7系统提供延长生命周期支持（ELS）附加订阅，有关更多信息，请参阅宣布为Red Hat Enterprise Linux 7提供长达4年的延长生命周期支持（ELS）。
与Convert 2 RHEL一样，红帽也为infra. leapp提供了经Ansible验证的内容。infra.leapp内容包含帮助我们进行预升级步骤的角色，例如生成预升级报告、常见问题/抑制因素的补救角色以及升级我们的系统。
当我们在RHEL的主要版本之间升级时，我们通常使用LEAPP来评估系统并创建升级前报告。LEAPP将收集数据，并提供关于潜在问题/抑制因素的报告，以及解决这些问题的可能建议。 虽然我们可以使用Ansible Role来修复LEAPP发现的常见问题，但是，第三方依赖关系或某些配置更改可能需要单独解决。
步骤1：评估您的系统
我们可以再次求助于Ansible Automation Platform，通过解决报告中的问题，构建补救行动手册，并将大规模的更改应用于我们想要升级的系统，来简化我们系统的补救过程。此外，如果我们不确定所需的任务，我们可以利用Ansible Lightspeed来生成一些补救措施。
示例：我们的系统有一个root远程登录的抑制器，我们使用Ansible Lightspeed来构建修复：
步骤2：触发升级：
通过使用自动化网格（Ansible自动化平台的一部分）等技术，我们可以大规模部署具有工作流程的剧本，甚至在全球范围内部署，甚至在地球仪。
使用我们的Ansible验证的内容，我们可以创建我们的LVM的快照，这样我们就可以在下一个升级步骤中恢复失败。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
--- - name: Create/revert/remove/check LVM snapshots of node hosts: "{{ rhel_inventory_group | default(omit) }}" become: yes environment: LANG: en_US.UTF-8 LC_ALL: en_US.UTF-8 TERM: linux tasks: - ansible.builtin.set_fact: snapshot_create_set_name: "{{ snapshot_set_name }}" snapshot_remove_set_name: "{{ snapshot_set_name }}" snapshot_revert_set_name: "{{ snapshot_set_name }}" - name: "Execute snapshot check" ansible.builtin.include_role: name: "infra.lvm_snapshots.snapshot_create" vars: snapshot_create_check_only: true # Additional snapshot_* vars provided via AAP2 job template and associated surveys when: lvm_snapshots_action == "check" - name: "Execute snapshot {{ lvm_snapshots_action }}" ansible.builtin.include_role: name: "infra.lvm_snapshots.snapshot_{{ lvm_snapshots_action }}" # Additional snapshot_* vars provided via AAP2 job template and associated surveys when: (lvm_snapshots_action == "create") or (lvm_snapshots_action == "remove") or (lvm_snapshots_action == "revert") |
一旦我们有了快照，我们就可以使用Ansible集合中的内容升级RHEL系统。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
--- - name: Upgrade hosts: "{{ rhel_inventory_group | default(omit) }}" strategy: free become: true force_handlers: true # vars: # ansible_python_interpreter: /usr/libexec/platform-python tasks: - name: Perform OS upgrade ansible.builtin.import_role: name: infra.leapp.upgrade ... |
一旦系统升级，我们就可以使用Ansible自动化平台来检查系统的状态。如果一切顺利，我们还可以使用自动化将系统重新投入生产。
步骤3：升级后的附加组件
我们的升级已经完成，但我们仍然可以使用Ansible自动化平台做更多事情。升级后的配置和集成可以作为我们自动化工作流程的一部分进行，简化我们在升级系统时经常忘记的所有额外任务。Ansible自动化平台允许您将新的RHEL系统集成到红帽洞察中，从而简化合规性检查和执行。我们还可以配置Performance Co-Pilot向Event-Driven Ansible报告系统指标，以及您能想到的所有其他第2天任务！
自动化分析可以帮助我们明确自动化流程，或者帮助我们识别流程中主机中可能存在的异常，然后我们可以稍后解决这些异常。
Views: 4