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

Verwenden von OpenStack-Ansible in Ihrem Projekt

Einschließlich OpenStack-Ansible in Ihrem Projekt

Die Einbindung des openstack-ansible-Repository in ein anderes Projekt kann auf verschiedene Arten erfolgen:

  • Ein Git-Submodul zeigte auf ein freigegebenes Tag.

  • Ein Skript zum automatischen Ausführen eines Git-Checkouts von OpenStack-Ansible.

Wenn Sie OpenStack-Ansible in einem Projekt verwenden, sollten Sie eine parallele Verzeichnisstruktur verwenden, wie im Abschnitt `` ansible.cfg``-Dateien gezeigt.

Beachten Sie auch, dass das Kopieren von Dateien in Verzeichnisse wie `` env.d`` oder `` conf.d`` über eine Art Skript innerhalb des Erweiterungsprojekts erfolgen sollte.

Einschließlich OpenStack-Ansible mit Ihrer Ansible-Struktur

Sie können Ihre eigene Playbook-, Variablen- und Rollenstruktur erstellen, während Sie weiterhin die OpenStack-Ansible-Rollen und -Bibliotheken enthalten, indem Sie Umgebungsvariablen festlegen oder /usr/local/bin/openstack-ansible.rc anpassen.

Die relevanten Umgebungsvariablen für OpenStack-Ansible sind wie folgt:

ANSIBLE_LIBRARY

Diese Variable sollte auf /etc/ansible/plugins/library zeigen. Auf diese Weise können Rollen und Playbooks auf die enthaltenen Ansible-Module von OpenStack-Ansible zugreifen.

ANSIBLE_ROLES_PATH

Diese Variable sollte standardmäßig auf /etc/ansible/roles zeigen. Dadurch kann Ansible alle OpenStack-Ansible-Rollen, auf die sich die Erweiterungsrollen beziehen, ordnungsgemäß nachschlagen.

ANSIBLE_INVENTORY

Diese Variable sollte auf openstack-ansible/inventory/dynamic_inventory.py zeigen. Mit dieser Einstellung haben Erweiterungen Zugriff auf dasselbe dynamische Inventar, das OpenStack-Ansible verwendet.

Die Pfade zum obersten Verzeichnis openstack-ansible können in dieser Datei relativ sein.

Betrachten Sie diese Verzeichnisstruktur:

my_project
|
|- custom_stuff
|  |
|  |- playbooks
|- openstack-ansible
|  |
|  |- playbooks

Die Umgebungsvariablen würden ../openstack-ansible/playbooks/<directory> benutzen.

Hinzufügen neuer oder übergeordneter Rollen in Ihrer OpenStack-Ansible-Installation

Standardmäßig verwendet OpenStack-Ansible die ansible-role-requirements Datei, um die Rollen zu holen, die für den Installationsprozess benötigt werden.

Die Rollen werden in den Standard ANSIBLE_ROLES_PATH geholt, der standardmäßig /etc/ansible/roles ist.

ANSIBLE_ROLE_FILE ist eine Umgebungsvariable, die auf den Speicherort einer YAML-Datei verweist, die ansible-galaxy konsumieren kann, wobei angegeben wird, welche Rollen heruntergeladen und installiert werden sollen. Der Standardwert dafür ist ansible-role-anforderungen.yml.

Sie können die Datei ansible-role-requirement überschreiben, indem Sie die Umgebungsvariable ANSIBLE_ROLE_FILE definieren, bevor Sie das Skript bootstrap-ansible.sh ausführen.

It is now the responsibility of the deployer to maintain appropriate versions pins of the ansible roles if an upgrade is required.

Adding new collections in your OpenStack-Ansible installation

The Victoria release of openstack-ansible adds an optional new config file which defaults to /etc/openstack_deploy/user-collection-requirements.yml. It should be in the native format of the ansible-galaxy requirements file and can be used to add new collections to the deploy host. You can override location of the user-collection-requirements.yml by setting USER_COLLECTION_FILE environment variable before running the bootstrap-ansible.sh script.

Maintaining local forks of ansible roles

The Train release of openstack-ansible adds an optional new config file which defaults to /etc/openstack_deploy/user-role-requirements.yml. It is in the same format as ansible-role-requirements.yml and can be used to add new roles or selectively override existing ones. New roles listed in user-role-requirements.yml will be merged with those in ansible-role-requirements.yml, and roles with matching names will override those in ansible-role-requirements.yml. It is easy for a deployer to keep this file under their own version control and out of the openstack-ansible tree.

This allows a deployer to either add new ansible roles, or override the location or SHA of existing individual roles without replacing the original file entirely. It is also straightforward to include the