[ English | español | Deutsch | русский | Indonesia | English (United Kingdom) ]
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).