Journal Faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 (Suite)

• # pas besoin de ssh

  Posté par kna le 24 mai 2020 à 23:13. Évalué à 10.

  

  Si tu veux exécuter ton playbook localement, tu n'as pas besoin de te connecter à localhost en SSH.

  sudo apt install ansible git
  git clone https://gitlab.com/stephane.gambus/my-deb-laptop-ansible.git
  cd my-deb-laptop-ansible
  ansible-playbook -b --connection=local playbook.yml
  

  Voir aussi : ansible-pull

  Par ailleurs, plutôt que de faire un sed sur /etc/ansible/ansible.cfg, tu peux faire un ansible.cfg à la racine de ton repo. Par contre il faudra être dans le dossier quand tu exécute ansible-playbook pour qu'il soit lu, cf ansible configuration settings location

  • [^] # Re: pas besoin de ssh

    Posté par guitou le 25 mai 2020 à 12:45. Évalué à 1.

    

    Pour la gestion d'une seule machine en local, le ssh peut en en effet sembler un peu beaucoup too much, mais pour avoir eu le loisir de jouer un peu avec ansible, j'ai pu constater que la connexion n'est pas toujours évidente et qu'un mode de connexion harmonisé aux différents hôtes est pratiquement indispensable pour un fonctionnement normal d'ansible (sans quoi la délégation peut avoir des ratés, notamment). Donc, à mon sens, que ce soit pour gérer plusieurs machines ou garder la possibilité de séparer le contrôleur ansible, la connexion ssh n'est pas dénuée d'intérêt (et réserver la notion de "local" aux opérations propres au contrôleur ansible).

    ++
    Gi)

  • [^] # Re: pas besoin de ssh

    Posté par stephane.gambus le 25 mai 2020 à 21:59. Évalué à 1.

    

    Merci de vos retours particulièrement enrichissants !

    Voici ce que j'ai réalisé:
    - ajout de l'option "--connection=local" sur l'appel de ansible-playbook dans le fichier Makefile.
    - ajout du fichier ansible.cfg à la racine du projet
    - modif du fichier README.md

    Cela fonctionne à merveille en local.

    Par contre, j'ai regardé docker-pull, et je n'ai pas encore bien saisi le fonctionnement.

    De ce que je comprends, pour que cela fonctionne à la fois en localhost et sur un client ansible distant, il faudrait:
    - préciser dans le fichier host
    [remote]
    192.168.10.24 ansible_connection=ssh ansible_user=foo

    [local]
    127.0.0.1

    • remplacer dans le Makefile "ansible-playbook" par "ansible-pull"
    • installer un serveur ssh + générer clé plublique/privée
    • faire des actions sur 192.168.10.24 sur host [local]
      • installer un client ssh
      • ajout de clé ssh publique du serveur ansible (celle du host [local] )
      • initier une première connexion ssh sens [remote] --> [local] et répondre 'yes'
      • faire quelque chose dans dans crontab ?

    En tout cas, cela simplifie grandement la liste des actions pré-requises !

    • [^] # Re: pas besoin de ssh

      Posté par kna le 26 mai 2020 à 00:18. Évalué à 4.

      

      En fait ansible-pull c'est juste un script de fainéant qui va cloner ton repo et exécuter localement le playbook avec une seule commande. Mais c'est équivalent aux commandes que j'ai posté dans mon précédent commentaire.

      En fait, quand tu utilises --connection=local, il exécute le playbook localement. Donc si ton playbook contient :

      - hosts: foo
      

      Il va considérer que l'hôte local est foo. Il va chercher foo dans ton fichier hosts et trouver ainsi les variables correspondantes dans group_vars/ et host_vars/. Si tu n'as qu'une seule machine dans ton inventaire, tu peux utiliser all dans ton playbook comme c'est le cas actuellement.

      Personnellement, j'ai toujours utilisé des noms d'hôtes, donc je ne sais pas ce que ça donne si tu mets directement des adresses IP dans ton inventaire.

      J'étais parti du principe que tu l'utilisais juste localement à l'install.

      Si tu veux utiliser à la fois les connections locales et SSH, il faudra soit avoir un playbook dédié à l'utilisation locale, soit utiliser ansible_connection dans ton inventaire pour cibler ta machine locale (et ne pas utiliser l'argument --ansible-connection=local)

      Attention, comme dit le commentaire plus haut, ça peut poser problème de mixer les connections SSH et locales avec plusieurs machines à gérer, notamment si tu utilises des délégations, ou certains modules comme synchronise.

      <ma vie>
      Je gère mes machines perso avec ansible. 2 VPS et 2 laptops (boulot et perso). C'est pour des besoins assez simple, toutes mes machines sont différentes (pas de LB/failover) donc j'ai un playbook par machine et je n'utilise pas de délégation.
      J'utilise SSH pour les serveurs. Pour les laptops, j'ai un cron qui récupère mon repo et exécute localement le playbook correspondant à la machine. Si je fais une modif je la pousse sur les serveurs et les laptops l'appliqueront lorsqu'ils seront allumés.

      Par contre, actuellement je ne vois pas le résultat des exécutions cronées. Faut que je me décide entre :
      * une bête alerte renvoyée par le cron si l'exécution renvoie une erreur
      * rediriger l'output dans un log et centraliser les logs sur un serveur
      * utiliser ARA
      </ma vie>

      • [^] # Re: pas besoin de ssh

        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 18 juin 2020 à 22:47. Évalué à 0.

        

        Personnellement, j'ai toujours utilisé des noms d'hôtes, donc je ne sais pas ce que ça donne si tu mets directement des adresses IP dans ton inventaire.

        Ça marche très bien aussi les adresses IP :) Ou même des alias en tout genre, définis au niveau de ton /etc/hosts ou au niveau de ton ~/.ssh/config …parce-qu'au final, Ansible s'appuie sur ton SSH (du moins pour ce type de connexion, le local par exemple étant légèrement différent)

        Pour aller plus loin, tu peux utiliser des alias Ansible… le nom défini dans l'inventaire sera utilisé comme item/host affiché lors du déroulement, mais le nom/adresse/alias (complet ou court) utilisé en vrai (donc passé à l'appel SSH sous-jacent) est donné alors par la variable d'hôte ansible_host

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: pas besoin de ssh

        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 18 juin 2020 à 23:11. Évalué à 0.

        

        Petite remarque intéressante

        Par contre, actuellement je ne vois pas le résultat des exécutions cronées. Faut que je me décide entre :
        * une bête alerte renvoyée par le cron si l'exécution renvoie une erreur
        * rediriger l'output dans un log et centraliser les logs sur un serveur
        * utiliser ARA

        Pour le premier point, il me semble que c'était le cas par défaut (je mets l'imparfait parce-que je ne jure de rien avec systemd) Quand il y a une erreur, ou si une sortie est générée, alors tu en auras une trace dans les journaux. De plus, les systèmes traditionnels, pourvu que tu actives l'option (une variable à positionner), un mail est alors envoyé au propriétaire de la crontab en cas d'erreur ou si une sortie est générée. Par contre, si l'envoie de messages n'est pas configuré, ces messages vont juste se retrouver dans le fichier de messages localement. (les gens ne le savent pas toujours et laissent le spool gonfler ad vitam eternam…)

        Pour le second point, Ansible a une directive prévue à rajouter dans le ansible.cfg dans la section [default] : log_path = chemin/vers/le/fichier/de/log …Il faut juste que ce fichier puisse être écrit par le compte avec lequel tu lances les commandes ansible*
        C'est presque comparable au fait de faire suivre l'exécution de son playbook par des redirections (ou mieux | tee quand on est devant), mais en mieux car ça a une vraie tête de journal : les lignes sont précédées de l'horodatage ainsi que le compte et le PId exécutant ; ce qui est pratique bien des fois.

        ARA est l'étape au dessus : ça défini juste une autre sortie parallèle qui enregistre les informations dans une base de données et permet ensuite de consulter la métrologie via une interface web (bon, en vrai il y a une API pas mal aussi ce qui fait que les usages peuvent être repensés/démultipliés) Cette couche supplémentaire a de l'intérêt quand on travaille quotidiennement et en équipe avec Ansible et qu'on n'est pas prêt à des solutions plus lourdes comme Tower/AWX.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.