Playbooks Ansible vs Rôles

Selon la documentation Ansible, un Playbook est:

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

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

... moyens de charger automatiquement certains fichiers vars_files, tâches et gestionnaires basés sur une structure de fichiers 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 /etc/ansible/hostsfichier pour qu'il ressemble à:

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

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

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

Si quelqu'un pouvait m'expliquer les différences à ce sujet, ma compréhension d'Ansible serait grandement améliorée!

• Playbook vs Role vs [databases]et entrées similaires dans/etc/ansible/hosts
• Si les Playbooks sont définis à l'intérieur des fichiers YAML, où sont définis les rôles?
• En plus de la ansible.cfgvie sur le serveur Ansible, comment ajouter / configurer Ansible avec les playbooks / rôles disponibles? Par exemple, lorsque je cours ansible-playbook someplaybook.yaml, comment Ansible sait-il où trouver ce playbook?

Playbook vs Role vs [databases] 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.

Le rôle est un ensemble de tâches et de fichiers supplémentaires pour configurer l'hôte pour qu'il serve un certain rôle .

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

L'exemple de la documentation décrit un exemple de projet. Il contient deux choses:

• Playbooks. site.yml, webservers.yml, fooservers.ymlSont Playbooks.
• Rôles: roles/common/et roles/webservers/contiennent des définitions commonet des webserversrô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 à l'intérieur des fichiers YAML, où sont définis les rôles?

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

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

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

Mis à part le ansible.cfg vivant sur le serveur Ansible, comment ajouter / configurer Ansible avec les playbooks / rôles disponibles? Par exemple, lorsque j'exécute ansible-playbook someplaybook.yaml, comment Ansible sait-il où trouver ce playbook?

$ ansible-playbook someplaybook.yaml

Cherchera un playbook dans le répertoire actuel.

$ ansible-playbook somedir/somedir/someplaybook.yaml

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

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

Playbook vs Role vs [databases] et entrées similaires dans / etc / ansible / hosts

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

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

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

Une pièce de théâtre est un ensemble de tâches ou de rôles (ou les deux) dans un livre de jeu. Dans la plupart des cas (et exemples), un playbook ne contiendra qu'une seule lecture. Mais vous pouvez en avoir autant que vous le souhaitez. Cela signifie que vous pourriez avoir un playbook qui exécutera le rôle postfixsur le groupe d'hôtes mail_serverset le rôle mysqlsur le groupe d'hôtes databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Si les Playbooks sont définis à l'intérieur des fichiers YAML, où sont définis les rôles?

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

Mis à part le ansible.cfg vivant sur le serveur Ansible, comment ajouter / configurer Ansible avec les playbooks / rôles disponibles? Par exemple, lorsque j'exécute ansible-playbook someplaybook.yaml, comment Ansible sait-il où trouver ce playbook?

AFAIK vous devez fournir le chemin d'accès au playbook lors de l'appel ansible-playbook . Attendrais- ansible-playbook someplaybook.yamlje donc someplaybook.yamlà être dans votre répertoire actuel. Mais vous pouvez fournir le chemin complet:ansible-playbook /path/to/someplaybook.yaml

C'est une question de terminologie / 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 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 datal'hôte cible en fonction detarget data

En termes Ansible:

1. source data- est les différents endroits où nous pouvons mettre des données - group_vars, playbookvars, rolevars, etc. variable pendant ansible/ ansible-playbookexécution
2. target data - est l'inventaire (Et, il est également possible de définir des variables d'inventaire / de groupe d'hôtes dans l'inventaire!)
3. config changes - ansible a 4 niveaux d'abstraction pour cela:
   1. tâche - action unique
   2. liste des tâches - liste des actions
   3. role - liste d'actions (ou liste de listes) regroupées par le même `` sujet '', généralement toutes les cibles fonctionnent 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 plusieurs roles / tasks / listes de tâches (et des tâches spéciales telles que handlers)

Du point de vue «logiciel», le rôle doit être suffisamment générique pour être réutilisé .

De plus, dans certaines organisations (plutôt grandes), les `` rôles '' sont fournis 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 de regrouper des configurations similaires - dans un fichier role. regrouper les sous-systèmes / composants associés en un seul playbook. En outre, la valeur mentionnant, 1 article YAML dans un livre de jeux (y compris hosts:et soit ou tasks, pre_tasks, post_tasks, roles) est appelé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 que ce rôle setup_dbest appliqué dans un jeu sur un groupe d'hôtes associé (par exemple db_hosts), mais a playpeut être exécuté sur une union de plusieurs groupes d'hôtes. C'est juste une question de convention vs flexibilité.

PS

Veuillez m'écrire si cela a ajouté à la confusion ou clarifié. Merci.

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

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

Tout simplement:

Un playbook est comme le programme principal, il contient des instructions complètes pour terminer le travail. Cependant, pour les grands projets, il n'est pas souhaitable d'y mettre réellement tous les détails. Vous avez donc besoin d'un rôle.

Un rôle est un sous-programme et atteint généralement un objectif, par exemple configurer un serveur de base de données. Vous pouvez le mettre dans un roles/répertoire ou télécharger des rôles tiers en fournissant des URI rolesfile.ymlet en demandant à ansible-galaxy de les télécharger pour vous.

Le [database]est un groupe d'hôtes défini dans le fichier d'inventaire qui répertorie les hôtes appartenant au databasegroupe. Vous pouvez également spécifier un groupe de serveurs Web en spécifiant quelque chose comme

[web]
web1.example.com
web2.example.com

Grouper webou databasepeut ensuite être utilisé dans des playbooks ou des rôles pour spécifier les hôtes à appliquer.

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