[ English | русский | español | English (United Kingdom) | Deutsch | 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 на целевых хостах):

• https://download.ceph.com/

• http://ubuntu-cloud.archive.canonical.com/ubuntu

• https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang

• https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server

• http://downloads.mariadb.com/MariaDB

Данные списки намеренно не исчерпывающи и эквивалентные необходимы для других дистрибутивов 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).