Überschreiben der Standardkonfiguration¶

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.

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:

find . -name "main.yml" -exec grep '_.*_overrides:' {} \; \
    | grep -v "^#" \
    | sort -u

Die folgenden Übersteuerungsvariablen sind derzeit verfügbar:

Galera:

• galera_client_my_cnf_overrides
• galera_my_cnf_overrides
• galera_cluster_cnf_overrides
• galera_debian_cnf_overrides

Telemetriedienst (Ceilometer):

• ceilometer_policy_overrides
• ceilometer_ceilometer_conf_overrides
• ceilometer_event_definitions_yaml_overrides
• ceilometer_event_pipeline_yaml_overrides
• ceilometer_pipeline_yaml_overrides

Blockspeicher (cinder):

• cinder_policy_overrides
• cinder_rootwrap_conf_overrides
• cinder_api_paste_ini_overrides
• cinder_cinder_conf_overrides

Abbildservice (glance):

• glance_glance_api_paste_ini_overrides
• glance_glance_api_conf_overrides
• glance_glance_cache_conf_overrides
• glance_glance_manage_conf_overrides
• glance_glance_registry_paste_ini_overrides
• glance_glance_registry_conf_overrides
• glance_glance_scrubber_conf_overrides
• glance_glance_scheme_json_overrides
• glance_policy_overrides

Orchestrierungsdienst (heat):

• heat_heat_conf_overrides
• heat_api_paste_ini_overrides
• heat_default_yaml_overrides
• heat_aws_rds_dbinstance_yaml_overrides
• heat_policy_overrides

Identitätsdienst (Keystone):

• keystone_keystone_conf_overrides
• keystone_keystone_default_conf_overrides
• keystone_keystone_paste_ini_overrides
• keystone_policy_overrides

Vernetzungsdienst (neutron):

• neutron_neutron_conf_overrides
• neutron_ml2_conf_ini_overrides
• neutron_dhcp_agent_ini_overrides
• neutron_api_paste_ini_overrides
• neutron_rootwrap_conf_overrides
• neutron_policy_overrides
• neutron_dnsmasq_neutron_conf_overrides
• neutron_l3_agent_ini_overrides
• neutron_metadata_agent_ini_overrides
• neutron_metering_agent_ini_overrides

Compute-Service (nova):

• nova_nova_conf_overrides
• nova_rootwrap_conf_overrides
• nova_api_paste_ini_overrides
• nova_policy_overrides

Objektspeicherdienst (swift):

• swift_swift_conf_overrides
• swift_swift_dispersion_conf_overrides
• swift_proxy_server_conf_overrides
• swift_account_server_conf_overrides
• swift_account_server_replicator_conf_overrides
• swift_container_server_conf_overrides
• swift_container_server_replicator_conf_overrides
• swift_object_server_conf_overrides
• swift_object_server_replicator_conf_overrides

Tempest:

• tempest_tempest_conf_overrides

Pip:

• pip_global_conf_overrides

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

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"

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.

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