[ English | English (United Kingdom) | русский | Deutsch ]

Установка с ограниченным соединением

Многие плейбуки и роли в 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. Мы советуем зеркалировать репозитории, которые содержат данные пакеты.

Репозитории Ubuntu для зеркалирования на примере Ubuntu 22.04 LTS:

  • jammy

  • jammy-updates

OpenStack-Ansible требует несколько дополнительных репозиториев для установки специфичных компонентов, таких как Galera и Ceph.

Пример репозиториев для зеркалирования (Ubuntu на целевых хостах):

Эти списки намеренно не являются исчерпывающими, и для других дистрибутивов Linux потребуются эквиваленты. Ознакомьтесь с плейбуками OpenStack-Ansible и документацией по ролям для получения дополнительных репозиториев и переменных, которые могут использоваться для переопределения месторасположения репозитория.

Образы LXC контейнеров

OpenStack-Ansible собирает образы LXC с помощью debootstrap или dnf в зависимости от дистрибутива. Чтобы переопределить репозиторий пакетов, вам может потребоваться настроить некоторые переменные, например lxc_apt_mirror или полностью переопределить команду сборки с помощью lxc_hosts_container_build_command. Ознакомьтесь с ролью openstack-ansible-lxc_hosts для получения подробной информации о переопределении конфигурации для этого сценария.

Репозитории с исходным кодом

OpenStack-Ansible использует Ansible Galaxy для загрузки ролей Ansible при начальной подготовке хоста развертывания. Операторы могут зеркалировать зависимости, которые загружаются при помощи скрипта bootstrap-ansible.sh.

Операторы могут настроить скрипт на получение Ansible из альтернативного репозитория Git, установив переменную окружения ANSIBLE_GIT_REPO. Кроме того, во время начальной загрузки вам может потребоваться определить пользовательский URL для файла upper-constraints, который является частью репозитория openstack/requirements, используя переменную окружения TOX_CONSTRAINTS_FILE.

Операторы могут настроить скрипт для получения зависимостей ролей 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 трафика

Проксирование трафика TLS часто мешает клиентам успешно выполнять проверку цепочки сертификатов. В плейбуках и ролях OpenStack-Ansible существуют различные переменные конфигурации, которые позволяют оператору игнорировать эти сбои проверки. Отключайте проверку цепочки сертификатов в каждом конкретном случае и только после обнаружения сбоев, которые, как известно, вызваны только прокси-сервером(ами).