[ English | English (United Kingdom) | español | Indonesia | русский | Deutsch ]
Überschreiben der Standardkonfiguration¶
Variable Priorität¶
Rollenvorgaben¶
Jede Rolle hat eine Datei defaults/main.yml
, die die üblichen Variablen enthält, die von einem Deployer überschrieben werden können, wie eine reguläre Ansible-Rolle. Diese Standardwerte entsprechen den OpenStack-Standards.
Sie können auf mehreren Ebenen außer Kraft gesetzt werden.
Group-Vars und Host-Vars¶
OpenStack-Ansible bietet sichere Standards für Deployer im Ordner group_vars. Sie kümmern sich um die Verkabelung zwischen verschiedenen Rollen, wie zum Beispiel das Speichern von Informationen darüber, wie RabbitMQ von der nova-Rolle erreicht werden kann.
Sie können die vorhandenen Gruppenvariablen (und Hostvariablen) überschreiben, indem Sie in /etc/openstack_deploy/group_vars (bzw. /etc/openstack_deploy/host_vars) einen eigenen Ordner erstellen.
Wenn Sie den Speicherort des Override-Ordners ändern möchten, können Sie Ihre openstack-ansible.rc-Datei anpassen oder GROUP_VARS_PATH` und` HOST_VARS_PATH` während Ihrer Shell-Sitzung exportieren.
Role vars¶
Jede Rolle verwendet zusätzliche Variablen in vars/
, die Vorrang vor Gruppenvariablen haben.
Diese Variablen sind in der Regel für die Rolle intern und nicht für das Überschreiben vorgesehen. Implementierer können diese jedoch überschreiben, indem sie extra-vars verwenden, indem sie die Überschreibungen in die Benutzervariablendatei einfügen.
Benutzervariablen¶
Wenn Sie die Variable global überschreiben möchten, können Sie die Variable, die Sie überschreiben möchten, in einer Datei /etc/openstack_deploy/user_*.yml
definieren. Es wird auf alle Hosts angewendet.
user_*.yml-Dateien in weiteren Einzelheiten¶
Dateien in /etc/openstack_deploy
, beginnend mit user_
, werden automatisch in jedem openstack-ansible
-Befehl gespeichert. Alternativ können die Dateien mit dem Parameter -e
des Befehls ansible-playbook
bezogen werden.
user_variables.yml
und user_secrets.yml
werden direkt von OpenStack-Ansible verwendet. Es wird nicht empfohlen, benutzerdefinierte Variablen hinzuzufügen, die von Ihren eigenen Rollen und Playbooks für diese Dateien verwendet werden. Dies erschwert den Upgrade-Pfad, da der Vergleich Ihrer vorhandenen Dateien mit späteren Versionen dieser Dateien schwieriger wird. Stattdessen empfiehlt es sich, Ihre eigenen Variablen in Dateien zu speichern, die nach dem user_*.yml
-Muster benannt sind, so dass sie zusammen mit denen verwendet werden, die ausschließlich von OpenStack-Ansible verwendet werden.
user_*. yml` Dateien enthalten YAML-Variablen, die als extra-vars angewendet werden, wenn openstack-ansible
zum Ausführen von Playbooks ausgeführt wird. Sie werden in alphanumerischer Reihenfolge von openstack-ansible
bezogen. Wenn doppelte Variablen in den Dateien user_*.yml
auftreten, hat die Variable in der zuletzt gelesenen Datei Vorrang.
Überschreibungen in Konfigurationsdateien mit config_template setzen¶
Alle Dienste, die YAML, JSON oder INI für die Konfiguration verwenden, können durch die Verwendung eines Ansible-Action-Plugins mit dem Namen config_template
überschrieben werden. Die Konfigurationsvorlagen-Engine ermöglicht einem Bereitsteller, ein einfaches Wörterbuch zu verwenden, um Elemente zur Laufzeit in Konfigurationsdateien zu ändern oder hinzuzufügen, die möglicherweise keine voreingestellte Vorlagenoption haben. Alle OpenStack-Ansible-Rollen ermöglichen diese Funktionalität, wo anwendbar. Dateien, die für das Übernehmen von Überschreibungen verfügbar sind, können in der defaults/main.yml
-Datei als leere Standardwörterbücher (Hashes) gesehen werden.
Dieses Modul wurde nicht in Ansible Core übernommen (siehe PR1 und PR2) und wird es niemals sein.
Dokumentation der config_template¶
Dies sind die verfügbaren Optionen, die Sie im Dokumentationsabschnitt des virtuellen Moduls finden.
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
Beispielaufgabe, die das Modul config_template verwendet¶
In dieser Aufgabe ist die Datei test.ini.j2
eine Vorlage, die gerendert und auf der Festplatte unter /tmp/test.ini
gespeichert wird. Der Eintrag config_overrides ist ein Wörterbuch (Hash), mit dem ein Implementierer beliebige Daten als Überschreibungen festlegen kann, die zur Laufzeit in die Konfigurationsdatei geschrieben werden. Der Eintrag config_type gibt den Typ der Konfigurationsdatei an, mit der das Modul interagieren soll. Verfügbare Optionen sind yaml
, json
und ini
.
- name: Run config template ini
config_template:
src: test.ini.j2
dest: /tmp/test.ini
config_overrides: "{{ test_overrides }}"
config_type: ini
Hier ist ein Beispiel Override Dictionary (Hash)
test_overrides:
DEFAULT:
new_item: 12345
Und hier ist die Vorlagendatei:
[DEFAULT]
value1 = abc
value2 = 123
Die gerenderte Datei auf der Festplatte, nämlich /tmp/test.ini
sieht wie folgt aus:
[DEFAULT]
value1 = abc
value2 = 123
new_item = 12345
Ermitteln der verfügbaren Überschreibungen¶
Alle diese Optionen können auf jede für Ihre Bereitstellung geeignete Weise angegeben werden. In Bezug auf Benutzerfreundlichkeit und Flexibilität wird empfohlen, dass Sie Ihre Überschreibungen in einer Benutzervariablen-Datei wie /etc/openstack_deploy/user_variables.yml
definieren.
Die Liste der verfügbaren Überschreibungen finden Sie, indem Sie Folgendes ausführen:
ls /etc/ansible/roles/*/defaults/main.yml -1 \
| xargs -I {} grep '_.*_overrides:' {} \
| egrep -v "^#|^\s" \
| sort -u
Bemerkung
Mögliche zusätzliche Überschreibungen finden Sie im Tunable Section
der main.yml
Datei jeder Rolle, wie zum Beispiel /etc/ansible/roles/role_name/defaults/main.yml
.
Überschreiben der OpenStack-Konfigurationsstandards¶
OpenStack hat viele Konfigurationsoptionen in conf
Dateien (in einem Standard INI
Dateiformat), Richtliniendateien (im Standard JSON
Format) und YAML
Dateien, und kann Verwenden Sie daher das oben beschriebene Modul config_template
.
Mit OpenStack-Ansible können Sie auf alle Optionen in der OpenStack Configuration Reference verweisen, indem Sie einen einfachen Satz von Konfigurationseinträgen in der Datei /etc/openstack_deploy/user_variables.yml
verwenden.
Überschreiben von .conf-Dateien¶
In den meisten Fällen sind Überschreibungen für die <service>.conf``Dateien implementiert (zum Beispiel ``nova.conf
). Diese Dateien verwenden ein Standard-INI-Dateiformat.
Zum Beispiel möchten Sie vielleicht die folgenden Parameter zur nova.conf
Datei hinzufügen:
[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
Dazu verwenden Sie den folgenden Konfigurationseintrag in der Datei /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
Bemerkung
Das allgemeine Format für die Variablennamen, die für Überschreibungen verwendet werden, ist <service>_<filename>_<file extension>_overrides
. Der Variablenname, der in diesen Beispielen zum Hinzufügen von Parametern zur nova.conf
-Datei verwendet wird, ist beispielsweise nova_nova_conf_overrides
.
The same way you can apply overrides to the uwsgi services. For example:
nova_api_os_compute_uwsgi_ini_overrides:
uwsgi:
limit: 1024
Bemerkung
Some roles, like uwsgi, are used for lot of roles, and have „special“ overrides, (like uwsgi_ini_overrides) which can be defined to impact all services which are using uwsgi. These variables are „special“ as they will have precedence over role defined *_uwsgi_ini_overrides.
Sie können auch Überschreibungen pro Host mit der folgenden Konfiguration in der Datei /etc/openstack_deploy/openstack_user_config.yml
anwenden:
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
Verwenden Sie diese Methode für alle Dateien mit dem Format INI
für OpenStack-Projekte, die in OpenStack-Ansible bereitgestellt werden.
Überschreiben von JSON-Dateien¶
Um Zugriffskontrollen zu implementieren, die sich von denen in einer Standard-OpenStack-Umgebung unterscheiden, können Sie die Standardrichtlinien anpassen, die von den Services angewendet werden. Richtliniendateien haben das Format JSON
.
Beispielsweise möchten Sie möglicherweise die folgende Richtlinie in der Datei policy.json
für den Identitätsdienst (Keystone) hinzufügen:
{
"identity:foo": "rule:admin_required",
"identity:bar": "rule:admin_required"
}
Dazu verwenden Sie den folgenden Konfigurationseintrag in der Datei /etc/openstack_deploy/user_variables.yml
:
keystone_policy_overrides:
identity:foo: "rule:admin_required"
identity:bar: "rule:admin_required"
Bemerkung
Das allgemeine Format für die Variablennamen, die für Überschreibungen verwendet werden, ist <service> _policy_overrides
. Der Variablenname, der in diesem Beispiel zum Hinzufügen einer Richtlinie zur Datei policy.json
des Identitätsdienstes (Keystone) verwendet wird, lautet beispielsweise keystone_policy_overrides
.
Verwenden Sie diese Methode für alle Dateien mit dem Format JSON
in OpenStack-Projekten, die in OpenStack-Ansible bereitgestellt werden.
Um Ihnen bei der Suche nach dem geeigneten Variablennamen zu helfen, der für Überschreibungen verwendet werden kann, lautet das allgemeine Format für den Variablennamen <service> _policy_overrides
.
Überschreiben von .yml-Dateien¶
Sie können .yml` Dateiwerte überschreiben, indem Sie Ersatz-YAML-Inhalt bereitstellen.
Bemerkung
Der gesamte Inhalt der YAML-Datei wird vollständig durch die Überschreibungen überschrieben. Daher muss die gesamte YAML-Quelle (sowohl der vorhandene Inhalt als auch Ihre Änderungen) bereitgestellt werden.
Beispielsweise möchten Sie möglicherweise einen Zählerausschluss für alle Hardwareelemente im Standardinhalt der pipeline.yml
-Datei für den Telemetriedienst (Ceilometer) definieren:
sources:
- name: meter_source
interval: 600
meters:
- "!hardware.*"
sinks:
- meter_sink
- name: foo_source
value: foo
Dazu verwenden Sie den folgenden Konfigurationseintrag in der Datei /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
Bemerkung
Das allgemeine Format für die Variablennamen, die für Überschreibungen verwendet werden, ist <service>_<filename>_<file extension>_overrides
. Der Variablenname, der in diesem Beispiel zum Definieren eines Zählerausschlusses in der pipeline.yml
-Datei für den Telemetriedienst (Ceilometer) verwendet wird, lautet beispielsweise 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).