[ English | English (United Kingdom) | Deutsch | русский | español | Indonesia ]

Mengganti konfigurasi default

Variable precedence

Role defaults

Setiap peran memiliki file, defaults/main.yml yang menyimpan variabel biasa yang bisa ditimpa oleh seorang deployer, seperti peran Ansible reguler. Default ini adalah yang paling dekat dengan standar OpenStack.

Mereka dapat ditimpa pada berbagai tingkatan.

Group vars dan host vars

OpenStack-Ansible menyediakan default aman untuk penggunaan di folder group_vars. Mereka menjaga kabel antara peran yang berbeda, seperti misalnya menyimpan informasi tentang cara mencapai RabbitMQ dari peran nova.

Anda dapat mengganti group vars yang ada (dan host vars) dengan membuat folder Anda sendiri /etc/openstack_deploy/group_vars (dan /etc/openstack_deploy/host_vars masing-masing).

Jika Anda ingin mengubah lokasi folder override, Anda dapat mengadaptasi file openstack-ansible.rc Anda, atau mengekspor GROUP_VARS_PATH dan HOST_VARS_PATH selama sesi shell Anda.

Role vars

Setiap peran memanfaatkan variabel tambahan dalam vars/ yang diutamakan daripada vars grup.

Variabel ini biasanya internal untuk peran dan tidak dirancang untuk diganti. Namun, deployer dapat memilih untuk menimpa mereka menggunakan extra-vars dengan menempatkan penggantian ke file variabel pengguna.

User variables

Jika Anda ingin menimpa variabel secara global, Anda dapat menentukan variabel yang ingin Anda timpa dalam file /etc/openstack_deploy/user_*.yml. Ini akan berlaku pada semua host.

file user_*.yml lebih detail

File dalam /etc/openstack_deploy beginning with user_ akan secara otomatis bersumber dari perintah openstack-ansible apa pun. Atau, file dapat bersumber dengan parameter -e dari perintah ansible-playbook.

user_variables.yml dan user_secrets.yml digunakan langsung oleh OpenStack-Ansible. Menambahkan variabel khusus yang digunakan oleh peran dan buku pedoman Anda sendiri ke file ini tidak disarankan. Melakukan hal itu akan mempersulit jalur upgrade Anda dengan membuat perbandingan file yang ada dengan versi yang lebih baru dari file ini lebih sulit. Sebaliknya, praktik yang disarankan adalah menempatkan variabel Anda sendiri dalam file bernama mengikuti pola user_*.yml sehingga mereka akan bersumber di samping yang digunakan secara eksklusif oleh OpenStack-Ansible.

File user_*.yml berisi variabel-variabel YAML yang diterapkan sebagai extra-vars ketika menjalankan openstack-ansible untuk menjalankan playbooks. Mereka akan bersumber dalam urutan alfanumerik dengan openstack-ansible. Jika variabel duplikat terjadi dalam file user_*.yml, variabel dalam pembacaan file terakhir akan diutamakan.

Pengaturan menimpa dalam file konfigurasi dengan config_template

Semua layanan yang menggunakan YAML, JSON, atau INI untuk konfigurasi dapat menerima penggantian melalui penggunaan plugin tindakan Ansible bernama config_template. Mesin template konfigurasi memungkinkan deployer untuk menggunakan kamus sederhana untuk memodifikasi atau menambahkan item ke dalam file konfigurasi pada waktu berjalan yang mungkin tidak memiliki opsi template yang telah ditetapkan. Semua peran OpenStack-Ansible memungkinkan fungsionalitas ini jika berlaku. File yang tersedia untuk menerima penggantian dapat dilihat dalam file defaults/main.yml sebagai kamus standar kosong (hash).

Modul ini tidak diterima di Ansible Core (lihat PR1 dan PR2), dan tidak akan pernah ada.

dokumentasi config_template

Ini adalah opsi yang tersedia seperti yang ditemukan dalam bagian dokumentasi modul virtual.

module: config_template
version_added: 1.9.2
short_description: >
  Renders template files providing a create/update override interface
description:
  - The module contains the template functionality with the ability to
    override items in config, in transit, through the use of a simple
    dictionary without having to write out various temp files on target
    machines. The module renders all of the potential jinja a user could
    provide in both the template file and in the override dictionary which
    is ideal for deployers who may have lots of different configs using a
    similar code base.
  - The module is an extension of the **copy** module and all of attributes
    that can be set there are available to be set here.
options:
  src:
    description:
      - Path of a Jinja2 formatted template on the local server. This can
        be a relative or absolute path.
    required: true
    default: null
  dest:
    description:
      - Location to render the template to on the remote machine.
    required: true
    default: null
  config_overrides:
    description:
      - A dictionary used to update or override items within a configuration
        template. The dictionary data structure may be nested. If the target
        config file is an ini file the nested keys in the ``config_overrides``
        will be used as section headers.
  config_type:
    description:
      - A string value describing the target config type.
    choices:
      - ini
      - json
      - yaml

Contoh tugas menggunakan modul config_template

Dalam tugas ini file test.ini.j2 adalah templat yang akan dirender dan ditulis ke disk di /tmp/test.ini. Entri config_overrides adalah kamus (hash) yang memungkinkan penyebar untuk mengatur data sewenang-wenang sebagai penggantian yang akan ditulis ke dalam file konfigurasi pada saat run time. Entri config_type menentukan jenis file konfigurasi yang akan berinteraksi dengan modul; opsi yang tersedia adalah "yaml", "json", dan "ini".

- name: Run config template ini
  config_template:
    src: test.ini.j2
    dest: /tmp/test.ini
    config_overrides: "{{ test_overrides }}"
    config_type: ini

Berikut ini adalah contoh override kamus (dictionary) (hash)

test_overrides:
  DEFAULT:
    new_item: 12345

Dan di sini adalah file templat:

[DEFAULT]
value1 = abc
value2 = 123

File yang diberikan pada disk, yaitu /tmp/test.ini terlihat seperti ini:

[DEFAULT]
value1 = abc
value2 = 123
new_item = 12345

Menemukan penggantian yang tersedia

Semua opsi ini dapat ditentukan dengan cara apa pun yang sesuai dengan penyebaran Anda. Dalam hal kemudahan penggunaan dan fleksibilitas, disarankan agar Anda mendefinisikan override Anda dalam file variabel pengguna seperti /etc/openstack_deploy/user_variables.yml.

Daftar penggantian yang tersedia dapat ditemukan dengan menjalankan:

ls /etc/ansible/roles/*/defaults/main.yml -1 \
    | xargs -I {} grep '_.*_overrides:' {} \
    | egrep -v "^#|^\s" \
    | sort -u

Catatan

Kemungkinan override tambahan dapat ditemukan di "Tunable Section" dari setiap file main.yml peran, seperti /etc/ansible/roles/role_name/defaults/main.yml.

Mengganti default konfigurasi OpenStack

OpenStack memiliki banyak opsi konfigurasi yang tersedia dalam file .conf (dalam format file INI standar), file kebijakan (dalam format JSON standar) dan file YAML, dan dapat karena itu gunakan modul config_template yang dijelaskan di atas.

OpenStack-Ansible memungkinkan Anda untuk referensi opsi apa pun di OpenStack Configuration Reference melalui penggunaan serangkaian entri konfigurasi yang sederhana di /etc/openstack_deploy/user_variables.yml.

File Overriding .conf

Paling sering, override diterapkan untuk file <service> .conf (misalnya, nova.conf). File ini menggunakan format file INI standar.

Misalnya, Anda mungkin ingin menambahkan parameter berikut ke file nova.conf:

[DEFAULT]
remove_unused_original_minimum_age_seconds = 43200

[libvirt]
cpu_mode = host-model
disk_cachemodes = file=directsync,block=none

[database]
idle_timeout = 300
max_pool_size = 10

Untuk melakukan ini, Anda menggunakan entri konfigurasi berikut di file /etc/openstack_deploy/user_variables.yml:

nova_nova_conf_overrides:
  DEFAULT:
    remove_unused_original_minimum_age_seconds: 43200
  libvirt:
    cpu_mode: host-model
    disk_cachemodes: file=directsync,block=none
  database:
    idle_timeout: 300
    max_pool_size: 10

Catatan

Format umum untuk nama variabel yang digunakan untuk penggantian adalah <service>_<filename>_<file extension>_overrides. Sebagai contoh, nama variabel yang digunakan dalam contoh ini untuk menambahkan parameter ke file nova.conf adalah nova_nova_conf_overrides.

Dengan cara yang sama Anda dapat menerapkan penggantian ke layanan uwsgi. Sebagai contoh:

nova_api_os_compute_uwsgi_ini_overrides:
  uwsgi:
    limit: 1024

Catatan

Beberapa peran, seperti uwsgi, digunakan untuk banyak peran, dan memiliki penggantian "special", (seperti uwsgi_ini_overrides) yang dapat ditentukan untuk memengaruhi semua layanan yang menggunakan uwsgi. Variabel ini "special" karena akan didahulukan daripada peran yang ditentukan * _uwsgi_ini_overrides.

Anda juga dapat menerapkan penggantian pada basis per-host dengan konfigurasi berikut di file /etc/openstack_deploy/openstack_user_config.yml:

compute_hosts:
  900089-compute001:
    ip: 192.0.2.10
    host_vars:
      nova_nova_conf_overrides:
        DEFAULT:
          remove_unused_original_minimum_age_seconds: 43200
        libvirt:
          cpu_mode: host-model
          disk_cachemodes: file=directsync,block=none
        database:
          idle_timeout: 300
          max_pool_size: 10

Gunakan metode ini untuk file apa pun dengan format INI untuk di proyek OpenStack yang digunakan di OpenStack-Ansible.

Mengganti file .json

Untuk menerapkan kontrol akses yang berbeda dari yang ada di lingkungan OpenStack standar, Anda dapat menyesuaikan kebijakan default yang diterapkan oleh layanan. File kebijakan dalam format JSON.

Misalnya, Anda mungkin ingin menambahkan kebijakan berikut di file policy.json untuk layanan Identity (keystone):

{
    "identity:foo": "rule:admin_required",
    "identity:bar": "rule:admin_required"
}

Untuk melakukan ini, Anda menggunakan entri konfigurasi berikut di file /etc/openstack_deploy/user_variables.yml:

keystone_policy_overrides:
  identity:foo: "rule:admin_required"
  identity:bar: "rule:admin_required"

Catatan

Format umum untuk nama variabel yang digunakan untuk penggantian adalah <service>_policy_overrides. Misalnya, nama variabel yang digunakan dalam contoh ini untuk menambahkan kebijakan ke layanan Identity (keystone) file policy.json adalah keystone_policy_overrides.

Gunakan metode ini untuk file apa pun dengan format JSON di proyek OpenStack yang digunakan di OpenStack-Ansible.

Untuk membantu Anda dalam menemukan nama variabel yang sesuai untuk digunakan untuk penggantian, format umum untuk nama variabel adalah <service>_policy_overrides.

Mengganti file .yml

Anda dapat mengganti nilai file .yml dengan memasok konten YAML pengganti.

Catatan

Semua konten file YAML default sepenuhnya ditimpa oleh override, sehingga seluruh sumber YAML (konten yang ada dan perubahan Anda) harus disediakan.

Misalnya, Anda mungkin ingin menentukan pengecualian meter untuk semua item perangkat keras dalam konten default file pipeline.yml untuk layanan Telemetry (ceilometer):

sources:
    - name: meter_source
    interval: 600
    meters:
        - "!hardware.*"
    sinks:
        - meter_sink
    - name: foo_source
    value: foo

Untuk melakukan ini, Anda menggunakan entri konfigurasi berikut di file /etc/openstack_deploy/user_variables.yml:

ceilometer_pipeline_yaml_overrides:
  sources:
      - name: meter_source
      interval: 600
      meters:
          - "!hardware.*"
      sinks:
          - meter_sink
      - name: source_foo
      value: foo

Catatan

Format umum untuk nama variabel yang digunakan untuk penggantian adalah <service>_<filename>_<file extension>_overrides. Misalnya, nama variabel yang digunakan dalam contoh ini untuk menentukan pengecualian meter dalam file pipeline.yml untuk layanan Telemetri (ceilometer) adalah ceilometer_pipeline_yaml_overrides.

Overriding OpenStack upper constraints

Each OpenStack release uses an upper-constraints.txt file to define the maximum permitted version of each Python package. In some cases it may be necessary to override this file, for example when your local deployment needs to take advantage of a bug fix. Care should be taken when modifying this file as OpenStack services may not have been tested against more recent package versions.

To override the upper constraints for a deployment, clone the OpenStack requirements git repository, either storing it as a fork at a URL of your choice, or within the local filesystem of the host you are using to deploy OpenStack Ansible from. Once cloned, switch to the branch which matches the name of your deployed OpenStack version, and modify the upper constraints as required.

Next, edit your /etc/openstack_deploy/user_variables.yml file to indicate the path to the requirements git repository, and the git hash of the commit containing your changes using the requirements_git_repo and requirements_git_install_branch variables. When using the local filesystem, the requirements_git_repo should start with file://.

Finally, run the repo-install.yml playbook to upload these modified constraints to your repo host(s).