Est-il possible de définir les variables playbook-global dans Ansible?
j'ai un grand playbook Ansible où les images Docker sont construites en cours d'exécution. J'utilise un nombre croissant comme étiquette pour les modifier. Actuellement, je dois spécifier ceci dans chaque hosts: section.
je sais qu'il y a des variables globales mais d'après ce que j'ai trouvé en cherchant "possible" "global variables", elles doivent être définies en dehors du playbook. Est-il possible de définir des variables globales qui sont globales pour le playbook?
4 réponses
si la balise / version que vous utilisez est applicable à tous les hôtes, alors utilisez group_vars/ est une option viable.
si les numéros de révision sont spécifiques à chaque entrée hôte dans un fichier host_vars/host_name, cela pourrait être mieux.
si vous voulez lire et initialiser var et ensuite l'incrémenter après chaque jeu qui devient un peu plus difficile de persister cette information à travers les jeux (ou chaque-hôtes comme vous dites) dans le playbook. Par exemple, si vous avez été si vous cherchez à déployer des instances de docker N, vous pourriez faire de la magie d'inventaire dynamique comme ceci:
- hosts: localhost
tasks:
- add_host: name=docker_{{item}} groups="dockers,other" tag={{item}}
with_sequence: start={{ext_def_start}} count={{ext_def_num}}
- hosts: docker_*
tasks:
- debug: var=tag
Ansible a un défaut all groupe qui, curieusement, contient tous les hôtes dans le fichier d'inventaire.
en tant que tel, vous pouvez faire comme avec n'importe quel groupe d'hôtes et fournir group_vars pour le groupe d'hôtes.
Comme indiqué dans le lien précédent, ceux-ci peuvent être directement défini dans le fichier d'inventaire ou ils peuvent être contenus dans un fichier distinct, nommé d'après le groupe dans un group_vars répertoire au même niveau que l'inventaire fichier.
Un exemple de structure de répertoire pourrait alors ressembler à quelque chose comme:
-ansible
|--inventory
| |--group_vars
| | |--all
| | |--dev
| | |--test
| | |--prod
| | |--webservers
| | |--databases
| |--dev
| |--test
| |--prod
|--roles
...
votre fichier d'inventaire dev pourrait alors ressembler à quelque chose comme:
[dev:children]
webservers
databases
[webservers]
web1.dev
web2.dev
[databases]
database-master.dev
database-slave.dev
tous ces hôtes vont maintenant prendre n'importe quelle config spécifique à l'hôte (qui pourrait être définie soit en ligne, soit, comme avec group_vars peut être placée dans un dossier host_vars) et aussi config pour les groupes spécifiques dans lesquels ils sont tels que webservers et puis les groupes dont ils héritent aussi tels que dev mais aussi, par défaut, all.
ceci peut alors être utilisé pour configurer les choses de manière plus grossière que par hôte.
des choses telles que les serveurs NTP peuvent vouloir être définies dans tous, tandis que les serveurs DNS peuvent vouloir être définis au niveau de l'environnement (si votre réseau est segmenté en dev, test et production, ils peuvent avoir besoin de différents serveurs DNS dans /etc/resolv.conf) alors que différents types de serveurs peuvent avoir différentes configurations autour de choses telles que des listes de paquets à être installer. Enfin, certaines choses peuvent devoir être spécifiques à l'hôte, comme définir L'id du serveur MySQL dans un groupe de réplication.
si, à la place, vous voulez définir seulement les paramètres globaux du playbook plutôt que l'ensemble de l'inventaire (et donc vous pouvez accéder à d'autres playbooks) alors vous avez simplement besoin d'un vars dans votre jouer définition comme suit:
- hosts: webservers
vars:
http_port: 80
tasks:
- name: Task1 to be ran against all the webservers
...
Comme mentionné avant, vous pouvez toujours utiliser le all groupe ici trop:
- hosts: all
vars:
ntp_pool:
- ntp1.domain
- ntp2.domain
tasks:
- name: Task1 to be ran against all the servers
...
en général cependant, je recommande fortement d'utiliser les rôles pour structurer les choses qui sont lancées contre certains hôtes et ensuite d'utiliser l'inventaire pour expliquer ce que les serveurs sont Quel type et puis d'utiliser une directive group_vars au niveau de l'inventaire pour contenir toutes les variables pour ces groupes d'hôtes. Faire les choses de cette façon vous aidera à garder les choses dans des endroits sensés et vous permettra de réutiliser facilement votre base de code.
Oui, les variables globales sont possibles comme cela,
exemple de splunk installation playbook
splunk/
setup_splunk_playbook.yaml
roles/base
/tasks/main.yaml
/tasks/install.yaml
search_head
/tasks/configure.yaml
indexer
/tasks/configure.yaml
some_other_role
/tasks/some_task.yaml
hosts
config.yaml
placez vos Var dans la configuration.yaml
chat splunk/config.yaml
---
# global Splunk variables
splunk_version: 7.0.0
dans votre playbook, inclure les Rôles
chat setup_splunk_playbook.yaml
- hosts: "search_heads"
become_user: root
become: true
gather_facts: true
roles:
- base
- search_head
dans votre rôle, incluez les variables globales dans une tâche
chat rôles/base/tâches/main.yaml
---
# install Splunk Base
- name: include vars
include_vars: "{{ playbook_dir }}/config.yaml"
- include: install.yaml
revendeurs à valeur ajoutée sont accessibles dans les tâches d',
chat rôles/base/tâches/installer.yaml
- name: echo version
debug: splunk version is {{ splunk_version }}
je sais que cela pourrait ne pas répondre à la requête de L'OP exactement, mais pour les gens googlant pour définir des variables globales (listes/tableaux) de sorte qu'ils n'ont pas à les définir dans chaque tâche cela pourrait être assez pratique.
Son étonnamment simple, Disons que vous avez une liste de domaines que vous devez passer, j'ai nommé la variable dingo juste pour signifier qu'il pourrait être n'importe quoi.
- hosts: [yourhostlistgoeshere]
remote_user: root
vars:
domainslisto:
- site1.com
- website2.xyz
....
tasks:
- name: copy vhosts
template: src=virtualhost.conf dest=/etc/apache2/sites-available/{{ item }}.conf
with_items: "{{ domainslisto }}"
- name: a2ensite {{ item }}
command: a2ensite {{ item }}
with_items: "{{ domainslisto }}"