Utiliser Ansible pour déployer sa clé SSH et installer Python

30 décembre 2017

Si vous commencez Ă  utiliser Ansible, vous pouvez vous retrouver dans ce genre de situation :

Standing up Ansible to help manage my 30+ VPS’ and couldn’t help thinking….

“I really wish I had a tool like Ansible to deploy this SSH key to these 30+ systems…” /irony

— Eric Capuano (@eric_capuano) December 30, 2017

Vous avez un paquet de machines sur lesquels :

Ă€ ce moment lĂ , vous vous dĂ®tes que ce serait pas mal d’avoir un outil comme Ansible pour normaliser tout ça. Eh bien bonne nouvelle ! Je connais un outil qui s’appelle Ansible et qui permet de faire tout ça 🙂

La première chose à faire est de définir votre inventaire prenant en compte vos cas particuliers. Voici un exemple commenté :

# hosts.ini
# un serveur avec :
#  - un utilisateur particulier défini par 'ansible_user'
#  - pas de clé SSH, donc on défini le mot de passe via 'ansible_ssh_pass'
srv-01 ansible_user=notroot ansible_ssh_pass=topsecret
# un serveur avec :
#  - le compte root
#  - une clé SSH spécifique définie via 'ansible_ssh_private_key_file'
srv-02 ansible_user=root ansible_ssh_private_key_file=~/.ssh/id_srv02

Ensuite, la seconde première chose Ă  faire c’est d’installer Python sur toutes les machines. Pour cela on va Ă©crire un petit playbook qui utilisera le module raw permettant de balancer des commandes brutes Ă  travers SSH :

# bootstrap.yml
---
- hosts: all
  gather_facts: no
  become: yes
  tasks:
    - raw: test -e /usr/bin/python || ( [ $(command -v apt) ] && apt install -y python-minimal )
    - raw: test -e /usr/bin/python || ( [ $(command -v yum) ] && yum install -y python )
...

Ici j’ai utilisĂ© gather_facts: no pour Ă©viter qu’Ansible ne cherche Ă  rĂ©cupĂ©rer tout un tas d’informations sur le hĂ´tes, ce qui Ă©chouerait Python n’Ă©tant pas encore installĂ©. Le paramètre become: yes sert Ă  escalader les privilèges pour lancer les commandes en root. Et les tâches lancent une commande qui :

On a ainsi quelque chose qui fonctionne pour Debian, Ubuntu, RedHat, CentOS, Fedora, etc. Et qu’on lance avec la commande suivante:

$ ansible-playbook -i hosts.ini bootstrap.yml

La troisième et dernière des premières choses Ă  faire, c’est de dĂ©ployer la configuration normalisĂ©e que vous souhaitez (votre clĂ© SSH, votre user, etc.). On reprend donc notre playbook prĂ©cĂ©dent et on y ajoute les Ă©lĂ©ments suivants :

# bootstrap.yml
---
[…]
- hosts: all
  become: yes
  tasks:
    - name: create my main user
      user:
        name: myusername
        password: $6$shKSkXZIG0ZLHKOg$Ai1nQ0ETm0MavWCAapU7F5GXIK.Y9SjSDZHzUnAQB7CxgihYy8HaNKZlT.ij1DHGjeoOsRXWSDNuRgnhE5Uwg.
        groups: sudo, wheel
        append: yes
    - name: deploy my main ssh public key to my main user
      authorized_key:
        user: myusername
        key: "{{ lookup('file', '/home/nicolas/.ssh/id_ed25519.pub') }}"
...

On a utilisĂ© ici les modules user et authorized_keys, je vous laisse aller jeter un coup d’Ĺ“il Ă  la documentation de chacun pour voir la signification et l’utilisation des diffĂ©rents paramètres.

On relance l’exĂ©cution de notre playbook :

$ ansible-playbook -i hosts.ini bootstrap.yml

Et c’est terminĂ©. On peut maintenant nettoyer notre inventaire de ses variables spĂ©cifiques Ă  chaque hĂ´te, et utiliser les options dĂ©finies globalement dans le fichier ansible.cfg ou dans les variables de groupes.