GNU/Linux >> Tutoriels Linux >  >> Linux

RHCE Ansible Series #2 :Exécution de commandes ad hoc

Dans la première partie de la série Ansible, vous vous êtes familiarisé avec Ansible et avez appris à l'installer.

Dans ce didacticiel, vous apprendrez à gérer l'inventaire statique dans Ansible. Vous comprendrez également divers paramètres de configuration Ansible.

De plus, vous explorerez quelques modules Ansible et vous pourrez exécuter des commandes Ansible Ad-Hoc.

Avant de voir tout ça, je voudrais remercier tous les membres LHB Pro. Cette série Ansible est possible avec leur soutien. Si vous n'êtes pas encore membre pro, veuillez envisager d'opter pour l'abonnement.

Créer un utilisateur Ansible

Même si vous pouvez utiliser l'utilisateur root dans Ansible pour exécuter des commandes Ad-Hoc et des playbooks, ce n'est certainement pas recommandé et n'est pas considéré comme la meilleure pratique en raison des risques de sécurité qui peuvent survenir en autorisant l'accès ssh à l'utilisateur root.

Pour cette raison, il est recommandé de créer un utilisateur Ansible dédié avec des privilèges sudo (pour toutes les commandes) sur tous les hôtes (contrôle et hôtes gérés).

N'oubliez pas qu'Ansible utilise SSH et Python pour faire tout le sale boulot dans les coulisses. Voici donc les quatre étapes à suivre après l'installation d'Ansible :

  1. Créer un nouvel utilisateur sur tous les hôtes.
  2. Accordez les privilèges sudo au nouvel utilisateur sur tous les nœuds.
  3. Générez des clés SSH pour le nouvel utilisateur sur le nœud de contrôle.
  4. Copiez la clé publique SSH sur les nœuds gérés.

Alors, sans plus tarder, commençons par créer un nouvel utilisateur nommé elliot sur tous les hôtes :

[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot

Après avoir réglé elliot mot de passe sur tous les hôtes, vous pouvez passer à l'étape 2 ; vous pouvez accorder elliot privilèges sudo à toutes les commandes sans mot de passe en ajoutant l'entrée suivante à /etc/sudoers fichier :

[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers

Maintenant, connectez-vous en tant qu'utilisateur elliot sur votre nœud de contrôle et générez une paire de clés ssh :

[[email protected] ~]$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/elliot/.ssh/id_rsa):       
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/elliot/.ssh/id_rsa.
Your public key has been saved in /home/elliot/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Xf5bKx0kkBCsCQ/7rc6Kv6CxCRTH2XJajbNvpzel+Ik [email protected]
The key's randomart image is:
+---[RSA 3072]----+
|        .oo .    |
|  . ooo  . o     |
| . = *=.o   o    |
|  o =.o+ . o . . |
| . . .. S . . o  |
|.     .. . . . . |
|.. .   oo.o   o o|
|. = o oo++.  . +.|
| + ..++Eoo.   o. |
+----[SHA256]-----+

Enfin, vous pouvez copier elliot clé ssh publique à tous les hôtes gérés à l'aide de ssh-copy-id commande comme suit :

[[email protected] ~]$ ssh-copy-id node1
[[email protected] ~]$ ssh-copy-id node2
[[email protected] ~]$ ssh-copy-id node3
[[email protected] ~]$ ssh-copy-id node4

Vous devriez maintenant pouvoir vous connecter en ssh à tous les nœuds gérés sans être invité à entrer un mot de passe ; il vous sera uniquement demandé de saisir une phrase de passe ssh (si vous ne l'avez pas laissée vide, ha-ha).

Construire votre inventaire Ansible

Un fichier d'inventaire Ansible est essentiellement un fichier contenant une liste de serveurs, un groupe de serveurs ou des adresses IP faisant référence aux hôtes que vous souhaitez gérer par Ansible (nœuds gérés).

Le fichier /etc/ansible/hosts est le fichier d'inventaire par défaut. Je vais maintenant vous montrer comment créer vos propres fichiers d'inventaire dans Ansible.

Création d'un répertoire de projet

Vous ne voulez pas jouer avec /etc/ansible annuaire; vous devez tout conserver dans /etc/ansible intact et utilisez-le simplement comme référence lorsque vous créez des fichiers d'inventaire, modifiez des fichiers de configuration de projet Ansible, etc.

Maintenant, créons un nouveau répertoire de projet Ansible nommé dans /home/elliot jeux nommés que vous utiliserez pour stocker tous vos éléments liés à Ansible (playbooks, fichiers d'inventaire, rôles, etc.) que vous créerez à partir de maintenant :

[[email protected] ~]$ mkdir /home/elliot/plays

Notez que tout ce que vous créerez à partir de ce point sera sur le nœud de contrôle.

Création d'un fichier d'inventaire

Passez à /home/elliot/plays répertoire et créez un fichier d'inventaire nommé myhosts et ajoutez tous les noms d'hôte de vos nœuds gérés pour qu'il ressemble à ceci :

[[email protected] plays]$ cat myhosts 
node1
node2
node3
node4

Vous pouvez maintenant exécuter la commande Ansible suivante pour répertorier tous vos hôtes dans myhosts fichier d'inventaire :

[[email protected] plays]$ ansible all -i myhosts --list-hosts
  hosts (4):
    node1
    node2
    node3
    node4

Le -i l'option a été utilisée pour spécifier myhosts dossier d'inventaire. Si vous omettez le -i , Ansible recherchera les hôtes dans /etc/ansible/hosts fichier d'inventaire à la place.

Gardez à l'esprit que j'utilise des noms d'hôte ici et que tous les nœuds (vms) que j'ai créés sur Azure sont sur le même sous-réseau et je n'ai pas à me soucier du DNS car il est géré par Azure.

Si vous n'avez pas de serveur DNS fonctionnel, vous pouvez ajouter les entrées d'adresse IP/de nom d'hôte de vos nœuds dans /etc/hosts , ci-dessous un exemple :

Création de groupes et sous-groupes d'hôtes

Vous pouvez organiser vos hôtes gérés en groupes et sous-groupes. Par exemple, vous pouvez modifier le myhosts fichier pour créer deux groupes test et production comme suit :

[[email protected] plays]$ cat myhosts 
[test]
node1
node2

[prod]
node3
node4

Vous pouvez lister les hébergeurs dans la prod groupe en exécutant la commande suivante :

[[email protected] plays]$ ansible prod -i myhosts --list-hosts
  hosts (2):
    node3
    node4

Il existe deux groupes par défaut dans Ansible :

  1. all - contient tous les hôtes de l'inventaire
  2. ungrouped - contient tous les hôtes qui ne sont membres d'aucun groupe (mis à part tous).

Ajoutons un hôte imaginaire node5 aux mes hôtes fichier d'inventaire pour démontrer le dissocié groupe :

[[email protected] plays]$ cat myhosts 
node5

[test]
node1
node2

[prod]
node3
node4

Notez que j'ai ajouté node5 au tout début (et non à la fin) de myhosts fichier, sinon, il serait considéré comme un membre de la prod groupe.

Vous pouvez maintenant exécuter la commande suivante pour répertorier tous les éléments non groupés hôtes :

[[email protected] plays]$ ansible ungrouped -i myhosts --list-hosts
  hosts (1):
    node5

Vous pouvez également créer un groupe (parent) contenant des sous-groupes (enfants). Jetez un œil à l'exemple suivant :

[[email protected] plays]$ cat myhosts 
[web_dev]
node1

[web_prod]
node2

[db_dev]
node3

[db_prod]
node4

[development:children]
web_dev
db_dev

[production:children]
web_prod
db_prod

Le développement groupe contient tous les hôtes qui sont dans web_dev plus tous les membres qui sont dans db_dev . De même, la production groupe contient tous les hôtes qui sont dans web_prod plus tous les membres qui sont dans db_prod. 

[[email protected] plays]$ ansible development -i myhosts --list-hosts
  hosts (2):
    node1
    node3

[[email protected] plays]$ ansible production -i myhosts --list-hosts
  hosts (2):
    node2
    node4

Configurer Ansible

Dans cette section, vous découvrirez les paramètres de configuration Ansible les plus importants. Tout au long de la série, vous discuterez d'autres paramètres de configuration en cas de besoin.

Le fichier /etc/ansible/ansible.cfg est le fichier de configuration par défaut. Cependant, il est également recommandé de ne pas jouer avec /etc/ansible/ansible.cfg et utilisez-le simplement comme référence. Vous devez créer votre propre fichier de configuration Ansible dans votre répertoire de projet Ansible.

La version ansible --version La commande vous montrera quel fichier de configuration vous utilisez actuellement :

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Comme vous pouvez le voir sur la sortie, /etc/ansible/ansible.cfg est actuellement utilisé car vous n'avez pas encore créé votre propre ansible.cfg fichier dans le répertoire du projet.

Le fichier /etc/ansible/ansible.cfg contient un ensemble de divers paramètres et sections de configuration Ansible :

[[email protected] plays]$ wc -l /etc/ansible/ansible.cfg 
490 /etc/ansible/ansible.cfg

Les deux sections les plus importantes que vous devez définir dans votre fichier de configuration Ansible sont :

  1. [valeurs par défaut]
  2. [privilege_escalation]

Dans les [valeurs par défaut] section, voici les paramètres les plus importants que vous devez connaître :

  • inventaire - spécifie le chemin de votre fichier d'inventaire.
  • utilisateur_distant - spécifie l'utilisateur qui se connectera aux hôtes gérés et exécutera les playbooks.
  • fourchettes - spécifie le nombre d'hôtes qu'Ansible peut gérer/traiter en parallèle ; la valeur par défaut est 5.
  • vérification_clé_hôte - spécifie si vous souhaitez activer/désactiver la vérification de l'hôte de la clé SSH ; la valeur par défaut est True.

Dans le [privilege_escalation] section, vous pouvez configurer les paramètres suivants :

  • devenir - spécifier où autoriser/interdire l'élévation des privilèges ; la valeur par défaut est False.
  • devenir_méthode - spécifier la méthode d'escalade des privilèges ; la valeur par défaut est sudo.
  • devenir_utilisateur - spécifiez l'utilisateur que vous devenez par élévation de privilèges ; la valeur par défaut est root.
  • devenir_ask_pass - spécifier s'il faut demander ou non le mot de passe d'escalade de privilèges ; la valeur par défaut est False.

Gardez à l'esprit que vous n'avez pas besoin de valider ces paramètres en mémoire. Ils sont tous documentés dans /etc/ansible/ansible.cfg .

Créez maintenant votre propre ansible.cfg fichier de configuration dans votre répertoire de projet Ansible /home/elliot/plays et définissez les paramètres suivants :

Exécutez maintenant le ansible --version commander une fois de plus ; vous devriez voir que votre nouveau fichier de configuration est désormais effectif :

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /home/elliot/plays/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Exécuter des commandes ad hoc dans Ansible

Jusqu'à présent, vous venez juste d'installer, de configurer votre environnement et de configurer Ansible. Maintenant, le vrai plaisir commence !

Une commande ad hoc Ansible est un excellent outil que vous pouvez utiliser pour exécuter une seule tâche sur un ou plusieurs nœuds gérés. Une commande ad hoc typique d'Ansible suit la syntaxe générale :

ansible host_pattern -m module_name -a "module_options"

Le moyen le plus simple de comprendre le fonctionnement des commandes ad hoc Ansible est simplement d'en exécuter une ! Alors, allez-y et exécutez la commande ad-hoc suivante :

[[email protected] plays]$ ansible node1 -m command -a "uptime"
Enter passphrase for key '/home/elliot/.ssh/id_rsa':
node1 | CHANGED | rc=0 >>
18:53:01 up 5 days, 18:03,  1 user,  load average: 0.00, 0.01, 0.00

J'ai été invité à entrer ma phrase secrète de clé ssh, puis la disponibilité de node1 s'est affichée ! Maintenant, consultez la figure ci-dessous pour vous aider à comprendre chaque élément de la commande ad hoc que vous venez d'exécuter :

Vous l'auriez probablement deviné maintenant; modules ansibles sont des scripts réutilisables et autonomes qui peuvent être utilisés par l'API Ansible , ou par le ansible ou ansible - livre de jeu programmes.

Le module de commande est l'un des nombreux modules proposés par Ansible. Vous pouvez exécuter le ansible-doc -l commande pour lister tous les modules Ansible disponibles :

[[email protected] plays]$ ansible-doc -l | wc -l
3387

Actuellement, il y a 3387 modules Ansible disponibles, et ils augmentent de jour en jour ! Vous pouvez transmettre n'importe quelle commande que vous souhaitez exécuter en option au module de commande Ansible.

Si vous n'avez pas de phrase de passe de clé ssh vide (tout comme moi); alors vous devrez exécuter ssh-agent pour éviter le casse-tête inutile d'être invité à saisir une phrase de passe à chaque fois qu'Ansible essaie d'accéder à vos nœuds gérés :

[[email protected] plays]$ eval `ssh-agent`
Agent pid 218750
[[email protected] plays]$ ssh-add
Enter passphrase for /home/elliot/.ssh/id_rsa: 
Identity added: /home/elliot/.ssh/id_rsa ([email protected])

Tester la connectivité

Vous voudrez peut-être tester si Ansible peut se connecter à tous vos nœuds gérés avant de vous lancer dans des tâches plus sérieuses ; pour cela, vous pouvez utiliser le ping module et spécifiez tous vos hôtes gérés comme suit :

[[email protected] plays]$ ansible all -m ping 
node4 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
node3 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}

Comme vous pouvez le voir avec tout le SUCCÈS dans la sortie. Notez que le ping Ansible module n'a pas besoin d'options. Certains modules Ansible nécessitent des options et d'autres non, tout comme dans le cas des commandes Linux.

Documentation des modules Ansible

Si quelqu'un me demandait ce que vous aimez le plus chez Ansible; Je dirais rapidement que c'est la documentation. Ansible est très bien documenté et tout cela dans le confort de votre propre terminal.

Si vous voulez savoir comment utiliser un module Ansible spécifique, vous pouvez exécuter ansible-doc suivi du nom du module.

Par exemple, vous pouvez afficher la description du ping module et comment l'utiliser en exécutant :

[[email protected] plays]$ ansible-doc ping

Cela ouvrira le ping page de documentation du module :

Lors de la lecture de la documentation des modules, portez une attention particulière pour voir si une option est précédée du signe égal (=). Dans ce cas, il s'agit d'une option obligatoire que vous devez inclure.

De plus, si vous faites défiler vers le bas, vous pouvez voir quelques exemples d'exécution des commandes ad hoc ou des playbooks Ansible (dont nous parlerons plus tard).

Commande contre Shell contre modules bruts

Il existe trois modules Ansible que les gens confondent souvent les uns avec les autres; ce sont :

  1. commande
  2. coque
  3. brut

Ces trois modules atteignent le même objectif; ils exécutent des commandes sur les nœuds gérés. Mais il existe des différences clés qui séparent les trois modules.

Vous ne pouvez pas utiliser de canalisation ou de redirection avec la commande module. Par exemple, la commande ad hoc suivante entraînera une erreur :

[[email protected] plays]$ ansible node2 -m command -a "lscpu | head -n 5"
node2 | FAILED | rc=1 >>
lscpu: invalid option -- 'n'
Try 'lscpu --help' for more information.non-zero return code

C'est parce que la commande le module ne prend pas en charge les canaux ou la redirection. Vous pouvez utiliser le module shell à la place si vous souhaitez utiliser des canaux ou une redirection. Exécutez à nouveau la même commande, mais cette fois, utilisez le shell module à la place :

[[email protected] plays]$ ansible node2 -m shell -a "lscpu | head -n 5"
node2 | CHANGED | rc=0 >>
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0

Fonctionne comme un charme! Il a affiché avec succès les cinq premières lignes de la sortie de la commande lscpu sur node2.

Ansible utilise des scripts SSH et Python dans les coulisses pour faire toute la magie. Maintenant, le brut module utilise simplement SSH et contourne le sous-système de module Ansible. De cette façon, ce module brut fonctionnerait avec succès sur le nœud géré même si Python n'est pas installé (sur le nœud géré).

J'ai trafiqué mes binaires python sur node4 (veuillez ne pas le faire vous-même) afin que je puisse imiter un scénario de ce qui se passera si vous exécutez le shell ou commande module sur un nœud sur lequel Python n'est pas installé :

[email protected]:/usr/bin# mkdir hide
[email protected]:/usr/bin# mv python* hide/

Maintenant, vérifiez ce qui se passera si j'exécute un ad-hoc Ansible avec le shell ou commande module ciblant le nœud 4 :

[[email protected] plays]$ ansible node4 -m shell -a "whoami"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
}
[[email protected] plays]$ ansible node4 -m command -a "cat /etc/os-release"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error",
    "rc": 127
}

J'obtiens des erreurs ! Maintenant, je vais essayer d'accomplir la même tâche ; mais cette fois, j'utiliserai le raw modules :

[[email protected] plays]$ ansible node4 -m raw -a "cat /etc/os-release"
node4 | CHANGED | rc=0 >>
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Shared connection to node4 closed.

Comme vous pouvez le voir, le module brut était le seul module sur trois modules à mener à bien la tâche. Maintenant, je vais réparer le gâchis que j'ai fait sur node4 :

[email protected]:/usr/bin/hide# mv * ..

J'ai créé ce tableau ci-dessous pour aider à résumer les différents cas d'utilisation pour les trois modules :

Description Commande Coque Brut
Exécuter des commandes simples Oui Oui Oui
Exécuter des commandes avec redirection Non Oui Oui
Exécuter des commandes sans Python Non Non Oui

Très bien! Cela nous amène à la fin du deuxième tutoriel Ansible.

Restez à l'écoute pour le prochain didacticiel car vous allez apprendre à créer et à exécuter des playbooks Ansible. N'oubliez pas de devenir membre :)


Linux

  1. Exécution de commandes Linux en arrière-plan et au premier plan

  2. RHCE Ansible Series #8 :chiffrement de contenu avec Ansible Vault

  3. RHCE Ansible Series #7 :Modèles Jinja2

  4. RHCE Ansible Series #9 :Rôles Ansible

  5. Exécuter les commandes Shell à partir du programme exécuté dans WINE

Guide Ansible :la commande ad hoc

Premiers pas avec les commandes ansibles ad hoc

Mettez une minuterie sur vos commandes en cours d'exécution avec la commande Timeout sous Linux

RHCE Ansible Series #1 :Dites bonjour à Ansible

RHCE Ansible Series #3 :Playbooks Ansible

RHCE Ansible Series #12 :Dépannage Ansible