[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]

Installation mit eingeschränkter Konnektivität

Many playbooks and roles in OpenStack-Ansible retrieve dependencies from the public Internet by default. The example configurations assume that the deployer provides a good quality Internet connection via a router on the OpenStack management network.

Für Bereitstellungen kann es aus mehreren Gründen zu eingeschränkter externer Konnektivität kommen:

  • Unzuverlässige oder niedrige Bandbreite externe Konnektivität

  • Firewall-Regeln, die externe Konnektivität blockieren

  • Externe Konnektivität muss über HTTP- oder SOCKS-Proxies erfolgen

  • Architekturentscheidungen des Deployers zur Isolierung der OpenStack-Netzwerke

  • Hochsicherheitsumgebungen, in denen keine externe Konnektivität zulässig ist

When running OpenStack-Ansible in network environments that block internet connectivity, we recommend the following set of practices and configuration overrides for deployers to use.

Die folgenden Optionen schließen sich nicht gegenseitig aus und können bei Bedarf kombiniert werden.

Beispiel Internetabhängigkeiten

  • Python-Pakete

  • Verteilungsspezifische Pakete

  • LXC-Containerbilder

  • Quellcode-Repositories

  • GPG-Schlüssel für die Paketvalidierung

Übung A: Spiegeln Sie Internetressourcen lokal

Sie können wählen, Mirrors von OpenStack-Ansible und OpenStack-Abhängigkeiten zu betreiben und zu pflegen. Mirrors bieten oft eine große Risikominderung, da Abhängigkeiten von Ressourcen und Systemen, auf die Sie keinen direkten Einfluss haben, reduziert werden. Spiegel können auch für mehr Stabilität, Leistung und Sicherheit sorgen.

Python-Paket-Repositories

Many packages used to run OpenStack are installed using pip. We advise mirroring the PyPi package index used by pip. A deployer can choose to actively mirror the entire upstream PyPi repository, but this may require a significant amount of storage. Alternatively, a caching pip proxy can be used to retain local copies of only those packages which are required.

In order to configure the deployment to use an alternative index, create the file /etc/pip.conf with the following content and ensure that it resides on all hosts in the environment.

[global]
index-url = http://pip.example.org/simple

In addition, it is necessary to configure easy_install to use an alternative index. easy_install is used instead of pip to install anything listed under setup_requires in setup.py during wheel builds. See https://pip.pypa.io/en/latest/reference/pip_install/#controlling-setup-requires

To configure easy_install to use an alternative index, create the file /root/.pydistutils.cfg with the following content.

[easy_install]
index_url = https://pip.example.org/simple

Then, in /etc/openstack_deploy/user_variables.yml, configure the deployment to copy these files from the host into the container cache image.

# Copy these files from the host into the containers
lxc_container_cache_files_from_host:
  - /etc/pip.conf
  - /root/.pydistutils.cfg

Verteilungsspezifische Pakete

Viele Softwarepakete werden auf Ubuntu-Hosts mit .deb-Paketen installiert. Ähnliche Verpackungsmechanismen existieren für andere Linux-Distributionen. Wir empfehlen, die Repositorys zu spiegeln, die diese Pakete hosten.

Upstream Ubuntu repositories to mirror for Ubuntu 20.04 LTS:

  • focal

  • focal-updates

OpenStack-Ansible benötigt mehrere andere Repositories, um bestimmte Komponenten wie Galera und Ceph zu installieren.

Beispielrepositorys zum Spiegeln (Ubuntu-Zielhosts):

Diese Listen sind absichtlich nicht erschöpfend und für andere Linux-Distributionen sind Entsprechungen erforderlich. Konsultieren Sie die OpenStack-Ansible-Spielbücher und die Rollendokumentation für weitere Repositorys und die Variablen, die zum Überschreiben des Repository-Speicherorts verwendet werden können.

LXC-Containerbilder

OpenStack-Ansible basiert auf von der Community erstellten LXC-Images, wenn Container für OpenStack-Services erstellt werden. Bereitsteller können ihre eigenen Container-Images erstellen, verwalten und hosten. Weitere Informationen zu Konfigurationsüberschreibungen für dieses Szenario finden Sie in der Rolle "openstack-ansible-lxc_container_create".

Quellcode-Repositories

OpenStack-Ansible basiert darauf, dass Ansible Galaxy Ansible-Rollen beim Bootstrapping eines Bereitstellungshosts herunterlädt. Deployer möchten möglicherweise die Abhängigkeiten spiegeln, die vom `` bootstrap-ansible.sh``-Skript heruntergeladen werden.

Deployer können das Skript so konfigurieren, dass es Ansible aus einem alternativen Git-Repository bezieht, indem es die Umgebungsvariable `` ANSIBLE_GIT_REPO`` festlegt.

Deployer können das Skript so konfigurieren, dass es Ansible-Rollenabhängigkeiten von alternativen Speicherorten abruft, indem es eine benutzerdefinierte Rollenanforderungsdatei bereitstellt und den Pfad zu dieser Datei mit der Umgebungsvariable ANSIBLE_ROLE_FILE angibt.

Übung B: Proxy-Zugriff auf Internetressourcen

Einige Netzwerke haben keinen gerouteten Zugriff auf das Internet oder erfordern einen bestimmten Datenverkehr, um anwendungsspezifische Gateways wie HTTP- oder SOCKS-Proxy-Server zu verwenden.

Target and deployment hosts can be configured to reach public internet resources via HTTP or SOCKS proxy server(s). OpenStack-Ansible may be used to configure target hosts to use the proxy server(s). OpenStack-Ansible does not provide automation for creating the proxy server(s).

Die anfängliche Host-Bereitstellung liegt außerhalb des Geltungsbereichs von OpenStack-Ansible, und der Deployer muss sicherstellen, dass eine Mindestanzahl von Proxy-Konfigurationen vorhanden ist, insbesondere für den System-Paket-Manager.

`` apt-get`` Proxy-Konfiguration

See Setting up apt-get to use a http-proxy

Andere Proxy-Konfiguration

In addition to this basic configuration, there are other network clients on the target hosts which may be configured to connect via a proxy. For example:

  • Die meisten Python-Netzwerkmodule

  • Curl

  • wget

  • openstack

Diese Tools und ihre zugrunde liegenden Bibliotheken werden von Ansible selbst und den OpenStack-Ansible-Playbooks verwendet. Daher muss eine Proxy-Konfiguration vorhanden sein, damit die Playbooks erfolgreich auf externe Ressourcen zugreifen können.

In der Regel lesen diese Tools Umgebungsvariablen mit Proxy-Server-Einstellungen. Diese Umgebungsvariablen können bei Bedarf in /etc/environment konfiguriert werden.

It is important to note that the proxy server should only be used to access external resources, and communication between the internal components of the OpenStack deployment should be direct and not through the proxy. The no_proxy environment variable is used to specify hosts that should be reached directly without going through the proxy. These often are the hosts in the management network.

OpenStack-Ansible bietet zwei verschiedene Mechanismen zum Konfigurieren von Proxyservereinstellungen:

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.

Der Deployer muss entscheiden, welcher dieser Ansätze für die Zielhosts besser geeignet ist, wobei folgende Hinweise zu berücksichtigen sind:

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.

Once the number of hosts/containers in a deployment reaches a certain size, the length of no_proxy will exceed 1024 characters at which point it is mandatory to use the transient proxy settings which only requires a subset of the management network IP addresses to be present in no_proxy at deployment time.

Siehe global_environment_variables: und deployment_environment_variables: im Beispiel user_variables.yml für Details zum Konfigurieren von persistenten und transienten Proxy-Umgebungsvariablen.

Deployment-Host-Proxy-Konfiguration für das Bootstrapping von Ansible

Konfigurieren Sie das Skript `` bootstrap-ansible.sh``, das zum Installieren der Abhängigkeiten von Ansible und Ansible auf dem Implementierungshost verwendet wird, um einen Proxy zu verwenden, indem Sie die Umgebungsvariablen `` HTTPS_PROXY`` oder `` HTTP_PROXY`` festlegen.

Bemerkung

Wir empfehlen, dass Sie Ihre `` / etc / environment``-Variablen mit Proxy-Einstellungen festlegen, bevor Sie Skripte oder Playbooks starten, um Fehler zu vermeiden.

In größeren oder komplexen Umgebungen ermöglicht ein dedizierter Bereitstellungshost die Verwendung der am besten geeigneten Proxykonfiguration für Implementierungs- und Zielhosts.

Überlegungen bei der Verwendung von TLS-Verkehr

Das Proxying von TLS-Datenverkehr beeinträchtigt häufig die Fähigkeit des Clients, eine erfolgreiche Validierung der Zertifikatskette durchzuführen. In den OpenStack-Ansible-Playbooks und Rollen gibt es verschiedene Konfigurationsvariablen, die es einem Implementierer ermöglichen, diese Validierungsfehler zu ignorieren. Finden Sie ein Beispiel /etc/openstack_deploy/user_variables.yml Konfiguration unten:

pip_validate_certs: false
galera_package_download_validate_certs: false

Die obige Liste ist absichtlich nicht erschöpfend. Zusätzliche Variablen können innerhalb des Projekts existieren und werden unter Verwendung des * _validate_cert-Musters benannt. Deaktivieren Sie die Zertifikatkettenüberprüfung von Fall zu Fall und nur nach dem Auftreten von Fehlern, von denen bekannt ist, dass sie nur von den Proxyservern verursacht werden.