Installation mit eingeschränkter Konnektivität¶

Viele Playbooks und Rollen in OpenStack-Ansible rufen standardmäßig Abhängigkeiten vom öffentlichen Internet ab. Bei den Beispielkonfigurationen wird davon ausgegangen, dass der Deployer über einen Router im OpenStack-Verwaltungsnetzwerk eine Internetverbindung mit guter Qualität bereitstellt.

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

Wir empfehlen eine Reihe von Vorgehensweisen und Konfigurations-Overrides, die von den Deployern bei der Ausführung von OpenStack-Ansible in Netzwerkumgebungen verwendet werden können, die die Internetverbindung blockieren.

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¶

Viele Pakete, die OpenStack ausführen, werden mit pip installiert. Wir empfehlen, den PyPi-Paket-Index, der von pip verwendet wird, zu spiegeln. Ein Deployer kann wählen, ob er das gesamte vorgelagerte PyPi-Repository aktiv spiegeln soll, aber dies kann eine erhebliche Menge an Speicher erfordern. Alternativ kann ein Caching-Pip-Proxy verwendet werden, um lokale Kopien nur der Pakete beizubehalten, die benötigt werden.

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

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

Then, in /etc/openstack_deploy/user_variables.yml, inform the deployment that it needs to copy that file 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

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 zum Spiegeln von Ubuntu 18.04 LTS:

bionic
bionic-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.

Die Konfiguration kann auf Ziel- und Deployment-Hosts angewendet werden, um öffentliche Internet-Ressourcen über HTTP- oder SOCKS-Proxy-Server zu erreichen. OpenStack-Ansible kann verwendet werden, um Zielhosts für die Verwendung des / der Proxy-Server zu konfigurieren. OpenStack-Ansible bietet keine Automatisierung zum Erstellen des / der Proxy-Server.

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¶

Siehe Einrichten von apt-get für die Verwendung eines http-proxy

Andere Proxy-Konfiguration¶

Zusätzlich zu dieser grundlegenden Konfiguration befinden sich auf den Zielhosts weitere Netzwerkclients, die für die Verbindung über einen Proxy konfiguriert werden können. Beispielsweise:

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.

Es ist wichtig zu beachten, dass der Proxy-Server nur für den Zugriff auf externe Ressourcen verwendet werden sollte und dass die Kommunikation zwischen den internen Komponenten der OpenStack-Bereitstellung direkt erfolgen sollte, ohne den Proxy zu durchlaufen. Die Umgebungsvariable `` no_proxy`` wird verwendet, um Hosts anzugeben, die direkt erreicht werden sollen, ohne den Proxy zu durchlaufen. Diese sind oft die Hosts im Management-Netzwerk.

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

#. 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.

#. 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:

#. Persistent proxy configuration is a standard practice and network clients on the target hosts will be able to access external resources after deployment.

#. 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.

#. 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.

#. 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.

Sobald die Anzahl der Hosts / Container in einer Bereitstellung eine bestimmte Größe erreicht, überschreitet die Länge von no_proxy 1024 Zeichen. Es ist dann zwingend erforderlich, die transienten Proxy-Einstellungen zu verwenden, die nur eine Teilmenge der IP-Adressen des Verwaltungsnetzwerks benötigen, um zum Zeitpunkt der Bereitstellung in `` no_proxy`` vorhanden zu sein.

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.