[ English | русский | español | Indonesia | English (United Kingdom) | Deutsch ]
Quickstart: AIO¶
Pembuatan All-in-one (AIO) adalah cara yang bagus untuk melakukan pembangunan OpenStack-Ansible untuk:
lingkungan pengembangan
gambaran umum tentang bagaimana semua layanan OpenStack cocok bersama
penyebaran laboratorium sederhana
Meskipun build AIO tidak direkomendasikan untuk penyebaran produksi besar, mereka sangat bagus untuk penyebaran konsep-konsep yang lebih kecil.
Sumber daya server minimum absolut (saat ini digunakan untuk pemeriksaan gate):
8 vCPU's
Ruang disk kosong 50GB pada partisi root
8GB RAM
Sumber daya server yang direkomendasikan:
CPU/motherboard yang mendukung hardware-assisted virtualization
8 CPU Cores
80GB ruang kosong pada partisi root, atau 60GB + pada disk sekunder kosong. Menggunakan disk sekunder membutuhkan penggunaan parameter
bootstrap_host_data_disk_device. Silakan lihat Building an AIO untuk detail lebih lanjut.16GB RAM
Sangat mungkin untuk melakukan build AIO di dalam mesin virtual untuk demonstrasi dan evaluasi, tetapi mesin virtual Anda akan berkinerja buruk kecuali jika tersedia virtualisasi bersarang. Untuk beban kerja produksi, beberapa node untuk role tertentu direkomendasikan.
Membangun AIO¶
Ikhtisar¶
Ada tiga langkah untuk menjalankan build AIO, dengan langkah pertama opsional jika Anda perlu menyesuaikan build Anda:
Siapkan host
Bootstrap Ansible dan role yang diperlukan
Bootstrap konfigurasi AIO
Jalankan playbook
Siapkan host¶
Ketika membangun AIO di server baru, disarankan agar semua paket sistem ditingkatkan dan kemudian reboot ke kernel baru:
Catatan
Jalankan perintah dan skrip berikut sebagai pengguna root.
## 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
Catatan
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.
Catatan
If you are installing with limited connectivity, please review Installing with limited connectivity before proceeding.
Bootstrap Ansible dan role yang diperlukan¶
Mulailah dengan menggandakan repositori OpenStack-Ansible dan mengubah ke direktori root repositori:
# git clone https://opendev.org/openstack/openstack-ansible \
/opt/openstack-ansible
# cd /opt/openstack-ansible
Selanjutnya, pindahkan branch/tag yang berlaku untuk dikerahkan. Perhatikan bahwa penerapan dari kepala cabang (head of a branch) dapat mengakibatkan pembangunan yang tidak stabil karena perubahan dalam flight dan perubahan OpenStack di hulu. Untuk tes (misalnya, bukan pengembangan) membangunnya biasanya lebih baik untuk memeriksa versi tag terbaru.
# # List all existing tags. # git tag -l # # Checkout the stable branch and find just the latest tag # git checkout stable/2024.1 # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout 29.1.0
Catatan
The 2024.1 release is only compatible with Debian 11 (bullseye), Debian 12 (bookworm), Ubuntu 22.04 (Jammy Jellyfish), CentOS 9 Stream, and derivitives of CentOS Stream/RHEL such as Rocky Linux.
Langkah selanjutnya adalah untuk bootstrap Ansible dan peran Ansible untuk lingkungan pengembangan.
Jalankan berikut ini untuk bootstrap Ansible dan peran (role) yang diperlukan:
# scripts/bootstrap-ansible.sh
Catatan
Anda mungkin mengalami kesalahan saat menjalankan skrip bootstrap Ansible saat membuat beberapa ekstensi Python (seperti pycrypto) yang mengatakan:
configure: error: cannot run C compiled programs.
Alasan kegagalan ini mungkin disebabkan oleh flag mount noexec yang digunakan untuk filesystem yang terkait dengan /tmp yang dapat Anda periksa dengan menjalankan perintah berikut:
# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec
Jika ini adalah kasus Anda dapat menentukan jalur alternatif yang tidak memiliki opsi mount ini diatur:
# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh
Bootstrap konfigurasi AIO¶
Agar semua layanan berjalan, host harus dipersiapkan dengan partisi disk, paket, konfigurasi jaringan dan konfigurasi yang tepat untuk OpenStack Deployment.
Secara default skrip bootstrap AIO menggunakan set dasar layanan OpenStack dengan default yang masuk akal untuk tujuan pemeriksaan gerbang (gate check), pengembangan atau sistem pengujian.
Tinjau strstrstrap-host role defaults file untuk melihat berbagai opsi konfigurasi. Deployer memiliki opsi untuk mengubah cara host ditopang bootstrap. Ini berguna ketika Anda ingin AIO menggunakan disk data sekunder, atau ketika menggunakan peran ini untuk bootstrap lingkungan pengembangan multi-node.
Skrip bootstrap telah ditetapkan sebelumnya untuk meneruskan variabel lingkungan BOOTSTRAP_OPTS sebagai opsi tambahan untuk proses bootstrap. Misalnya, jika Anda ingin mengatur bootstrap untuk mempartisi ulang perangkat penyimpanan sekunder khusus (/dev/sdb), yang akan menghapus semua data pada perangkat, kemudian jalankan:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
Opsi tambahan dapat diimplementasikan hanya dengan menggabungkannya dengan spasi di antara setiap rangkaian opsi, misalnya:
# 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"
Untuk skenario AIO default, persiapan konfigurasi AIO akan selesai dengan mengeksekusi:
# scripts/bootstrap-aio.sh
Untuk menambahkan OpenStack Service di atas dan di atas layanan default bootstrap-aio untuk skenario yang berlaku, salin file conf.d dengan ekstensi file `` .aio`` ke /etc/openstack_deploy dan ganti nama kemudian ke file .yml. Misalnya, untuk mengaktifkan layanan Telemetri OpenStack, jalankan yang berikut:
# 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
Untuk menambahkan global override, melebihi dan di atas default untuk skenario yang berlaku, edit /etc/openstack_deploy/user_variables.yml. Untuk memahami berbagai cara agar Anda dapat menimpa perilaku default yang ditetapkan dalam variabel role, playbook, dan grup, lihat Mengganti konfigurasi default.
Lihat Deployment Guide untuk perincian yang lebih rinci tentang bagaimana menerapkan konfigurasi Anda sendiri daripada menggunakan bootstrap AIO.
Jalankan playbook¶
Akhirnya, jalankan playbook dengan mengeksekusi:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible setup-hosts.yml
# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml
Proses instalasi akan memakan waktu cukup lama untuk diselesaikan, tetapi berikut adalah beberapa perkiraan umum:
Sistem bare metal dengan penyimpanan SSD: ~ 30-50 menit
Mesin virtual dengan penyimpanan SSD: ~ 45-60 menit
Sistem dengan hard disk tradisional: ~ 90-120 menit
Setelah playbook sepenuhnya dieksekusi, adalah mungkin untuk bereksperimen dengan berbagai perubahan pengaturan di /etc/openstack_deploy/user_variables.yml dan hanya menjalankan playbook individu. Misalnya, untuk menjalankan pedoman untuk layanan Keystone, laksanakan:
# 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.
Catatan
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.
Penting
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.
Catatan
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.
Catatan
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
Mem-boot ulang AIO¶
Karena AIO mencakup ketiga anggota cluster MariaDB/Galera, cluster harus diinisialisasi ulang setelah host di-reboot.
Ini dilakukan dengan mengeksekusi yang berikut:
# 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.
Membangun kembali AIO¶
Kadang-kadang mungkin berguna untuk menghancurkan semua kontainer dan membangun kembali AIO. Meskipun lebih disukai bahwa AIO sepenuhnya dihancurkan dan dibangun kembali, ini tidak selalu praktis. Karena itu, hal-hal berikut dapat dieksekusi sebagai gantinya:
# # 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
Jika lingkungan AIO yang ada perlu diinstal ulang, metode yang paling efisien adalah menghancurkan sistem operasi host dan memulai kembali. Untuk alasan ini, AIO paling baik dijalankan di dalam beberapa bentuk mesin virtual (virtual machine) atau cloud guest.
Referensi Diagram untuk AIO Build¶
Berikut ini adalah diagram dasar yang mencoba untuk menggambarkan apa yang dihasilkan penyebaran AIO yang dihasilkan.
Diagram ini tidak untuk skala dan bahkan tidak 100% akurat, diagram ini dibangun hanya untuk tujuan informasi dan seharusnya ONLY digunakan seperti itu.
------->[ 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 ]-
