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