[ English | English (United Kingdom) | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]
Mengkonfigurasi inventory¶
Dalam bab ini, Anda dapat menemukan informasi tentang cara mengonfigurasikan dynamic inventory openstack-ansible untuk kebutuhan Anda.
Pengantar¶
Layanan OpenStack umum dan konfigurasinya ditentukan oleh OpenStack-Ansible di file pengaturan /etc/openstack_deploy/openstack_user_config.yml
.
Layanan tambahan harus didefinisikan dengan file YAML di /etc/openstack_deploy/conf.d
, untuk mengelola ukuran file.
Direktori /etc/openstack_deploy/env.d
sumber semua file YAML ke dalam lingkungan yang digunakan, yang memungkinkan seorang deployer untuk menentukan pemetaan grup tambahan. Direktori ini digunakan untuk memperluas kerangka lingkungan, atau memodifikasi default yang ditentukan dalam direktori inventory/env.d
.
Untuk memahami cara kerja inventaris dinamis, lihat Memahami inventory.
Peringatan
Jangan pernah mengedit atau menghapus file /etc/openstack_deploy/openstack_inventory.json
atau /etc/openstack_deploy/openstack_hostnames_ips.yml
. Ini dapat menyebabkan file korup, dan masalah dengan inventory: host dan kontainer bisa menghilang dan yang baru akan muncul, merusak deployment Anda yang ada.
Kendala konfigurasi¶
Keanggotaan grup¶
Saat menambahkan grup, perhatikan hal berikut:
Grup dapat berisi host
Grup dapat berisi grup anak (child group)
Namun, grup tidak dapat berisi grup anak dan host.
Grup lxc_hosts¶
Ketika skrip inventory dinamis membuat nama container, host tempat container tersebut ditambahkan ke grup inventory lxc_hosts
.
Menggunakan nama ini untuk grup dalam konfigurasi akan menghasilkan kesalahan runtime.
Deploying langsung pada host¶
Untuk menggunakan komponen secara langsung pada host daripada di dalam sebuah container, atur properti is_metal
menjadi true
untuk grup kontainer di bagian container_skel
dalam file yang sesuai.
Penggunaan container_vars
dan pemetaan dari grup container ke grup host sama dengan layanan yang disebarkan langsung ke host.
Anda juga dapat menggunakan opsi no_containers
untuk menentukan host yang akan menggunakan semua layanan yang dikerahkan pada metal di dalamnya.
Catatan
Komponen cinder-volume
digunakan secara langsung pada host secara default. Lihat file env.d/cinder.yml
untuk contoh ini.
Contoh: Menjalankan semua pengontrol pada metal¶
Misalnya, jika Anda ingin menjalankan semua pengontrol Anda pada logam, Anda akan memiliki yang berikut di dalam openstack_user_config.yml
Anda.
infra_hosts: infra1: ip: 172.39.123.11 no_containers: true infra2: ip: 172.39.123.12 no_containers: true infra3: ip: 172.39.123.13 no_containers: true
Contoh: Menjalankan galera pada host khusus (dedicated host)¶
Misalnya, untuk menjalankan Galera langsung pada host khusus, Anda akan melakukan langkah-langkah berikut:
Ubah bagian
container_skel
dari fileenv.d/galera.yml
. Sebagai contoh:container_skel: galera_container: belongs_to: - db_containers contains: - galera properties: is_metal: true
Catatan
Untuk menggunakan dalam container pada host khusus ini, abaikan properti
is_metal: true
.Tetapkan grup container
db_containers
(dari langkah sebelumnya) ke grup host dengan memberikan bagianphysical_skel
untuk grup host dalam file baru atau yang sudah ada, sepertienv.d/galera.yml
. Sebagai contoh:physical_skel: db_containers: belongs_to: - all_containers db_hosts: belongs_to: - hosts
Tentukan grup host (
db_hosts
) dalam fileconf.d/
(sepertigalera.yml
). Sebagai contoh:db_hosts: db-host1: ip: 172.39.123.11 db-host2: ip: 172.39.123.12 db-host3: ip: 172.39.123.13
Catatan
Setiap nama grup kustom dalam contoh ini (
db_containers
dandb_hosts
) adalah arbitrer. Pilih nama grup Anda sendiri, tetapi pastikan referensi konsisten di antara semua file yang relevan.
Menyebarkan 0 (atau lebih dari satu) tipe komponen per host¶
Ketika OpenStack-Ansible menghasilkan inventaris dinamisnya, pengaturan affinity (pertalian) menentukan berapa banyak kontainer dari jenis yang sama yang digunakan pada satu host fisik.
Dengan menggunakan shared-infra_hosts
sebagai contoh, pertimbangkan konfigurasi openstack_user_config.yml
ini:
shared-infra_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
Tiga host ditugaskan ke grup shared-infra_hosts, OpenStack-Ansible memastikan bahwa setiap host menjalankan kontainer basis data tunggal, kontainer Memcached tunggal, dan kontainer RabbitMQ tunggal. Setiap host memiliki afinitas 1 secara default, yang berarti bahwa setiap host menjalankan satu dari setiap jenis kontainer.
Jika Anda menggunakan lingkungan Object Storage (swift) yang berdiri sendiri, Anda dapat melewati penerapan RabbitMQ. Jika Anda menggunakan konfigurasi ini, file openstack_user_config.yml
Anda akan terlihat seperti berikut:
shared-infra_hosts:
infra1:
affinity:
rabbit_mq_container: 0
ip: 172.29.236.101
infra2:
affinity:
rabbit_mq_container: 0
ip: 172.29.236.102
infra3:
affinity:
rabbit_mq_container: 0
ip: 172.29.236.103
Konfigurasi ini menyebarkan kontainer Memcached dan kontainer basis data pada setiap host, tetapi tidak ada kontainer RabbitMQ.
Hapus layanan atau komponen dari penerapan¶
Untuk menghilangkan komponen dari penerapan, Anda dapat menggunakan salah satu dari beberapa opsi:
Hapus tautan
physical_skel
antara grup kontainer dan grup host dengan menghapus file terkait yang terletak di direktorienv.d/
.Jangan jalankan playbook yang menginstal komponen. Kecuali Anda menentukan komponen untuk dijalankan secara langsung pada host dengan menggunakan properti
is_metal
, sebuah kontainer dibuat untuk komponen ini.Sesuaikan Menyebarkan 0 (atau lebih dari satu) tipe komponen per host ke 0 untuk grup host. Mirip dengan opsi kedua yang tercantum di sini, Kecuali Anda menentukan komponen untuk dijalankan secara langsung pada host dengan menggunakan properti
is_metal
, sebuah kontainer dibuat untuk komponen ini.
Menyebarkan menggunakan teknologi container yang berbeda¶
Peringatan
While nspawn is an available containerization technology it should be considered unmaintained and it's support will be removed in the upcoming release.
OpenStack-Ansible saat ini mendukung dua teknologi container yang berbeda, LXC dan nspawn. Kedua teknologi container ini dapat digunakan secara terpisah atau bersama-sama dalam kelompok yang sama tetapi memiliki batasan hanya satu pengaturan per host.
Dengan menggunakan shared-infra_hosts
sebagai contoh, pertimbangkan konfigurasi openstack_user_config.yml
ini:
shared-infra_hosts:
infra1:
ip: 172.29.236.101
container_vars:
container_tech: lxc
infra2:
ip: 172.29.236.102
container_vars:
container_tech: nspawn
infra3:
ip: 172.29.236.103
Dalam contoh ini, tiga host ditugaskan ke grup shared-infra_hosts, dan akan menggunakan beban kerja containerized menggunakan lxc
pada infra1, nspawn
pada infra2, and lxc
pada infra3. Perhatikan infra3 tidak mendefinisikan opsi container_tech
karena itu tidak diperlukan. Jika opsi ini tidak ditentukan, nilai akan secara otomatis ditetapkan ke lxc
dalam inventaris yang dihasilkan. Dua opsi yang didukung untuk variabel konfigurasi container_tech
adalah lxc
atau nspawn
.