主要升级¶
本指南提供了从 2025.1 (Epoxy) 到 2025.2 (Flamingo) 升级 OpenStack-Ansible 的过程信息。
注意
您可以升级到连续发布版本，或升级到标记为 SLURP 的版本。
介绍¶
对于主要版本之间的升级，OpenStack-Ansible 仓库提供了用于升级环境的 playbook 和脚本。 run-upgrade.sh 脚本会按正确顺序运行每个升级 playbook，或者如果需要，可以单独运行 playbook。 或者，部署者可以手动升级。
有关主要升级过程的更多信息，请参阅 使用脚本升级 和 手动升级。
警告
升级始终处于积极开发中。 首先在开发环境中进行测试。
使用脚本升级¶
OpenStack-Ansible 的 2025.2 (Flamingo) 发布系列包含从 2025.1 (Epoxy) 迁移到 2025.2 (Flamingo) 的代码。
运行升级脚本¶
要使用升级脚本从 2025.1 (Epoxy) 升级到 2025.2 (Flamingo)，请在 openstack-ansible 目录中执行以下步骤
更改目录到仓库克隆的根目录
# cd /opt/openstack-ansible
运行以下命令
# git checkout 32.0.0.0rc1 # ./scripts/run-upgrade.sh
有关脚本执行步骤的更多信息，请参阅 手动升级。
手动升级¶
手动升级对于限定升级过程中的更改范围（例如，在具有严格 SLA 要求的非常大的部署中），或执行 OpenStack-Ansible 提供的自动化之外的其他升级自动化非常有用。
此处详细介绍的步骤与 run-upgrade.sh 脚本执行的步骤相匹配。 您可以安全地多次运行这些步骤。
升级前检查¶
在开始升级之前，请执行升级前健康检查，以确保您的环境稳定。 如果任何检查失败，请确保在继续之前解决该问题。
检出 2025.2 (Flamingo) 发布版¶
确保您的 OpenStack-Ansible 代码位于最新的 2025.2 (Flamingo) 标记发布版本上。
# git checkout 32.0.0.0rc1
备份现有的 OpenStack-Ansible 配置¶
备份环境的配置
# source_series_backup_file="/openstack/backup-openstack-ansible-2025.1.tar.gz"
# tar zcf ${source_series_backup_file} /etc/openstack_deploy /etc/ansible/ /usr/local/bin/openstack-ansible.rc
引导新的 Ansible 和 OpenStack-Ansible 角色¶
为了确保没有设置 ANSIBLE_INVENTORY 来覆盖默认的 inventory 位置，我们取消设置环境变量。
# unset ANSIBLE_INVENTORY
再次引导 Ansible，以确保所有 OpenStack-Ansible 角色依赖项都已就位，然后再运行 2025.2 (Flamingo) 发布版的 playbook。
# cd /opt/openstack-ansible
# ./scripts/bootstrap-ansible.sh
实施 OpenStack-Ansible 配置更改¶
如果 OpenStack-Ansible 变量名称或环境/inventory 发生了任何更改，则有一个 playbook 来处理这些更改，以确保在运行新的 playbook 时环境中的服务连续性。 该 playbook 已标记，以确保可以单独执行其任何部分或跳过该部分。 请查看 playbook 的内容以获取更多信息。
# openstack-ansible openstack.osa.upgrade.deploy_config_changes
注意
从 2024.2 (Dalmatian) 发布版及更高版本开始，使用 RabbitMQ Quorum Queues 是强制性的，以确保队列的高可用性。 如果您之前设置了 oslomsg_rabbit_quorum_queues: false，请在继续使用 RabbitMQ 4.x 的此升级之前考虑迁移。
请查看 RabbitMQ 维护 以获取有关在 Quourum 和 HA 队列之间切换的更多信息。
升级主机¶
在安装基础设施和 OpenStack 之前，请更新主机机器。
警告
由于较新 amqp 版本的要求，因此无法使用不受信任的证书进行 RabbitMQ。
之后，您可以继续执行标准的 OpenStack 升级步骤
# openstack-ansible openstack.osa.setup_hosts --limit '!galera_all:!rabbitmq_all' -e package_state=latest
此命令与在新安装中设置主机相同。 排除 galera_all 和 rabbitmq_all 主机组，以防止重新配置和重新启动任何这些容器，因为需要更新它们，但不需要重新启动。
完成此操作后，使用该标志升级最终的主机组，以防止容器重新启动。
# openstack-ansible openstack.osa.setup_hosts -e 'lxc_container_allow_restarts=false' --limit 'galera_all:rabbitmq_all'
升级基础设施¶
现在我们可以继续升级所有基础设施组件。 为了确保升级 RabbitMQ 和 MariaDB，我们传递了适当的标志。
警告
请确保在继续执行此步骤之前，您正在运行 RabbitMQ 版本 3.13 或更高版本。 从早期版本升级 RabbitMQ 到版本 4.0（2024.2 的默认版本）将导致 playbook 失败。
此时，您可以使用以下命令微调升级 RabbitMQ
openstack-ansible openstack.osa.rabbitmq_server -e rabbitmq_upgrade=true -e rabbitmq_package_version=3.13.7-1
此外，请确保您已从镜像队列（HA 队列）迁移到 Quorum 队列，因为镜像队列在升级后不再受支持。
# openstack-ansible openstack.osa.setup_infrastructure -e 'galera_upgrade=true' -e 'rabbitmq_upgrade=true' -e package_state=latest
完成此操作后，我们可以逐个重新启动 MariaDB 容器，确保每个容器都已启动、响应并与集群中的其他节点同步，然后再继续下一步骤。 此步骤允许您之前应用的 LXC 容器配置生效，确保以受控方式重新启动容器。
# openstack-ansible openstack.osa.tools.galera_cluster_rolling_restart
升级 OpenStack¶
现在我们可以继续升级所有 OpenStack 组件。
# openstack-ansible openstack.osa.setup_openstack -e package_state=latest
升级 Ceph¶
在每个 OpenStack-Ansible 版本中，我们都定义了将在 Glance/Cinder/Nova 主机上安装并由这些服务使用的默认 Ceph 客户端版本。 如果您希望在 OpenStack-Ansible 升级期间保留以前版本的 ceph 客户端，则需要在 user_variables.yml 中覆盖变量 ceph_stable_release。
如果 Ceph 作为 OpenStack-Ansible 部署的一部分使用由 Ceph-Ansible 项目维护的角色部署的，您还需要升级 Ceph 版本。 每个 OpenStack-Ansible 版本仅与特定的 Ceph-Ansible 版本进行测试，并且 Ceph 升级未在任何 Openstack-Ansible 集成测试中进行检查。 因此，我们不测试或保证此类部署的升级路径。 在这种情况下，应在实验室环境中进行测试，然后再进行升级。
警告
Ceph 相关 playbook 包含在 openstack.osa.setup_infrastructure 和 openstack.osa.setup_openstack playbook 的一部分中，因此在 OpenStack 升级期间运行它们时应谨慎。 如果您的用户变量中设置了 upgrade_ceph_packages: true 或提供了 -e upgrade_ceph_packages=true 作为参数，并运行 setup-infrastructure.yml，这将导致 Ceph 包被升级。
为了升级部署中的 Ceph，您需要运行
# openstack-ansible /etc/ansible/roles/ceph-ansible/infrastructure-playbooks/rolling_update.yml
