Ansible Playbooks vs rôles

Selon les documents Ansible, un Playbook est:

...la base d'une gestion de configuration très simple et d'un système de déploiement multi-machines, contrairement à ceux qui existent déjà, et qui est très bien adapté au déploiement d'applications complexes.

Et, encore une fois, selon ces mêmes docs, un rôles sont:

...moyens de charger automatiquement certains vars_files, tâches et gestionnaires basés sur structure de fichier connue. Le regroupement du contenu par rôles permet également de partager facilement les rôles avec d'autres utilisateurs.

Cependant, la distinction entre ceux-ci et leurs différents cas d'utilisation n'est pas immédiatement évidente pour moi. Par exemple, si je configure mon fichier /etc/ansible/hosts pour ressembler à:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

...alors, quelle est cette entrée "[databases]"...un rôle? Ou le nom d'un fichier PlayBook YAML quelque part? Ou quelque chose d'autre?!?

Si quelqu'un pouvait m'expliquer les différences sur ces, mon compréhension de Ansible serait grandement améliorer!

  • Playbook vs Rôle vs [databases] et des entrées similaires dans /etc/ansible/hosts
  • si les Playbooks sont définis dans les fichiers YAML, où sont définis les rôles?
  • mis à part le ansible.cfg vivant sur le serveur Ansible, comment ajouter / configurer Ansible avec les Playbooks/rôles disponibles? Par exemple, quand je lance ansible-playbook someplaybook.yaml, Comment Ansible sait-il Où trouver ce playbook?
61
demandé sur smeeb 2015-08-19 19:29:42

4 réponses

Playbook vs Role vs [bases de données] et entrées similaires dans /etc / Ansible / hosts

[databases] est un nom unique pour un groupe d'hôtes. Il vous permet de référencer plusieurs hôtes par un seul nom.

Rôle est un ensemble de tâches et de fichiers supplémentaires à configurer hôte pour servir pour un certain rôle .

Playbook est un mappage entre les hôtes et les rôles.

Exemple de documentation décrit l'exemple de projet. Il contient deux choses:

  • tablettes playbook. site.yml, webservers.yml, fooservers.yml sont des livres de jeu.
  • Rôles: roles/common/ et roles/webservers/ contiennent des définitions de la common et webservers rôles en conséquence.

Dans playbook (webservers.yml) vous avez quelque chose comme:

---
- hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question
  roles: <- this is list of roles to assign to these hosts
     - common
     - webservers

Si les Playbooks sont définis dans les fichiers YAML, où sont définis les rôles?

Ils sont définis dans les répertoires roles/*. Les rôles sont définis principalement à l'aide de fichiers YAML, mais peuvent également contenir des ressources de tous types (files/, templates/). Selon documentation La définition du rôle est structurée de cette façon:

  • Si les rôles/x/tâches/main.YML existe, les tâches qui y sont listées seront ajoutées au jeu
  • Si les rôles/x/gestionnaires/main.YML existe, les gestionnaires qui y sont listés seront ajoutés au jeu
  • Si les rôles/x/vars/main.YML existe, les variables qui y sont listées seront ajoutées au jeu
  • Si les rôles/x/meta/main.YML existe, toutes les dépendances de rôle qui y sont listées seront ajouté à la liste des rôles (1.3 et versions ultérieures)
  • toutes les tâches de copie peuvent référencer des fichiers dans roles/x/ files / sans avoir à les tracer relativement ou absolument
  • toutes les tâches de script peuvent référencer des scripts dans roles/x/ files / sans avoir à les tracer relativement ou absolument
  • toutes les tâches de modèle peuvent référencer des fichiers dans roles/x/ templates / sans avoir à les tracer relativement ou absolument
  • toutes les tâches include peuvent référencer des fichiers dans roles / x/ tasks / without avoir à leur chemin relativement ou absolument

Le fichier le plus important est roles/x/tasks/main.yml, ici vous définissez des tâches, qui seront exécutées, lorsque le rôle est exécuté.

Mis à part l'ansible.cfg vivant sur le serveur Ansible, comment ajouter / configurer Ansible avec les Playbooks/rôles disponibles? Par exemple, quand je lance Ansible-playbook someplaybook.yaml, comment Ansible sait où trouver ce playbook?

$ ansible-playbook someplaybook.yaml

Va chercher un playbook à l'intérieur répertoire en cours.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Recherchera un playbook dans le répertoire somedir/somedir/.

Il est de votre responsabilité de mettre votre projet avec tous les playbooks et les rôles sur le serveur. Ansible n'a rien à voir avec ça.

65
répondu Yaroslav Admin 2017-08-10 15:59:57

Playbook vs Role vs [bases de données] et entrées similaires dans /etc / Ansible / hosts

Les rôles sont un moyen de regrouper les tâches en un seul conteneur. Vous pourriez avoir un rôle pour configurer MySQL, un autre pour configurer Postfix, etc.

Un playbook définit ce se passe . C'est l'endroit où vous définissez les hôtes (hostgroups, voir ci-dessous) et les rôles qui seront appliqués à ces hôtes.

[databases] et les autres entrées dans votre inventaire sont des groupes d'hôtes. Les groupes d'hôtes définissent un ensemble d'hôtes sur lesquels un jeu sera exécuté.

Un jeu est un ensemble de tâches ou rôles (ou les deux) à l'intérieur d'un playbook. Dans la plupart des cas (et exemples), un playbook ne contiendra qu'une seule pièce. Mais vous pouvez en avoir autant que vous le souhaitez. Cela signifie que vous pourriez avoir un playbook qui se déroulera le rôle postfix sur les groupes d'hôtes mail_servers et le rôle mysql sur les groupes d'hôtes databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Si les Playbooks sont définis dans les fichiers YAML, alors où les rôles sont-ils définis?

Dans Ansible à peu près tout est défini dans YAML, qui compte pour les rôles et les playbooks.

Mis à part l'ansible.cfg vivant sur le serveur Ansible, comment ajouter / configurer Ansible avec les Playbooks/rôles disponibles? Par exemple, quand je lance Ansible-playbook someplaybook.yaml, comment Ansible sait où trouver ce playbook?

AFAIK vous devez fournir le chemin d'accès au playbook lors de l'appel de ansible-playbook. Donc ansible-playbook someplaybook.yaml s'attendrait {[8] } pour être dans votre répertoire actuel. Mais vous pouvez fournir le chemin complet: ansible-playbook /path/to/someplaybook.yaml

24
répondu udondan 2015-08-19 16:50:45

C'est une question terminologique/sémantique. Cela peut être subjectif, même s'il existe une définition de base.

Mon point de vue est le suivant:

Tout système de gestion/déploiement de la configuration a:

  1. source data - données utilisées pour créer la configuration de l'hôte cible
  2. target data - données utilisées pour identifier les hôtes cibles
  3. config changes - Liste / ensemble de règles / actions que nous appliquons avec source data sur l'hôte cible basé sur target data

Dans Ansible conditions:

  1. source data - est les différents lieux, on peut mettre des données - group_vars, playbook vars, role var, etc., Ces endroits affectent la priorité (si une variable nommée la même est redéfinie dans différents endroits, il existe des règles très spécifiques de ce qui serait la valeur de la variable pendant ansible/ansible-playbook exécution
  2. target data - est l'inventaire (et, il est également possible de définir des variables d'inventaire/groupe d'hôtes dans l'inventaire!)
  3. config changes - ansible a 4 niveaux d'abstraction pour il:
    1. tâche-action unique
    2. liste des tâches - liste des actions
    3. rôle-liste d'actions (ou liste de listes) regroupées par le même 'sujet', généralement toutes les cibles opèrent sur le même hôte / groupe d'hôtes
    4. playbook-liste de jeux, chacun fonctionnant sur un groupe d'hôtes éventuellement différent, appliquant plusieursroleS/tasks/tasklists (et des tâches spéciales comme handlers)

De l'aspect 'logiciel' - le rôle devrait être assez générique pour être réutilisé .

Dans certaines organisations (plutôt grandes), les "rôles" sont expédiés par le groupe A, alors qu'ils sont utilisés dans les playbooks gérés par le groupe B.

Résumé

Tout ce qui précède permet le regroupement de configurations similaires-dans un role. regroupement des sous-systèmes/composants connexes en un seul playbook. En outre, il convient de mentionner, 1 élément YAML dans un playbook (y compris hosts: et soit ou tasks, pre_tasks, post_tasks, roles) est appelé un play

Maintenant pour votre question:

Oui, c'est déroutant au début.

Vous connectez généralement votre source data à la sémantique de votre rôle, donc quand vous voyez ce rôle setup_db est appliqué dans un jeu sur un groupe d'hôtes associé (par exemple db_hosts) Mais un {[23] } peut être exécuté sur une union de plusieurs groupes d'hôtes. C'est juste une question de convention vs flexibilité.

P.S.

Écrivez-moi si cela a ajouté à la confusion, ou clarifié. Grâce.

2
répondu mvk_il 2017-09-07 21:40:52

Gardez également à l'esprit qu'un playbook peut appeler plus d'un rôle si un méta-fichier est utilisé pour affecter les différents rôles.

Exemple Playbook: dual_role-playbook.yml

- name: Some Action for two roles
  hosts: localhost

  vars_files:
    - roles/dual_role/meta/main.yml

  roles:
    - dual_role/container-1
    - dual_role/container-2

Le dossier de rôle et le schéma de fichiers ressembleront à ceci:

dual_role-playbook.yml
  -- roles
     -- dual_role
        -- meta/main.yml
        -- container-1
           -- tasks/main.yml
           -- templates/template.j2
        -- container-2
           -- tasks/main.yml
           -- templates/template.j2
0
répondu Jose H. Rosa 2017-08-16 19:19:04