Revenons à ansible un peu dans ce nouvel article avec deux nouvelles utilisations simples et très utiles :

• la possibilité de créer une clef SSH et de la pousser sur les machines cibles
• l’ajout d’une tâche de reboot (après upgrade par exemple) et la reprise des tâches où on en était resté

Donc des tâches simples mais courantes d’un administrateur système sous linux.

Créer une clef SSH et la déployer sur votre parc avec Ansible

Pour faire cela, nous allons réaliser deux tâches différentes avec deux modules disctincts :

• openssh_keypair : pour créer une clef SSH avec différents paramètres
• authorized_key : pour déployer la clef publique dans le fichier authorized_keys de vos utilisateurs

Créer une clef c’est bien mais en créer une différente sur chaque machine ne sera pas forcément une grande idée. Certes, niveau sécurité vous auriez une infrastructure un peu plus robuste, mais la gestion des clefs risque vite de déborder et devenir insoutenable.

Ainsi, si vous souhaitez passer par ansible pour créer le jeu de clefs SSH (privée et publique), je vous invite à faire tourner cette tâche sur le serveur ansible en local.

Ainsi, nous allons jouer une partie de playbook de la manière suivante :

- name: mon premier playbook
  hosts: all
  remote_user: vagrant
  tasks:
  - name: generate SSH key"
    openssh_keypair:
      path: /tmp/xavki
      type: rsa
      size: 4096
      state: present
      force: no
    run_once: yes
    delegate_to: localhost

J’ai pris des options de base qui peuvent être renforcées (notammen ajouter une passphrase est indispensable).

Nous utilisons donc le module openssh_keypair en lui demandant de créer un jeu de clefs “xavki” de type rsa et de longueur 4096. Et pour faire cela sur le serveur ansible nous lui ajoutons le paramètre delegate_to en mentionnant localhost (run local). Bien sûr ansible souhaite par défaut faire tourner cette tâche pour toutes les machines du groupe all tel que mentionné dans “hosts”. C’est pourquoi avec un run_once à yes, nous allons limiter ce run à une seule itération c’est à dire pour la première machine du groupe all.

Pour le déploiement de la clef publique dans le authorized_key, là encore ansible fournit une module bien pratique.

  - name: Deploy SSH Key
    authorized_key: 
      user: devops
      key: "{{ lookup('file', '/tmp/xavki.pub') }}"
      state: present
    become: yes

On ajoute un become yes pour que notre user puisse avoir suffisament de droit pour aller dans les homes de tous les utilisateurs. Ensuite on va rechercher le contenu de notre clef publique localement (serveur ansible) avec un lookup de type file et on indique pour cible le user nommé “devops”.

Et le tour est joué !!!

Comment organiser un reboot après un upgrade avec ansible ?

Le module reboot de ansible est très utile. Il permet de lancer un reboot intercalé entre différentes taches et de reprendre celles-ci où elles en étaient arrivées avant de lancer le reboot. C’est bon ça, non ?

Alors comment lancer un reboot après une mise à jour du noyau par exemple ou lorsqu’un reboot est requis ?

 - name: update cache
      apt:
        update_cache: yes
        force_apt_get: yes
        cache_valid_time: 3600

    - name: upgrade général
      apt:
        upgrade: dist
        force_apt_get: yes

    - name: vérification à partir du fichier reboot_required
      register: __reboot_required_file
      stat:
        path: /var/run/reboot-required

    - name: lancement du reboot avec reboot
      reboot:
        msg: "Reboot via ansible"
        connect_timeout: 5
        reboot_timeout: 300
        pre_reboot_delay: 0
        post_reboot_delay: 30
        test_command: uptime
      when: __reboot_required_file.stat.exists

Dans la première tâche, on lance une mise à jour du cache apt puis dans la seconde on réalise un dist-upgrade (dans notre exemple).

Sur debian, lorsque qu’un reboot est nécessaire, un fichier temporaire est créé dans /var/run/reboot-required. Donc réalisons un stat sur ce fichier pour tester sa présence.

Donc en dernière tâche, on se base sur __reboot_required et sa clef stat.exists pour vérifier la présence de ce fichier. Si celui-ci est là on lance un reboot.

Pour le reboot, on lance aux utilisateurs connectés un message, et on lance un reboot sans attendre avec pre_reboot_delay. On laisse 5min à la machine pour rebooter, puis 30s d’après reboot et 5 secondes pour se connecter ensuite en SSH dessus. Dans le cas contraire la tâche plantera. Et pour valider cette tâche de reboot on lance enfin un uptime.

Et voilà le tour est joué. Rien de complexe pour deux tâche rudimentaires.

Oubliez pas de venir visiter la chaine Xavki et de vous abonner pour découvrir les plus de 1100 tutoriels.