[ English | English (United Kingdom) | Deutsch | русский | español | Indonesia ]
Установка с ограниченным соединением¶
Многие плейбуки и роли в OpenStack-Ansible получают зависимости из Интернета по умолчанию. Настройки в примерах предполагают, что имеется Интернет соединение с высокой пропускной способностью через роутер в управляющей сети OpenStack.
Установки могут сталкиваться с ограниченным внешним соединением по ряду причин:
Ненадежное или медленное внешнее соединение
Правила брандмауэра, которые блокируют внешнее соединение
Внешнее соединение осуществляется через HTTP или SOCKS прокси
Архитектурные решения оператора изолировать сети OpenStack
Высокозащищенные окружения, где внешнее соединение не разрешено
При запуске OpenStack-Ansible в окружениях, которые блокируют интернет соединение, мы рекомендуем использовать следующий набор практик и переопределений настроек для использования.
Нижеприведенные параметры не исключают друг друга, и могут быть совмещены при необходимости.
Пример зависящих от Интернета вещей¶
пакеты Python
пакеты дистрибутивов
образы LXC контейнеров
репозитории с исходным кодом
GPG ключи для валидации пакетов
Вариант А: Создание локальных зеркал интернет ресурсов¶
Вы можете управлять и поддерживать зеркала OpenStack-Ansible и зависимостей OpenStack. Зеркала обычно предоставляют значительное снижение рисков путем уменьшения зависимости от ресурсов и систем вне вашего прямого контроля. Зеркала также могут дать более высокую стабильность, производительность и безопасность.
Репозитории Python пакетов¶
Много пакетов, используемых для запуска OpenStack, устанавливаются при помощи pip. Мы рекомендуем зеркалировать список пакетов из PyPi, которые используются pip. Оператор может предпочесть активно зеркалировать весь верхний репозиторий PyPi, но это может потребовать значительный объем дискового пространства. Как вариант, можно использовать кэширующий pip прокси для получения локальных копий только требуемых пакетов.
Что бы настроить развертывание на использование альтернативного источника при сборке, создайте файл /etc/pip.conf со следующим содержанием и убедитесь, что он имеется на всех хостах в окружении.
[global]
index-url = http://pip.example.org/simple
Дополнительно необходимо настроить easy_install на использование альтернативного индекса. easy_install используется вместо pip для установки любых зависимостей, которые указаны в переменной setup_requires в setup.py во время сборки wheel. Для более подробной информации https://pip.pypa.io/en/latest/reference/pip_install/#controlling-setup-requires
Для настройки easy_install используйте альтернативный индекс, создайте файл /root/.pydistutils.cfg со следующим содержанием.
[easy_install]
index_url = https://pip.example.org/simple
После, в /etc/openstack_deploy/user_variables.yml, настройте развертывание для копирования данных файлов с хоста в кэш образа контейнера.
# Copy these files from the host into the containers
lxc_container_cache_files_from_host:
- /etc/pip.conf
- /root/.pydistutils.cfg
пакеты дистрибутивов¶
Много программных пакетов установлено на Ubuntu при помощи .deb пакетов. Схожие механизмы пакетов существуют и для других дистрибутивов Linux. Мы советуем зеркалировать репозитории, которые содержат данные пакеты.
Upstream Ubuntu repositories to mirror for Ubuntu 22.04 LTS:
jammy
jammy-updates
OpenStack-Ansible требует несколько дополнительных репозиториев для установки специфичных компонентов, таких как Galera и Ceph.
Пример репозиториев для зеркалирования (Ubuntu на целевых хостах):
Данные списки намеренно не исчерпывающи и эквивалентные необходимы для других дистрибутивов Linux. Обратитесь к плейбукам OpenStack-Ansible и документации по ролям для дополнительных репозиториев и переменных, которые могут быть использованы для переопределения месторасположения репозитория.
образы LXC контейнеров¶
OpenStack-Ansible builds LXC images using debootstrap or dnf depending on
the distribution. In order to override the package repository you
might need to adjust some variables, like lxc_apt_mirror
or completely
override build command with lxc_hosts_container_build_command
Consult the openstack-ansible-lxc_hosts
role for details on
configuration overrides for this scenario.
репозитории с исходным кодом¶
OpenStack-Ansible использует Ansible Galaxy для загрузки ролей Ansible при начальной подготовке хоста развертывания. Операторы могут зеркалировать зависимости, которые загружаются при помощи скрипта bootstrap-ansible.sh
.
Deployers can configure the script to source Ansible from an alternate Git
repository by setting the environment variable ANSIBLE_GIT_REPO
. Also,
during initial bootstrap you might need to define a custom URL for
upper-constraints file that is part of openstack/requirements repository,
using the TOX_CONSTRAINTS_FILE environment variable.
Операторы могу настроить скрипт получать требуемые Ansible роли из альтернативных источников указав пользовательский файл требуемых ролей и указав путь к этому файлу при помощи переменной окружения ANSIBLE_ROLE_FILE
.
Вариант Б: Доступ к интернет ресурсам при помощи прокси¶
Некоторые сети не имеют маршрутизируемого доступа в Интернет, или требуют для определенного трафика использовать специфичные шлюзы, такие как HTTP или SOCKS прокси сервера.
Настройка может быть применена к целевым серверам и хосту развертывания для получения доступа к публичным интернет ресурсам через HTTP или SOCKS прокси сервер(ы). OpenStack-Ansible может быть использован для настройки целевых хостов использовать прокси сервер(ы). OpenStack-Ansible не предоставляет автоматизацию по созданию прокси сервера(ов)
Начальный хост развертывания не покрывается OpenStack-Ansible и оператор должен обеспечить наличие минимальных настройки прокси, а именно для системного менеджера пакетов.
Настройка прокси для apt-get
¶
Обратитесь к Настройка apt-get для использования http-прокси
Другие настройки прокси¶
В дополнение к базовой конфигурации имеются другие сетевые клиенты на целевых хостах, которые могут быть настроены для соединения через прокси. Например:
Большинство Python модулей
curl
wget
openstack
Эти инструменты и положенные в их основу библиотеки используются как непосредственно Ansible-ом, так и плейбуками OpenStack-Ansible. Потому для успешного доступа плейбуков к внешним ресурсам должна быть произведена настройка прокси.
Обычно эти инструменты считывают переменные окружения, содержащие настройки прокси сервера. Эти переменные окружения, при необходимости, можно задать в /etc/environment
.
Важно отметить, что прокси сервер должен использоваться только для доступа ко внешним ресурсам, а связь между внутренними компонентами OpenStack должна быть прямая и без использования прокси. Переменная окружения no_proxy
используется для определения хостов, доступ к которым должен быть осуществлён напрямую, без использования прокси. Обычно, это хосты из управляющей сети.
OpenStack-Ansible предоставляет два различных механизма для настройки прокси сервера:
1. The default configuration file suggests setting a persistent proxy
configuration on all target hosts and defines a persistent no_proxy
environment variable which lists all hosts/containers“ management addresses as
well as the load balancer internal/external addresses.
2. An alternative method applies proxy configuration in a transient manner
during the execution of Ansible playbooks and defines a minimum set of
management network IP addresses for no_proxy
that are required for the
playbooks to succeed. These proxy settings do not persist after an Ansible
playbook run and the completed deployment does not require them in order to be
functional.
Оператор должен решить какой из данных подходов больше подходит для целевых хостов, учитывая следующие рекомендации:
1. Persistent proxy configuration is a standard practice and network clients on the target hosts will be able to access external resources after deployment.
2. The deployer must ensure that a persistent proxy configuration has complete
coverage of all OpenStack management network host/containers“ IP addresses in
the no_proxy
environment variable. It is necessary to use a list of IP
addresses, CIDR notation is not valid for no_proxy
.
3. Transient proxy configuration guarantees that proxy environment variables
will not persist, ensuring direct communication between services on the
OpenStack management network after deployment. Target host network clients
such as wget
will not be able to access external resources after
deployment.
4. The maximum length of no_proxy
should not exceed 1024 characters due to
a fixed size buffer in the pam_env
PAM module. Longer environment variables
will be truncated during deployment operations and this will lead to
unpredictable errors during or after deployment.
Как только количество хостов/контейнеров в окружении достигнет определенного размера и длина no_proxy
превысит 1024 символа, в этот момент будет необходимо использовать сквозной прокси, настройки которого требуют только наличия ряда IP адресов управляющей сети в no_proxy
во время развертывания.
Обратитесь к global_environment_variables: и deployment_environment_variables: в типовом user_variables.yml для получения деталей о настройке переменных окружения для постоянного и временного прокси.
Настройка прокси на хосте развертывания для подготовки Ansible¶
Скрипт bootstrap-ansible.sh
, используемый для установки Ansible и зависимостей Ansible ролей на хосте развертывания, использует настройки прокси, заданные переменными окружения HTTPS_PROXY
или HTTP_PROXY
.
Примечание
Мы рекомендуем задать ваши переменные окружения с настройками прокси в /etc/environment
перед запуском каких-либо скриптов или плейбуков что бы избежать ошибок.
Для больших или сложных окружений, выделенный хост развертывания позволит применить наиболее подходящую настройку прокси как для хоста развертывания, так и для целевых хостов.
Важные моменты при проксировании TLS трафика¶
Proxying TLS traffic often interferes with the clients ability to perform successful validation of the certificate chain. Various configuration variables exist within the OpenStack-Ansible playbooks and roles that allow a deployer to ignore these validation failures. Disable certificate chain validation on a case by case basis and only after encountering failures that are known to only be caused by the proxy server(s).