Schnellstart: AIO¶

All-in-One-Builds (AIO-Builds) sind eine hervorragende Möglichkeit, OpenStack-Ansible-Builds für Folgendes auszuführen:

eine Entwicklungsumgebung
ein Überblick darüber, wie alle OpenStack-Services zusammenpassen
eine einfache Laborbereitstellung

Obwohl AIO-Builds nicht für große Produktionsbereitstellungen empfohlen werden, eignen sie sich hervorragend für kleinere Proof-of-Concept-Bereitstellungen.

Absolute minimale Serverressourcen (derzeit für Gate-Checks verwendet):

8 vCPUs
50 GB freier Speicherplatz auf der Root-Partition
8 GB RAM

Empfohlene Serverressourcen:

CPU / Motherboard, das Hardware-unterstützte Virtualisierung unterstützt
8 CPU-Kerne
80 GB freier Speicherplatz auf der Root-Partition oder 60 GB auf einer leeren sekundären Festplatte. Die Verwendung eines sekundären Laufwerks erfordert die Verwendung des Parameters `` bootstrap_host_data_disk_device``. Weitere Informationen finden Sie unter Erstellen eines AIO.
16 GB RAM

Es ist möglich, AIO-Builds zur Demonstration und Bewertung in einer virtuellen Maschine auszuführen. Die Leistung Ihrer virtuellen Maschinen ist jedoch schlecht, wenn keine verschachtelten Virtualisierungen verfügbar sind. Für Produktions-Workloads werden mehrere Knoten für bestimmte Rollen empfohlen.

Ein AIO bauen¶

Übersicht¶

Es gibt drei Schritte zum Ausführen eines AIO-Builds mit einem optionalen ersten Schritt, falls Sie Ihren Build anpassen müssen:

Den Host vorbereiten
Ansible bootstrappen und die erforderlichen Rollen
Bootstrappen der AIO Konfiguration
Führe Playbooks aus

Den Host vorbereiten¶

Wenn Sie ein AIO auf einem neuen Server erstellen, wird empfohlen, dass alle Systempakete aktualisiert werden und anschließend in den neuen Kernel neu gestartet werden:

Bemerkung

Führen Sie die folgenden Befehle und Skripts als Root-Benutzer aus.

## Ubuntu / Debian
# apt-get update
# apt-get dist-upgrade
# reboot

## CentOS / Rocky Linux
# dnf upgrade
# dnf install git-core
# systemctl stop firewalld
# systemctl mask firewalld
# reboot

Bemerkung

Before rebooting, in /etc/sysconfig/selinux, make sure that SELINUX=enforcing is changed to SELINUX=disabled. SELinux enabled is not currently supported in OpenStack-Ansible for CentOS/Rocky/RHEL due to a lack of maintainers for the feature.

Bemerkung

If you are installing with limited connectivity, please review Installing with limited connectivity before proceeding.

Ansible bootstrappen und die erforderlichen Rollen¶

Klonen Sie zunächst das OpenStack-Ansible-Repository und wechseln Sie in das Repository-Stammverzeichnis:

# git clone https://opendev.org/openstack/openstack-ansible \
    /opt/openstack-ansible
# cd /opt/openstack-ansible

Als Nächstes wechseln Sie den zutreffenden Zweig / Tag, von dem die Bereitstellung erfolgen soll. Beachten Sie, dass das Deployment vom Kopf eines Zweiges zu einem instabilen Build aufgrund von Änderungen im Flug und Upstream-Änderungen führen kann. Für einen Test (zum Beispiel keine Entwicklung) ist es normalerweise am besten, die neueste getaggte Version auszuprobieren.

# # List all existing tags.
# git tag -l

# # Checkout the stable branch and find just the latest tag
# git checkout stable/yoga
# git describe --abbrev=0 --tags

# # Checkout the latest tag from either method of retrieving the tag.
# git checkout yoga-eom

Bemerkung

The Yoga release is only compatible with Debian 11 (bullseye), Ubuntu 20.04 (Focal Fossa), CentOS 8 Stream, CentOS 9 Stream and derivitives of CentOS Stream/RHEL such as Rocky Linux.

Der nächste Schritt ist das Bootstrappen von Ansible und die Ansible-Rollen für die Entwicklungsumgebung

Rufen Sie Folgendes auf zum Boostrappen von Ansible und den erforderlichen Rollen:

# scripts/bootstrap-ansible.sh

Bemerkung

Möglicherweise tritt beim Ausführen des Ansible-Bootstrap-Skripts beim Erstellen einiger Python-Erweiterungen (wie pycrypto) ein Fehler auf, der besagt:

configure: error: cannot run C compiled programs.

Der Grund für diesen Fehler liegt möglicherweise in einem noexec-Mount-Flag, das für das Dateisystem verwendet wird, das /tmp zugeordnet ist. Sie können dies überprüfen, indem Sie den folgenden Befehl ausführen:

# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec

Wenn dies der Fall ist, können Sie einen alternativen Pfad angeben, für den diese Mount-Option nicht festgelegt ist:

# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh

Bootstrappen der AIO Konfiguration¶

Damit alle Dienste ausgeführt werden können, muss der Host mit den entsprechenden Festplattenpartitionierungen, Paketen, Netzwerkkonfigurationen und Konfigurationen für die OpenStack-Bereitstellung vorbereitet sein.

Standardmässig installiert das AIO Bootstrap Script ein Basisset von OpenStack Diensten mit sensiblen Einstellungen für den Gate-Check, Entwicklung- oder Test-Systeme.

Überprüfen Sie die bootstrap-host role defaults Datei, um verschiedene Konfigurationsoptionen anzuzeigen. Bereitsteller haben die Möglichkeit zu ändern, wie der Host bootstrapped wird. Dies ist nützlich, wenn Sie möchten, dass das AIO eine sekundäre Datenfestplatte verwendet oder wenn Sie diese Rolle zum Bootstrap einer Entwicklungsumgebung mit mehreren Knoten verwenden.

Das Bootstrap-Skript ist voreingestellt, um die Umgebungsvariable `` BOOTSTRAP_OPTS`` als zusätzliche Option an den Bootstrap-Prozess zu übergeben. Wenn Sie beispielsweise festlegen möchten, dass der Bootstrap ein bestimmtes sekundäres Speichergerät (/dev /sdb) neu partitioniert, wodurch alle Daten auf dem Gerät gelöscht werden, führen Sie Folgendes aus:

# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"

Zusätzliche Optionen können implementiert werden, indem sie einfach mit einem Leerzeichen zwischen den einzelnen Optionen verknüpft werden, z. B .:

# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
# export BOOTSTRAP_OPTS="${BOOTSTRAP_OPTS} bootstrap_host_data_disk_fs_type=xfs"

If you are installing with limited connectivity, or you don’t have default route set, you will need to define interface for outgoing connections manually

# export BOOTSTRAP_OPTS="bootstrap_host_public_interface=eth1"

Für das Standard-AIO-Szenario wird die Vorbereitung der AIO-Konfiguration abgeschlossen, indem Sie Folgendes ausführen:

# scripts/bootstrap-aio.sh

Um OpenStack Services über die Bootstrap-aio Default Services für das entsprechende Szenario hinzuzufügen, kopieren Sie die` conf.d`-Dateien mit der Dateierweiterung` aio` nach` /etc/openstack_deploy` und benenne sie dann in .yml -Dateien um. Um beispielsweise die OpenStack Telemetrie-Dienste zu aktivieren, führen Sie Folgendes aus:

# cd /opt/openstack-ansible/
# cp etc/openstack_deploy/conf.d/{aodh,gnocchi,ceilometer}.yml.aio /etc/openstack_deploy/conf.d/
# for f in $(ls -1 /etc/openstack_deploy/conf.d/*.aio); do mv -v ${f} ${f%.*}; done

It is possible to also do this (and change other defaults) during the bootstrap script initial execution by changing the SCENARIO environment variable before running the script. The key word ‚aio‘ will ensure that a basic set of OpenStack services (cinder, glance, horizon, neutron, nova) will be deployed. The key words ‚lxc‘ can be used to set the container back-end, while the key word ‚metal‘ will deploy all services without containers. In order to implement any other services, add the name of the conf.d file name without the .yml.aio extension into the SCENARIO environment variable. Each key word should be delimited by an underscore. For example, the following will implement an AIO with barbican, cinder, glance, horizon, neutron, and nova. It will set the cinder storage back-end to ceph and will make use of LXC as the container back-end.

# export SCENARIO='aio_lxc_barbican_ceph'
# scripts/bootstrap-aio.sh

To add any global overrides, over and above the defaults for the applicable scenario, edit /etc/openstack_deploy/user_variables.yml. In order to understand the various ways that you can override the default behaviour set out in the roles, playbook and group variables, see Überschreiben der Standardkonfiguration.

Schauen Sie Deployment Guide für mehr Informationen, wie Ihre eigene Konfiguration in AIP Boostrap zu verwenden ist.

Führe Playbooks aus¶

Führen Sie abschließend die Playbooks aus, indem Sie Folgendes ausführen:

# cd /opt/openstack-ansible/playbooks
# openstack-ansible setup-hosts.yml
# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml

Der Installationsvorgang wird einige Zeit in Anspruch nehmen, aber hier einige allgemeine Schätzungen:

Bare-Metal-Systeme mit SSD-Speicher: ~ 30-50 Minuten
Virtuelle Maschinen mit SSD-Speicher: ~ 45-60 Minuten
Systeme mit traditionellen Festplatten: ~ 90-120 Minuten

Sobald die Playbooks vollständig ausgeführt wurden, ist es möglich, mit verschiedenen Einstellungsänderungen in /etc/openstack_deploy/user_variables.yml zu experimentieren und nur einzelne Playbooks auszuführen. Um beispielsweise das Playbook für den Keystone-Service auszuführen, führen Sie Folgendes aus:

# cd /opt/openstack-ansible/playbooks
# openstack-ansible os-keystone-install.yml

Neustart eines AIO¶

Da die AIO alle drei Cluster-Mitglieder von MariaDB / Galera umfasst, muss der Cluster nach dem Neustart des Hosts neu initialisiert werden.

Dies geschieht, indem Sie Folgendes ausführen:

# cd /opt/openstack-ansible/playbooks
# openstack-ansible -e galera_ignore_cluster_state=true galera-install.yml

If this fails to get the database cluster back into a running state, then please make use of the Galera Cluster Recovery section in the operations guide.

Wiederaufbau eines AIO¶

Manchmal kann es nützlich sein, alle Container zu zerstören und das AIO neu aufzubauen. Während es bevorzugt wird, dass der AIO vollständig zerstört und neu aufgebaut wird, ist dies nicht immer praktisch. Daher kann stattdessen Folgendes ausgeführt werden:

# # Move to the playbooks directory.
# cd /opt/openstack-ansible/playbooks

# # Destroy all of the running containers.
# openstack-ansible lxc-containers-destroy.yml

# # On the host stop all of the services that run locally and not
# #  within a container.
# for i in \
       $(ls /etc/init \
         | grep -e "nova\|swift\|neutron\|cinder" \
         | awk -F'.' '{print $1}'); do \
    service $i stop; \
  done

# # Uninstall the core services that were installed.
# for i in $(pip freeze | grep -e "nova\|neutron\|keystone\|swift\|cinder"); do \
    pip uninstall -y $i; done

# # Remove crusty directories.
# rm -rf /openstack /etc/{neutron,nova,swift,cinder} \
         /var/log/{neutron,nova,swift,cinder}

# # Remove the pip configuration files on the host
# rm -rf /root/.pip

# # Remove the apt package manager proxy
# rm /etc/apt/apt.conf.d/00apt-cacher-proxy

Wenn eine vorhandene AIO-Umgebung neu installiert werden muss, besteht die effizienteste Methode darin, das Host-Betriebssystem zu zerstören und neu zu starten. Aus diesem Grund werden AIOs am besten in Form einer virtuellen Maschine oder eines Cloud-Gastes ausgeführt.

Referenzdiagramm für einen AIO Build¶

Hier ist ein grundlegendes Diagramm, das versucht zu veranschaulichen, wie die resultierende AIO-Bereitstellung aussieht.

Dieses Diagramm ist nicht maßstabsgetreu und nicht einmal 100% genau. Dieses Diagramm wurde nur zu Informationszwecken erstellt und sollte ** NUR ** als solches verwendet werden.

          ------->[ ETH0 == Public Network ]
          |
          V                        [  *   ] Socket Connections
[ HOST MACHINE ]                   [ <>v^ ] Network Connections
  *       ^  *
  |       |  |-------------------------------------------------------
  |       |                                                         |
  |       |---------------->[ HAProxy ]                             |
  |                                 ^                               |
  |                                 |                               |
  |                                 V                               |
  |                          (BR-Interfaces)<------                 |
  |                                  ^     *      |                 |
  *-[ LXC ]*--*----------------------|-----|------|----|            |
  |           |                      |     |      |  | |            |
  |           |                      |     |      |  | |            |
  |           |                      |     |      |  | |            |
  |           |                      |     |      V  * |            |
  |           *                      |     |   [ Galera x3 ]        |
  |        [ Memcached ]<------------|     |           |            |
  *-------*[ Rsyslog ]<--------------|--|  |           *            |
  |        [ Repos Server x3 ]<------|  ---|-->[ RabbitMQ x3 ]      |
  |        [ Horizon x2 ]<-----------|  |  |                        |
  |        [ Nova api ec2 ]<---------|--|  |                        |
  |        [ Nova api os ]<----------|->|  |                        |
  |        [ Nova console ]<---------|  |  |                        |
  |        [ Nova Cert ]<------------|->|  |                        |
  |        [ Cinder api ]<-----------|->|  |                        |
  |        [ Glance api ]<-----------|->|  |                        |
  |        [ Heat apis ]<------------|->|  | [ Loop back devices ]*-*
  |        [ Heat engine ]<----------|->|  |    \        \          |
  | ------>[ Nova api metadata ]     |  |  |    { LVM }  { XFS x3 } |
  | |      [ Nova conductor ]<-------|  |  |       *         *      |
  | |----->[ Nova scheduler ]--------|->|  |       |         |      |
  | |      [ Keystone x3 ]<----------|->|  |       |         |      |
  | | |--->[ Neutron agents ]*-------|--|---------------------------*
  | | |    [ Neutron server ]<-------|->|          |         |      |
  | | | |->[ Swift proxy ]<-----------  |          |         |      |
  *-|-|-|-*[ Cinder volume ]*----------------------*         |      |
  | | | |                               |                    |      |
  | | | -----------------------------------------            |      |
  | | ----------------------------------------- |            |      |
  | |          -------------------------|     | |            |      |
  | |          |                              | |            |      |
  | |          V                              | |            *      |
  ---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-

Schnellstart: AIO

Schnellstart: AIO¶

Ein AIO bauen¶

Übersicht¶

Den Host vorbereiten¶

Ansible bootstrappen und die erforderlichen Rollen¶

Bootstrappen der AIO Konfiguration¶

Führe Playbooks aus¶

Neustart eines AIO¶

Wiederaufbau eines AIO¶

Referenzdiagramm für einen AIO Build¶

openstack-ansible 25.6.1.dev7

Page Contents