[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]

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:

  1. 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.

  2. 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

  3. 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.

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 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

Catatan

Meskipun nspawn adalah teknologi kontainerisasi yang tersedia, itu harus dipertimbangkan sebagai pengalaman saat ini. Meskipun subsistem ini belum direkomendasikan untuk produksi, ini cukup stabil untuk diperkenalkan kepada masyarakat dan kami ingin umpan balik ketika kami memperbaikinya pada siklus berikutnya.

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.