[ English | Indonesia | français | Deutsch | English (United Kingdom) | 한국어 (대한민국) | español | русский ]
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 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.
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¶
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.