Ansible tablettes playbook vs Rôles

Selon l'Ansible docs, Playbook
est:

...la base pour un vraiment simple de gestion de la configuration et de déploiement sur plusieurs machines du système, contrairement aux autres qui existent déjà, et qui est très bien adapté pour le déploiement d'applications complexes.

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

...façons de charger automatiquement certaines vars_files, les tâches et les gestionnaires basés sur une structure de fichier. Le regroupement du contenu par les rôles permet également le partage des rôles avec d'autres utilisateurs.

Cependant la distinction entre ces derniers et leurs différents cas d'utilisation n'est pas immédiatement évident pour moi. Par exemple, si je configurer mon /etc/ansible/hosts fichier à ressembler à:

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

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

...alors qu'est-ce que cette "[databases]" l'entrée...un rôle? Ou le nom d'un playbook fichier YAML quelque part? Ou quelque chose d'autre?!?

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

Playbook vs Rôle vs [databases] et des entrées similaires dans /etc/ansible/hosts
Si les tablettes playbook sont définies à l'intérieur des fichiers YAML, alors où sont les Rôles définis?
En dehors de la ansible.cfg vivant sur l'Ansible serveur, comment puis-je ajouter/configurer Ansible avec les tablettes playbook/Rôles? Par exemple, quand je lance ansible-playbook someplaybook.yaml, comment ne Ansible savoir où trouver ce playbook?

Les rôles sont un moyen de rendre le code dans les tablettes playbook réutilisables en mettant la fonctionnalité dans généralisé "bibliothèques" qui peut ensuite être utilisé dans toute playbook en tant que de besoin.

InformationsquelleAutor smeeb | 2015-08-19

ansible ansible-playbook

85

Playbook vs Rôle vs [bases de données] et similaires entrées dans /etc/ansible/hosts

[databases] est un nom unique pour un groupe d'hôtes. Il permet de faire référence à plusieurs hôtes par un nom unique.

Rôle est un ensemble de tâches et d'autres fichiers pour configurer un hôte de servir pendant un certain rôle.

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

Exemple de la documentation décrit l'exemple de projet. Il contient deux choses:
- Tablettes playbook. site.yml, webservers.yml, fooservers.yml sont tablettes playbook.
- Rôles: roles/common/ et roles/webservers/ contiennent des définitions de la common et webservers rôle en conséquence.
À l'intérieur 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 tablettes playbook sont définies à l'intérieur des fichiers YAML, alors où sont les Rôles définis?

Ils sont définis à l'intérieur de roles/* répertoires. Les rôles sont définis en utilisant la plupart du temps, les fichiers YAML, mais peut également contenir des ressources de tous types (files/, templates/). Selon la documentation définition de rôle est structuré de cette manière:
- Si les rôles/x/tâches/main.yml existe, les tâches qui y sont énoncés seront ajoutés à la
- Si les rôles/x/gestionnaires/main.yml existe, les gestionnaires qui y figurent seront ajoutés à la
- Si les rôles/x/vars/main.yml existe, les variables qui y figurent seront ajoutés à la
- Si les rôles/x/meta/main.yml existe, un rôle de dépendances qui y sont énoncés seront ajoutés à la liste des rôles (1.3 et plus tard)
- Toute copie tâches peut faire référence à des fichiers dans les rôles/x/fichiers/sans avoir à chemin relativement ou absolument
- Toutes les tâches de script peut scripts de référence dans les rôles/x/fichiers/sans avoir à chemin relativement ou absolument
- Le modèle de tâches peut faire référence à des fichiers dans les rôles/x/templates/sans avoir à chemin relativement ou absolument
- Toute incluent des tâches peut faire référence à des fichiers dans les rôles/x/tâches/sans avoir à chemin relativement ou absolument
Le fichier le plus important est roles/x/tasks/main.yml, vous définissez ici les tâches qui seront exécutées, lorsque le rôle est exécuté.

Côté de l'ansible.cfg vivant sur l'Ansible serveur, comment puis-je ajouter/configurer Ansible avec les tablettes playbook/Rôles? Par exemple, quand je lance ansible-playbook someplaybook.yaml, comment ne Ansible savoir où trouver ce playbook?
```
$ ansible-playbook someplaybook.yaml
```
Va chercher un playbook à l'intérieur du répertoire courant.
```
$ ansible-playbook somedir/somedir/someplaybook.yaml
```
Va chercher un playbook à l'intérieur de somedir/somedir/ répertoire.

Il est de votre responsabilité de mettre votre projet avec toutes les tablettes playbook et les rôles sur le serveur. Ansible n'a rien à voir avec cela.
- Merci @Yaroslav Admin (+1) - un rapide suivi question: vous dites que les rôles sont définis à l'intérieur de annuaires, mais alors ce qui définit le rôle? En d'autres termes, la webservers.yml playbook cartes de la [webservers] hôtes à la common et webservers rôle. Mais ce qui est exactement inclus avec le common rôle? Il n'y a pas moyen de définir que dans les répertoires, de sorte qu'il y a généralement les fichiers YAML à l'intérieur de ces "le rôle des répertoires"? Merci encore!
- Oui, vous avez raison, le rôle est défini par les fichiers de ce répertoire. Ils sont pour la plupart YAML, mais peut aussi contenir d'autres types de fichiers. Voir mise à jour de la réponse pour plus de détails.
InformationsquelleAutor Yaroslav Admin
31

Playbook vs Rôle vs [bases de données] et similaires entrées dans /etc/ansible/hosts

Rôles sont un moyen pour le groupe de tâches dans un récipient. Vous pourriez avoir un rôle pour la configuration de MySQL, un autre pour la configuration de Postfix, etc.

Un playbook définit ce se passe où. 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 d'autres entrées dans votre inventaire sont hostgroups. Hostgroups définir un ensemble d'hôtes, un jeu fonctionnera sur.

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 des 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 le groupe d'hôtes mail_servers et le rôle mysql sur le groupe d'hôtes databases:
```
- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql
```
Si les tablettes playbook sont définies à l'intérieur des fichiers YAML, alors où sont les Rôles définis?

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

Côté de l'ansible.cfg vivant sur l'Ansible serveur, comment puis-je ajouter/configurer Ansible avec les tablettes playbook/Rôles? Par exemple, quand je lance ansible-playbook someplaybook.yaml, comment ne Ansible savoir où trouver ce playbook?

Autant que je sache, vous devez fournir le chemin d'accès à la playbook lors de l'invocation de ansible-playbook. Donc ansible-playbook someplaybook.yaml attendre someplaybook.yaml être dans votre répertoire courant. Mais vous pouvez fournir le chemin d'accès complet: ansible-playbook /path/to/someplaybook.yaml

InformationsquelleAutor udondan
8

C'est une terminologie/question de sémantique. Il peut être subjective, même si il y a une définition de base.

Mon point de vue est comme suit:

Toute la gestion de configuration/système de déploiement a:
1. source data - les données utilisées pour créer des cibles de l'hôte de configuration
2. target data - les données utilisées pour identifier les hôtes de la cible
3. config changes la liste d'un ensemble de règles/actions s'appliquent, avec source data cours cible de l'hôte basé sur target data
Dans Ansible termes:
1. source data - est les différents lieux, on peut mettre des données - group_vars, playbook vars, role vars, etc., Ces lieux affecter la priorité (si une variable portant le même nom est ré-défini dans différents endroits, il y a des règles très précises de ce que serait la valeur de la variable au cours de ansible/ansible-playbook exécution
2. target data - est de l'inventaire (Et, Il est également possible de définir des stocks/groupe d'hôtes de variables à l'intérieur de stock!)
3. config changes - ansible a 4 niveaux d'abstraction pour elle:
  1. la tâche unique action
  2. liste des tâches - liste des actions
  3. rôle - liste des actions (ou d'une liste de listes) regroupés par le même "sujet", généralement, toutes les cibles sont en exploitation sur le même hôte/groupe d'hôtes
  4. playbook - liste de jeux, chaque exploitation sur plusieurs groupes d'hôtes, l'application de plusieurs roles/tasks/tasklists (et des tâches spéciales comme handlers)
De "logiciel" de l'aspect rôle doit être suffisamment générique pour être réutilisés.

Également dans certains (assez grand) les organisations, les "rôles" sont expédiés par le groupe A, tandis que dans les tablettes playbook maintenu par le groupe B.

sommaire

Tous les ci-dessus permet le regroupement de configurations similaires - dans un role.
le regroupement des sous-systèmes connexes/composants dans un playbook.
Aussi, la peine de mentionner, 1 YAML élément dans un playbook (y compris hosts: et soit ou tasks, pre_tasks, post_tasks, roles) est appelé un play

Maintenant à votre question:

Oui, c'est déroutant au premier abord.

Vous vous connectez habituellement votre source data à votre rôle de la sémantique, donc quand vous voyez que le rôle setup_db est appliquée dans un jeu sur les liés à des groupes d'hôtes (par exemple,db_hosts)
Mais un play peut être en cours d'exécution sur une union de plusieurs hostgroups.
C'est juste une question de convention vs flexibilité.

P. S.

Veuillez m'écrire en arrière si cela a ajouté à la confusion, ou de les clarifier.
Merci.

InformationsquelleAutor mvk_il

Également garder à l'esprit un playbook peut appeler plus d'un rôle si un méta fichier est utilisé qui est destiné à agir sur 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 rôle de dossiers et de fichiers système va ressembler à 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

InformationsquelleAutor Jose H. Rosa

0

Il suffit de mettre:

Un playbook est comme le programme principal, le contenu des instructions complètes pour terminer le travail. Cependant, pour de gros projets, il n'est pas souhaitable de mettre tous les détails en elle. Si vous avez besoin de rôle.

Un rôle est une sous-routine et permet généralement un objectif, comme par exemple l'installation d'un serveur de base de données. Vous pouvez le mettre dans roles/ répertoire, ou télécharger de la 3ème partie de rôles en donnant des Uri dans rolesfile.yml et demander ansible-galaxy pour les télécharger pour vous.

La [database] est un groupe hôte défini dans fichier d'inventaire de qui répertorie les hôtes qui appartiennent à la database groupe. Vous pouvez également spécifier un groupe de serveurs web en spécifiant quelque chose comme
```
[web]
web1.example.com
web2.example.com
```
Groupe web ou database peut ensuite être utilisé dans les tablettes playbook ou des rôles pour spécifier les hôtes à s'appliquer.

Les groupes peuvent également être utilisés dans la commande ansible pour exécuter des commandes ad hoc.

InformationsquelleAutor Ding-Yi Chen

Vous devez vous connecter pour publier un commentaire.

Dans Ansible termes:

sommaire

Maintenant à votre question:

P. S.