[ English | Indonesia | русский ]
Основные обновления¶
В этом руководстве содержится информация о процессе обновления с 2025.1 (Epoxy) до 2025.2 (Flamingo) для OpenStack-Ansible.
Примечание
Вы можете обновляться между последовательными релизами или между релизами, помеченными как SLURP.
Введение¶
Для обновления между основными версиями репозиторий OpenStack-Ansible содержит плейбук и скрипты для обновления окружения. Сценарий run-upgrade.sh запускает каждый плейбук обновления в правильном порядке, а при необходимости плейбук можно запускать по отдельности. Кроме того, установщик может обновить среду вручную.
Более подробную информацию о процессе обновления смотрите в Обновление с помощью скрипта и Обновление вручную.
Предупреждение
Upgrading to master is not recommended. Master is under heavy development, and is not stable. Сначала протестируйте это в окружении разработчиков.
Обновление с помощью скрипта¶
Серия релизов 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 master # ./scripts/run-upgrade.sh
Более подробную информацию о действиях, выполняемых скриптом, смотрите в Обновление вручную.
Обновление вручную¶
Ручное обновление полезно для определения масштаба изменений в процессе обновления (например, в очень крупных развертываниях со строгими требованиями к SLA) или для автоматизации других обновлений, помимо тех, что предоставляет OpenStack-Ansible.
Шаги, описанные здесь, совпадают с теми, которые выполняет сценарий run-upgrade.sh. Вы можете смело выполнять эти шаги несколько раз.
Предварительные проверки¶
Прежде чем приступить к обновлению, выполните предварительную проверку работоспособности, чтобы убедиться в стабильности окружения. Если какая-либо из этих проверок не удалась, убедитесь, что проблема решена, прежде чем продолжать.
Проверьте релиз 2025.2 (Flamingo).¶
Убедитесь, что ваш код OpenStack-Ansible находится на последней версии с меткой 2025.2 (Flamingo).
# git checkout master
Резервное копирование существующей конфигурации 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).
# cd /opt/openstack-ansible
# ./scripts/bootstrap-ansible.sh
Внесите изменения в конфигурацию OpenStack-Ansible¶
Если в OpenStack-Ansible были внесены изменения в имена переменных или в окружение/inventory, есть плейбук для обработки этих изменений, чтобы обеспечить непрерывность обслуживания в окружении при запуске новых playbook. Плейбук содержит теги, чтобы любая его часть могла быть выполнена самостоятельно или пропущена. Для получения дополнительной информации ознакомьтесь с содержанием плейбука.
# openstack-ansible openstack.osa.upgrade.deploy_config_changes
Примечание
С обновлением до релиза 2024.2 (Dalmatian) и выше использование RabbitMQ Quorum Queues является обязательным для обеспечения высокой доступности очередей. Если ранее вы установили oslomsg_rabbit_quorum_queues: false, пожалуйста, рассмотрите возможность миграции перед продолжением этого обновления, которое использует RabbitMQ 4.x.
Пожалуйста, ознакомьтесь с RabbitMQ maintenance для получения дополнительной информации о переключении между Quourum и HA Queues.
Обновление хостов¶
Перед установкой инфраструктуры и окружения OpenStack обновите хосты.
Предупреждение
Использование недоверенных сертификатов для RabbitMQ невозможно из-за требований более новых версий amqp.
После этого вы можете приступить к стандартным шагам обновления 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) с предыдущей версии приведет к сбою плейбука.
На этом этапе вы можете незначительно обновить 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 мы определяем версию клиента Ceph по умолчанию, которая будет установлена на хостах Glance/Cinder/Nova и использоваться этими службами. Если вы хотите сохранить предыдущую версию клиента Сeph при обновлении OpenStack-Ansible, вам нужно переопределить переменную ceph_stable_release в файле user_variables.yml
Если Ceph был развернут как часть развертывания OpenStack-Ansible с использованием ролей, поддерживаемых проектом Ceph-Ansible, вам также потребуется обновить версию Ceph. Каждый релиз OpenStack-Ansible тестируется только с определенным выпуском Ceph-Ansible, и обновление Ceph не проверяется ни в одном интеграционном тесте Openstack-Ansible. Поэтому мы не тестируем и не гарантируем путь обновления для таких развертываний. В этом случае перед обновлением следует провести тесты в лабораторном окружении.
Предупреждение
Плейбуки, связанные с Ceph, включены в состав плейбуков openstack.osa.setup_infrastructure и openstack.osa.setup_openstack, поэтому следует быть осторожным при их запуске во время обновления 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
