[ English | Deutsch | español | Indonesia | English (United Kingdom) | русский ]
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/2024.2 # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout 30.0.0.0rc1
Bemerkung
The 2024.2 release is only compatible with Debian 12 (bookworm), Ubuntu 22.04 (Jammy Jellyfish), Ubuntu 24.04 (Noble Numbat), 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_lxb'
# 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:
# openstack-ansible openstack.osa.setup_hosts
# openstack-ansible openstack.osa.setup_infrastructure
# openstack-ansible openstack.osa.setup_openstack
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
Interacting with an AIO¶
Once an AIO has been deployed, you most likely want to interact with it. You can do this via the web interface or one of the many clients or libraries that exist for OpenStack.
Using a GUI¶
The horizon web interface provides a graphical interface for interacting with the AIO deployment. By default, the horizon API is available on port 443 of the host (or port 80, if SSL certificate configuration was disabled). As such, to interact with horizon, simply browse to the IP of the host.
Bemerkung
If the AIO was deployed in a cloud VM, you may need to configure security groups or firewall rules to allow access to the HTTP(S) ports. For example, if the AIO was deployed in an OpenStack VM, you can create and apply a suitable security group for interacting with horizon like so:
$ openstack security group create http \
--description 'Allow HTTP and HTTPS access'
$ openstack security group rule create http \
--protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
$ openstack security group rule create http \
--protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0
$ openstack server add security group $SERVER http
A list of service ports can be found in the OpenStack Install Guide.
This will present a login page. By default, OpenStack-Ansible create a user
called admin. The password will be the value of the
keystone_auth_admin_password variable. If you did not configure this
variable, OpenStack-Ansible auto-generates one. You can view the configured
password in the /etc/openstack_deploy/user_secrets.yml file.
# grep admin_pass /etc/openstack_deploy/user_secrets.yml
heat_stack_domain_admin_password: <redacted>
keystone_auth_admin_password: <redacted>
radosgw_admin_password: <redacted>
Using this username and password combination, log in to horizon.
Using a client or library¶
There are a variety of clients and libraries available for interacting with an
OpenStack deployment, including as openstackclient, openstacksdk, or
gophercloud. These are typically configured using either environment
variables sourced from an openrc file or the newer clouds.yaml file.
OpenStack-Ansible provides the openstack_openrc role for creating these
configuration files as well as a number of utilities such as openstackclient.
If the AIO deployment using the lxc scenario (the default), these will be
availably in the utility container.
$ lxc-attach -n `lxc-ls -1 | grep utility`
# ls /root/openrc
/root/openrc
# ls /root/.config/openstack/clouds.yaml
/root/.config/openstack/clouds.yaml
# export OS_CLOUD=default
# openstack project list -c Name -f value
service
admin
Alternatively, if the AIO was deployed using the metal scenario, these
files will be available on the host itself.
# ls /root/openrc
/root/openrc
# ls /root/.config/openstack/clouds.yaml
/root/.config/openstack/clouds.yaml
If you wish to access the AIO deployment from another host - perhaps your local
workstation - you will need either an openrc file or clouds.yaml file.
You can download an openrc file from horizon: simply click the User
dropdown in the top-right corner and select ⭳ OpenStack RC file.
Wichtig
You may be tempted to copy the openrc or clouds.yaml files created
by the openstack_openrc role. However, these files use the internal
interface by default. This interface use the management network
(172.29.236.0/22) , which is not routable from outside the host. If you
wish to use these files, you will need to change the interface to
public.
Bemerkung
If the AIO was deployed in a cloud VM, you may need to configure security groups or firewall rules to allow access to the various sevice ports. For example, if the AIO was deployed in an OpenStack VM, you can create and apply a suitable security group for interacting the core services like so:
$ openstack security group create openstack-apis \
--description 'Allow access to various OpenStack services'
$ for port in 8774 8776 9292 9696 5000 8780; do
openstack security group rule create openstack-apis \
--protocol tcp --dst-port ${port}:${port} --remote-ip 0.0.0.0/0
done
$ openstack server add security group $SERVER openstack-apis
A list of service ports can be found in the OpenStack Install Guide.
Bemerkung
If you have enabled SSL certificate configuration (default), all services
will use self-signed certificates. While the host is configured to trust
these certificates, this is not the case for other hosts. This will result
in HTTPS errors when attempting to interact with the cloud. To resolve this
issue, you will need to manually configure certificates on other hosts or
ignore SSL issues. To use the self-signed certificate, first copy it to the
other hosts. The name and location of the generated certificate are
configured by the pki_authorities and pki_trust_store_location
variables respectively, which are used by the pki role provided by
ansible-role-pki. On an Ubuntu 22.04 host, these will default to
ExampleCorpRoot and /usr/local/share/ca-certificates, respectively.
For example:
$ scp aio:/usr/local/share/ca-certificates/ExampleCorpRoot.crt ~/.config/openstack/aio.crt
Once this is done, configure the cacert value in the the definition for
your cloud in clouds.yaml. For example:
clouds:
aio:
# ...
cacert: /home/<username>/.config/openstack/aio.crt
Alternatively, you can simply ignore SSL issues by setting verify: false
in the definition for your cloud in clouds.yaml. This will disable SSL
verification entirely for this cloud. For example:
clouds:
aio:
# ...
verify: false
Finally, you can also opt to disable SSL certificate configuration during initial deployment or opt to use an external certificate authority for signing, such as Lets Encrypt. Both topics are outside the scope of this document.
More information about SSL certificate configuration can be found in the security guide.
Once one of these files have been created, you can use it to interact with your deployment using most standard clients and libraries. For example, to list available projects using openstackclient:
$ export OS_CLOUD=aio
$ openstack project list -c Name -f value
service
admin
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 ]-
