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

Never edit or delete the file /etc/openstack_deploy/openstack_inventory.json. This can lead to problems with the inventory: existng hosts and containers will be unmanaged and new ones will be generated instead, breaking your existing deployment.

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 file env.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 bagian physical_skel untuk grup host dalam file baru atau yang sudah ada, seperti env.d/galera.yml. Sebagai contoh:
```
physical_skel:
  db_containers:
    belongs_to:
      - all_containers
  db_hosts:
    belongs_to:
      - hosts
```
Tentukan grup host (db_hosts) dalam file conf.d/ (seperti galera.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 dan db_hosts) adalah arbitrer. Pilih nama grup Anda sendiri, tetapi pastikan referensi konsisten di antara semua file yang relevan.

Adding virtual nest groups¶

If you want to create a custom group for arbitrary grouping of hosts and containers within these hosts but skip the generation of any new containers, you should use is_nest property under container_skel and skip defining belongs_to structure. is_nest property will add host-containers as children to such a group.

Example: Defining Availability Zones¶

A good example of how is_nest property can be used is describing Availability Zones. As when operating multiple AZs it's handy to define AZ-specific variables, like AZ name, for all hosts in this AZ. And leveraging group_vars is best way of ensuring that all hosts that belong to same AZ have same configuration applied.

Let's assume you have 3 controllers and each of them is placed in different Availability Zones. There is also a compute node in each Availability Zone. And we want each host or container that is placed physically in a specific AZ be part of it's own group (ie azN_all)

In order to achieve that we need:

Define host groups in conf.d or openstack_user_config.yml to assign hosts accordingly to their Availability Zones:

az1-infra_hosts: &infra_az1
  az1-infra1:
    ip: 172.39.123.11

az2-infra_hosts: &infra_az2
  az2-infra2:
    ip: 172.39.123.12

az3-infra_hosts: &infra_az3
  az3-infra3:
    ip: 172.39.123.13

shared-infra_hosts: &controllers
  <<: *infra_az1
  <<: *infra_az2
  <<: *infra_az3

az1-compute_hosts: &computes_az1
  az1-compute01:
    ip: 172.39.123.100

az2-compute_hosts: &computes_az2
  az2-compute01:
    ip: 172.39.123.150

az3-compute_hosts: &computes_az3
  az3-compute01:
    ip: 172.39.123.200

compute_hosts:
  <<: *computes_az1
  <<: *computes_az2
  <<: *computes_az3

az1_hosts:
  <<: *computes_az1
  <<: *infra_az1

az2_hosts:
  <<: *computes_az2
  <<: *infra_az2

az3_hosts:
  <<: *computes_az3
  <<: *infra_az3

Create env.d/az.yml file that will leverage is_nest property and allow all infra containers to be part of the AZ group as well

component_skel:
  az1_containers:
    belongs_to:
      - az1_all
  az1_hosts:
    belongs_to:
      - az1_all

  az2_containers:
    belongs_to:
      - az2_all
  az2_hosts:
    belongs_to:
      - az2_all

  az3_containers:
    belongs_to:
      - az3_all
  az3_hosts:
    belongs_to:
      - az3_all

container_skel:
  az1_containers:
    properties:
      is_nest: True
  az2_containers:
    properties:
      is_nest: True
  az3_containers:
    properties:
      is_nest: True

Now you can leverage group_vars file to apply a variable to all containers and bare metal hosts in AZ. For example /etc/openstack_deploy/group_vars/az1_all.yml:
```
---
az_name: az1
cinder_storage_availability_zone: "{{ az_name }}"
```

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 direktori env.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 Adding virtual nest groups 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.

Having SSH network different from OpenStack Management network¶

In some environments SSH network that is used to access nodes from deploy host and management network are different. In this case it's important that services were listening on correct network while ensure that Ansible use SSH network for accessing managed hosts. In these cases you can define management_ip key while defining hosts in your openstack_user_config.yml file.

management_ip will be used as management_address for the node, while ip will be used as ansible_host for accessing node by SSH.

Example:

shared-infra_hosts:
  infra1:
    ip: 192.168.0.101
    management_ip: 172.29.236.101

Mengkonfigurasi inventory