[ English | Deutsch | español | Indonesia | English (United Kingdom) | русский ]
Быстрое начало: AIO¶
Все-в-одном (AIO) это отличный способ выполнить установку OpenStack-Ansible для:
окружения для разработки
получения общего представления, как все сервисы OpenStack взаимодействуют друг с другом
простого исследовательского развертывания
Хоть AIO и не рекомендуется для больших рабочих окружений, он отлично подходит для небольших установок для проверки концепта.
Минимальные системные требования (используются для регулярного тестирования):
8 vCPU
50 Гб свободного дискового пространства на root разделе
8 Гб ОЗУ
Рекомендуемые системные ресурсы:
CPU/материнская плата поддерживают аппаратную виртуализацию
8 ядер CPU
80 Гб свободного дискового пространства, или 60 Гб+ на чистом дополнительном диске. Использование дополнительного диска требует использования параметра
bootstrap_host_data_disk_device. Пожалуйста, обратитесь к разделу Установка AIO для деталей.16 Гб ОЗУ
Имеется возможность выполнить развертывание AIO на виртуальном сервере для обзора и оценки, но ваши виртуальные сервера будут иметь низкую производительность, особенно, если вложенная виртуализация недоступна. Для рабочих окружений рекомендуется использовать несколько нод для отдельных ролей.
Установка AIO¶
Обзор¶
Имеется три необходимых шага для запуска установки AIO, с опциональным первым шагом, если вам нужно настроить развертывание:
Подготовка сервера
Начальная подготовка Ansible и требуемых ролей
Начальная подготовка конфигурации AIO
Запуск плейбуков
Подготовка сервера¶
Перед установкой AIO на новый сервер, рекомендуется обновить все системные пакеты и после этого выполнить перезагрузку в новое ядро:
Примечание
Выполните следующие команды от имени root пользователя.
## Ubuntu / Debian
# apt-get update
# apt-get dist-upgrade
# reboot
## CentOS / Rocky Linux
# dnf upgrade
# dnf install git-core
# systemctl stop firewalld
# systemctl mask firewalld
# reboot
Примечание
Перед перезагрузкой убедитесь, что в /etc/sysconfig/selinux параметр SELINUX=enforcing установлен в значение SELINUX=disabled. SELinux на данный момент не поддерживается в OpenStack-Ansible для CentOS/Rocky/RHEL из-за нехватки ресурсов для сопровождения данной возможности.
Примечание
Если вы производите установку с ограниченным доступом к сети, пожалуйста посмотрите Установка с ограниченным подключением перед тем, как продолжить.
Начальная подготовка Ansible и требуемых ролей¶
Начните с клонирования репозитория OpenStack-Ansible и перехода в его корневую директорию:
# git clone https://opendev.org/openstack/openstack-ansible \
/opt/openstack-ansible
# cd /opt/openstack-ansible
Далее переключитесь на желаемую ветку/тег с которого будет произведена установка. Учтите, что развертывание с определенной ветки может привести к нестабильной сборке из-за изменений, которые находятся в процессе, а также изменений в OpenStack. Для теста (не для разработки), обычно, наилучшим выбором будет переход на последнюю тегированную версию.
# # List all existing tags. # git tag -l # # Checkout the stable branch and find just the latest tag # git checkout stable/2024.2 # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout 30.0.0.0rc1
Примечание
The 2024.2 release is only compatible with Debian 12 (bookworm), Ubuntu 22.04 (Jammy Jellyfish), Ubuntu 24.04 (Noble Numbat), CentOS 9 Stream, and derivitives of CentOS Stream/RHEL such as Rocky Linux.
Следующий шаг это выполнение подготовки Ansible и Ansible ролей для среды разработки.
Выполните следующие команды для подготовки Ansible и требуемых ролей:
# scripts/bootstrap-ansible.sh
Примечание
Вы можете столкнуться с ошибками во время выполнения скрипта начальной подготовки Ansible, во время установки некоторых модулей Python (таких как pycrypto), например:
configure: error: cannot run C compiled programs.
Причина данной ошибки может быть следствием установленного флага noexec, использованного при монтировании файловой системы для /tmp, который вы можете проверить при помощи следующей команды:
# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec
В этом случае вы можете указать другой путь, для которого не указан данный флаг монтирования:
# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh
Начальная подготовка конфигурации AIO¶
Для того, что бы все сервисы успешно запустились, сервер должен быть подготовлен с использованием соответствующей разметки дисков, настроек сети и настроек развертывания OpenStack.
По умолчанию скрипты подготовки AIO разворачивают базовый набор сервисов OpenStack с благоразумными настройками по умолчанию для автоматических тестов, разработки или проверки работы систем.
Просмотрите файл bootstrap-host role defaults - в нем содержатся различные настройки развертывания. Оператор имеет возможность настроить, каким образом сервер будет подготовлен. Это может быть полезно, когда вы хотите, что бы AIO использовал второй диск для данных, либо же использовать данную роль для подготовки развертывания окружения на несколько серверов.
Скрипт начальной подготовки настроен на передачу переменной окружения BOOTSTRAP_OPTS как дополнительного параметра для процесса подготовки. Например, если вы хотите, задать второй диск (/dev/sdb) для переразметки при подготовке, которая удалит все данные на данном устройстве, выполните:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
Дополнительные параметры можно указать просто разделив их пробелом, например:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
# export BOOTSTRAP_OPTS="${BOOTSTRAP_OPTS} bootstrap_host_data_disk_fs_type=xfs"
Если вы производите установку с ограниченным соединение или маршрут по умолчанию отсутствует, вам будет нужно задать интерфейс для исходящих соединений вручную
# export BOOTSTRAP_OPTS="bootstrap_host_public_interface=eth1"
Для стандартного сценария AIO, начальная подготовка выполняется при помощи команды:
# scripts/bootstrap-aio.sh
Чтобы добавить сервисы OpenStack в дополнение к сервисам настраивающимся AIO по умолчанию в рамках сценария, скопируйте файлы из директории conf.d с расширением .aio в /etc/openstack_deploy и смените их расширение на .yml. Например, для того, что бы подключить сервисы Телеметрии OpenStack, выполните следующее:
# cd /opt/openstack-ansible/
# cp etc/openstack_deploy/conf.d/{aodh,gnocchi,ceilometer}.yml.aio /etc/openstack_deploy/conf.d/
# for f in $(ls -1 /etc/openstack_deploy/conf.d/*.aio); do mv -v ${f} ${f%.*}; done
It is possible to also do this (and change other defaults) during the bootstrap script initial execution by changing the SCENARIO environment variable before running the script. The key word „aio“ will ensure that a basic set of OpenStack services (cinder, glance, horizon, neutron, nova) will be deployed. The key words „lxc“ can be used to set the container back-end, while the key word „metal“ will deploy all services without containers. In order to implement any other services, add the name of the conf.d file name without the .yml.aio extension into the SCENARIO environment variable. Each key word should be delimited by an underscore. For example, the following will implement an AIO with barbican, cinder, glance, horizon, neutron, and nova. It will set the cinder storage back-end to ceph and will make use of LXC as the container back-end.
# export SCENARIO='aio_lxc_barbican_ceph_lxb'
# scripts/bootstrap-aio.sh
Для того, что бы глобально переопределить значения по умолчанию для сценария, отредактируйте /etc/openstack_deploy/user_variables.yml. Для понимания различных способов переопределения стандартного поведения, заданного в ролях, плейбуках и переменных групп, ознакомьтесь с Overriding default configuration.
Ознакомьтесь с Deployment Guide, где более подробно описаны способы применения собственной конфигурации, вместо использования начальной подготовки AIO.
Запуск плейбуков¶
Наконец, запустите плейбуки выполнив:
# openstack-ansible openstack.osa.setup_hosts
# openstack-ansible openstack.osa.setup_infrastructure
# openstack-ansible openstack.osa.setup_openstack
Процесс установки займет некоторое время, но продолжительность, примерно, следующая:
Сервера без виртуализации с SSD диском: ~30-50 минут
Виртуальные сервера с SSD диском: ~45-60 минут
Системы с традиционными жесткими дисками: ~90-120 минут
Как только выполнение плейбуков завершилось, вы можете экспериментировать с изменением различных настроек в /etc/openstack_deploy/user_variables.yml и запускать только отдельные плейбуки. Например, для запуска плейбука для сервиса Keystone выполните:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible os-keystone-install.yml
Interacting with an AIO¶
Once an AIO has been deployed, you most likely want to interact with it. You can do this via the web interface or one of the many clients or libraries that exist for OpenStack.
Using a GUI¶
The horizon web interface provides a graphical interface for interacting with the AIO deployment. By default, the horizon API is available on port 443 of the host (or port 80, if SSL certificate configuration was disabled). As such, to interact with horizon, simply browse to the IP of the host.
Примечание
If the AIO was deployed in a cloud VM, you may need to configure security groups or firewall rules to allow access to the HTTP(S) ports. For example, if the AIO was deployed in an OpenStack VM, you can create and apply a suitable security group for interacting with horizon like so:
$ openstack security group create http \
--description 'Allow HTTP and HTTPS access'
$ openstack security group rule create http \
--protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
$ openstack security group rule create http \
--protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0
$ openstack server add security group $SERVER http
A list of service ports can be found in the OpenStack Install Guide.
This will present a login page. By default, OpenStack-Ansible create a user
called admin. The password will be the value of the
keystone_auth_admin_password variable. If you did not configure this
variable, OpenStack-Ansible auto-generates one. You can view the configured
password in the /etc/openstack_deploy/user_secrets.yml file.
# grep admin_pass /etc/openstack_deploy/user_secrets.yml
heat_stack_domain_admin_password: <redacted>
keystone_auth_admin_password: <redacted>
radosgw_admin_password: <redacted>
Using this username and password combination, log in to horizon.
Using a client or library¶
There are a variety of clients and libraries available for interacting with an
OpenStack deployment, including as openstackclient, openstacksdk, or
gophercloud. These are typically configured using either environment
variables sourced from an openrc file or the newer clouds.yaml file.
OpenStack-Ansible provides the openstack_openrc role for creating these
configuration files as well as a number of utilities such as openstackclient.
If the AIO deployment using the lxc scenario (the default), these will be
availably in the utility container.
$ lxc-attach -n `lxc-ls -1 | grep utility`
# ls /root/openrc
/root/openrc
# ls /root/.config/openstack/clouds.yaml
/root/.config/openstack/clouds.yaml
# export OS_CLOUD=default
# openstack project list -c Name -f value
service
admin
Alternatively, if the AIO was deployed using the metal scenario, these
files will be available on the host itself.
# ls /root/openrc
/root/openrc
# ls /root/.config/openstack/clouds.yaml
/root/.config/openstack/clouds.yaml
If you wish to access the AIO deployment from another host - perhaps your local
workstation - you will need either an openrc file or clouds.yaml file.
You can download an openrc file from horizon: simply click the User
dropdown in the top-right corner and select ⭳ OpenStack RC file.
Важно
You may be tempted to copy the openrc or clouds.yaml files created
by the openstack_openrc role. However, these files use the internal
interface by default. This interface use the management network
(172.29.236.0/22) , which is not routable from outside the host. If you
wish to use these files, you will need to change the interface to
public.
Примечание
If the AIO was deployed in a cloud VM, you may need to configure security groups or firewall rules to allow access to the various sevice ports. For example, if the AIO was deployed in an OpenStack VM, you can create and apply a suitable security group for interacting the core services like so:
$ openstack security group create openstack-apis \
--description 'Allow access to various OpenStack services'
$ for port in 8774 8776 9292 9696 5000 8780; do
openstack security group rule create openstack-apis \
--protocol tcp --dst-port ${port}:${port} --remote-ip 0.0.0.0/0
done
$ openstack server add security group $SERVER openstack-apis
A list of service ports can be found in the OpenStack Install Guide.
Примечание
If you have enabled SSL certificate configuration (default), all services
will use self-signed certificates. While the host is configured to trust
these certificates, this is not the case for other hosts. This will result
in HTTPS errors when attempting to interact with the cloud. To resolve this
issue, you will need to manually configure certificates on other hosts or
ignore SSL issues. To use the self-signed certificate, first copy it to the
other hosts. The name and location of the generated certificate are
configured by the pki_authorities and pki_trust_store_location
variables respectively, which are used by the pki role provided by
ansible-role-pki. On an Ubuntu 22.04 host, these will default to
ExampleCorpRoot and /usr/local/share/ca-certificates, respectively.
For example:
$ scp aio:/usr/local/share/ca-certificates/ExampleCorpRoot.crt ~/.config/openstack/aio.crt
Once this is done, configure the cacert value in the the definition for
your cloud in clouds.yaml. For example:
clouds:
aio:
# ...
cacert: /home/<username>/.config/openstack/aio.crt
Alternatively, you can simply ignore SSL issues by setting verify: false
in the definition for your cloud in clouds.yaml. This will disable SSL
verification entirely for this cloud. For example:
clouds:
aio:
# ...
verify: false
Finally, you can also opt to disable SSL certificate configuration during initial deployment or opt to use an external certificate authority for signing, such as Lets Encrypt. Both topics are outside the scope of this document.
More information about SSL certificate configuration can be found in the security guide.
Once one of these files have been created, you can use it to interact with your deployment using most standard clients and libraries. For example, to list available projects using openstackclient:
$ export OS_CLOUD=aio
$ openstack project list -c Name -f value
service
admin
Перезагрузка AIO¶
Так как на AIO расположены все три участника кластера MariaDB/Galera, кластер должен быть повторно инициализирован после перезагрузки сервера.
Это можно сделать выполнив:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible -e galera_ignore_cluster_state=true galera-install.yml
If this fails to get the database cluster back into a running state, then please make use of the Galera Cluster Recovery section in the operations guide.
Переустановка AIO¶
Иногда может быть полезным удаление всех контейнеров и переустановка AIO. Хоть и рекомендуется полное удаление AIO и переустановка с нуля, это не всегда практично. Потому, можно выполнить следующее, вместо полной переустановки:
# # Move to the playbooks directory.
# cd /opt/openstack-ansible/playbooks
# # Destroy all of the running containers.
# openstack-ansible lxc-containers-destroy.yml
# # On the host stop all of the services that run locally and not
# # within a container.
# for i in \
$(ls /etc/init \
| grep -e "nova\|swift\|neutron\|cinder" \
| awk -F'.' '{print $1}'); do \
service $i stop; \
done
# # Uninstall the core services that were installed.
# for i in $(pip freeze | grep -e "nova\|neutron\|keystone\|swift\|cinder"); do \
pip uninstall -y $i; done
# # Remove crusty directories.
# rm -rf /openstack /etc/{neutron,nova,swift,cinder} \
/var/log/{neutron,nova,swift,cinder}
# # Remove the pip configuration files on the host
# rm -rf /root/.pip
# # Remove the apt package manager proxy
# rm /etc/apt/apt.conf.d/00apt-cacher-proxy
Если необходимо переустановить окружение AIO, самый эффективный способ это переустановить операционную систему на сервере и начать с начала. По этой причине лучше всего запускать AIO в виртуальной машине или гостевом облаке.
Справочная схема по развертыванию AIO¶
Ниже представлена базовая диаграмма, которая примерно иллюстрирует, как выглядит установленный AIO.
Данная диаграмма не масштабируется и даже не точна на 100%, она была создана в ознакомительных целях и должна использоваться ТОЛЬКО для них.
------->[ ETH0 == Public Network ]
|
V [ * ] Socket Connections
[ HOST MACHINE ] [ <>v^ ] Network Connections
* ^ *
| | |-------------------------------------------------------
| | |
| |---------------->[ HAProxy ] |
| ^ |
| | |
| V |
| (BR-Interfaces)<------ |
| ^ * | |
*-[ LXC ]*--*----------------------|-----|------|----| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | V * | |
| * | | [ Galera x3 ] |
| [ Memcached ]<------------| | | |
*-------*[ Rsyslog ]<--------------|--| | * |
| [ Repos Server x3 ]<------| ---|-->[ RabbitMQ x3 ] |
| [ Horizon x2 ]<-----------| | | |
| [ Nova api ec2 ]<---------|--| | |
| [ Nova api os ]<----------|->| | |
| [ Nova console ]<---------| | | |
| [ Nova Cert ]<------------|->| | |
| [ Cinder api ]<-----------|->| | |
| [ Glance api ]<-----------|->| | |
| [ Heat apis ]<------------|->| | [ Loop back devices ]*-*
| [ Heat engine ]<----------|->| | \ \ |
| ------>[ Nova api metadata ] | | | { LVM } { XFS x3 } |
| | [ Nova conductor ]<-------| | | * * |
| |----->[ Nova scheduler ]--------|->| | | | |
| | [ Keystone x3 ]<----------|->| | | | |
| | |--->[ Neutron agents ]*-------|--|---------------------------*
| | | [ Neutron server ]<-------|->| | | |
| | | |->[ Swift proxy ]<----------- | | | |
*-|-|-|-*[ Cinder volume ]*----------------------* | |
| | | | | | |
| | | ----------------------------------------- | |
| | ----------------------------------------- | | |
| | -------------------------| | | | |
| | | | | | |
| | V | | * |
---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-
