Share
Ceci est la deuxième partie d'un didacticiel en deux parties sur Ansible. La première partie est ici. Dans cette partie, vous en apprendrez plus sur les rôles (éléments constitutifs d'Ansible), les variables, les boucles, comment utiliser les rôles dans les playbooks et comment organiser les rôles dans une structure de répertoires.
Lorsque vous gérez des dizaines, des centaines ou plus de serveurs, il est probable que bon nombre d'entre eux doivent être configurés de la même manière. Différents groupes de serveurs, tels que les serveurs Web ou les serveurs de base de données, nécessiteront leur propre configuration spéciale, mais pourront également partager certaines fonctionnalités communes. Il est bien sûr possible de simplement copier des tâches, mais cela vieillit très vite s’il s’agit d’une infrastructure compliquée..
Les rôles correspondants sont le ticket. Les cahiers peuvent inclure des rôles. Les rôles peuvent dépendre d'autres rôles, et les meilleures pratiques Ansible recommandent de regrouper les hôtes dans votre fichier d'inventaire en fonction de leurs rôles. Les rôles sont l’épine dorsale d’une infrastructure sérieuse gérée par Ansible. Comme d'habitude, je commencerai par un exemple et présenterai de nombreuses capacités des rôles à travers l'exemple..
J'aime beaucoup les alias et les fonctions de shell parce que je ne me souviens pas de tous les commutateurs et options mystérieux de chaque commande, mais également parce que cela évite beaucoup de frappe. J'aime aussi avoir des outils comme htop et tmux sur chaque serveur auquel je me connecte.
Voici un fichier contenant certains de mes alias et fonctions préférés. Je l'appellerai '.gigirc'. En passant, si vous vous êtes déjà demandé ce que le suffixe "rc" représente dans tous ces fichiers rc, il signifie "Run Commands"..
alias sv = "sudo vim" alias py = "python" alias pi = "pip install" # Liste du répertoire dans un joli format alias lla = "ls -lAGh" # Recherche des fichiers de taille zéro alias lsz = "find. -type f - taille 0 -exec ls \; " # Supprime récursivement tous les fichiers * .pyc, alias rmpyc = "find. -Name" * .pyc "-print0 | xargs -0 rm" # Utilisation du disque qui trie également les résultats par taille et les enregistre dans un alias de fichier dus = "du - Pscmx * | sort -nr | tee disk_usage.txt "alias g =" git "alias gci =" git commit -a "alias gcia =" git commit -a - amend "alias gb =" branche de git "alias gbd =" git branch -D "alias gco =" git checkout "alias gpu =" git pull --rebase "alias gg =" git grep -i "alias gs =" git status "alias gd =" git diff "alias gl =" git log --oneline "# Affiche tous les fichiers et répertoires non suivis dans le répertoire courant alias ng =" git clean -n -d. " # Récupère et suit la fonction de branche distante gfr git checkout --track -b $ 1 origine / $ 1 # Crée une branche git distante (et locale aussi) à partir de la fonction maître gbr gco maître gb $ 1 g origine push -u $ 1
Définissons un rôle appelé 'commun' qui crée un utilisateur appelé 'gigi', ajoute une clé publique ssh, copie le fichier '.gigirc' et ajoute une ligne à la fin de '~ / .bashrc' qui exécute ce fichier et enfin installe les paquetages communs vim, htop et tmux (définis dans le fichier 'vars / main.yml').
Je vais présenter un lot de nouvelles choses ici: quatre modules différents, des variables et des boucles. En outre, les rôles sont généralement répartis sur plusieurs fichiers dans une structure de répertoires standard. Je vais vous montrer quelques fichiers, puis expliquer la structure des répertoires. Voici le fichier 'tasks / main.yml':
Accentsconagua
--- - nom: créer un utilisateur nommé gigi utilisateur: nom = gigi - nom: ajouter une clé publique clé autorisée: utilisateur = clé gigi = "lookup ('fichier', '~'. '. / .ssh / id_rsa.pub') -" nom : Copiez le fichier .gigirc dans le répertoire de base du nouvel utilisateur gigi copy: src = ~ / .gigirc dest = / home / gigi / .gigirc propriétaire = gigi groupe = gigi mode = 0644 - nom: exécutez .gigirc à partir de .bashrc lineinfile: dest = / home / gigi / .bashrc line = "source /home/gigi/.gigirc" - name: Installe les paquets communs apt: name = item state = est installé update_cache = true force = yes with_items: COMMON_PACKAGES Et voici le fichier vars / main.yml qui contient la définition de la variable 'COMMON_PACKAGES' utilisée pour spécifier les packages communs à installer..
--- PACKAGES COMMUNS: - vim - htop - tmux
Le module utilisateur peut gérer les comptes utilisateur. Ici, je l'utilise pour créer l'utilisateur 'gigi'.
Le module registered_key sert à ajouter / supprimer des clés autorisées SSH. Ici, je l'utilise pour ajouter ma clé publique à l'utilisateur 'gigi'.
Le module lineinfile peut être utilisé pour remplacer ou ajouter des lignes simples à un fichier. Dans ce cas, je l'utilise pour créer le fichier ".gigirc" à partir de ".bashrc", de sorte que tous les alias et fonctions intéressants de ".gigirc" soient toujours disponibles dans toute session interactive..
Enfin, le module apt dispose de nombreuses options pour gérer les paquets apt. Ici je viens d'installer des paquets communs.
le PACKAGES COMMUNS vous voyez dans la dernière tâche pour l'installation de packages communs est une variable. Ansible vous permet d'utiliser des variables définies presque partout: playbooks, inventaire, rôles, fichiers dédiés et même des variables d'environnement. Il y a beaucoup plus d'informations sur les variables dans la documentation.
Ansible est déclaratif, il ne prend donc pas en charge les boucles explicites. Mais il y a une pléthore de avec_xxx cela vous permet d'effectuer des opérations répétées sur une structure telle qu'une liste d'utilisateurs, des packages. ou des lignes dans un fichier. Vous pouvez également répéter des opérations jusqu'à ce qu'une condition soit vérifiée ou obtenir l'index de l'élément en cours. Des informations supplémentaires peuvent être trouvées dans la documentation.
Voici à quoi peut ressembler une structure de répertoire de rôles typique:
commun
├── les manutentionnaires
│ └── main.yml
├── méta
│ └── main.yml
├── tâches
│ └── main.yml
├── modèles
└── vars
├── Debian.yml
├── Ubuntu.yml
└── main.yml
Le fichier "tasks / main.yml" est l'emplacement où toutes les tâches sont définies. Chaque tâche correspond à une commande Ansible utilisant généralement un module..
Le fichier 'meta / main.yml' contiendra une liste des autres rôles dont dépend le rôle actuel. Les tâches de ces rôles seront exécutées avant le rôle actuel, ce qui permet de s'assurer que toutes les conditions préalables sont remplies..
Le fichier 'handlers / main.yml' est l'endroit où vous conservez vos gestionnaires, comme le gestionnaire que vous avez vu précédemment qui démarre Nginx après l'installation.
Le répertoire des modèles est l'endroit où vous conservez les modèles de configuration Jinja2 et les autres fichiers que vous souhaitez renseigner et copier sur le système cible..
Le répertoire vars contient diverses variables et peut conditionnellement contenir différentes valeurs pour différents systèmes d'exploitation (cas d'utilisation très courant)..
Il est important de noter qu'Ansible est très flexible et que vous pouvez tout mettre presque n'importe où. Ceci est juste une structure possible qui a du sens pour moi. Si vous regardez les structures de répertoires d'autres personnes, vous verrez peut-être quelque chose de complètement différent. C'est totalement bien. Ne vous inquiétez pas. Ansible n'est pas normatif, même s'il fournit des indications sur les meilleures pratiques.
Les rôles font le gros du travail, mais les cahiers sont la façon dont vous travaillez réellement. Les playbooks associent l'inventaire et les rôles et spécifient les rôles à jouer sur quel hôte. Voici à quoi ressemble un livre de jeu avec des rôles:
--- - hôtes: tous les rôles: - rôles / communs
L'exécution du livret produit le résultat suivant:
ansible-playbook -i accueille playbook_with_roles.yml --sudo JOUER ********************************* *************************************** TASK [setup] ******** ************************************************* ********* ok: [larry] ok: [moe] ok: [frisé] TÂCHE [rôles / commun: créer un utilisateur nommé gigi] ************** ******************* changé: [curly] changé: [moe] changé: [larry] TASK [rôles / common: Ajouter une clé publique] ****** ************************************* a changé: [larry] a changé: [frisé] a changé: [ moe] TASK [rôles / common: copie le fichier .gigirc dans le répertoire de base du nouvel utilisateur gigi] *** modifié: [moe] modifié: [larry] modifié: [curly] TASK [rôles / commun: installe les packages communs. ] ********************************** a changé: [curly] => (item = [u'vim ' , u'htop ', u'tmux']) a changé: [moe] => (item = [u'vim ', u'htop', u'tmux ']) a changé: [larry] => (item = [ u'vim ', u'htop', u'tmux ']) JOUER LE RELEVE ******************************* ************************************** curly: ok = 5 changé = 4 un accessible = 0 échec = 0 larry: ok = 5 modifié = 4 inaccessible = 0 échoué = 0 moe: ok = 5 modifié = 4 inaccessible = 0 échoué = 0
Ansible est un excellent outil. C'est léger. Il peut être utilisé de manière interactive avec des commandes ad-hoc et s'adapte très bien aux systèmes volumineux. Il a également beaucoup d'élan et une grande communauté. Si vous gérez ou même travaillez avec des serveurs distants, vous voulez Ansible.
