Aujourd’hui on va parler automatisation, et même plus que ça on va parler industrialisation ! Mais pas comme vous l’imaginez, loin de nous les centaines de serveurs configurés en une commande, abordons le cas de notre ordinateur de travail ! Il y a quelques mois, j’ai voulu me mettre à Ansible, sauf qu’au même titre que beaucoup d’entre nous j’apprends souvent plus facilement quand j’ai une réalisation dans ma tête pour tester et expérimenter. Ce qui est bien tombé, car rapidement une idée de projet m’est apparue: “Et si j’automatisais l’installation de mes PCs (vim, Gnome, zsh…) avec Ansible ?”.

Au-delà du fun, un confort

Alors au départ, cela peut paraître un projet assez lourd et surtout gadget, mais au final en l’utilisant il s’est montré très pratique est constitue souvent un gain de temps précieux. Avant tout un peu de contexte sur mon organisation personnel. Tout d’abord, précisons que j’exerce le métier de consultant, ce qui signifie concrètement que je change de mission “régulièrement” donc possiblement d’ordinateur. De plus pour ceux qui me connaisse, ils savent que mes PCs ont régulièrement tendance à mourir inopinément, même quasi neuf #TeamChatNoir, ce qui m’oblige à tout recommencer. En ce qui concerne le système d’exploitation, j’utilise au quotidien Debian, aussi bien pour le professionnel que pour le loisir (2 PCs) que pour mon travail (1 PC), sur lesquels 90 % de l’environnement est identique.

Donc en soi ma situation semble confortable, en effet j’ai un écosystème similaire partout que j’ai adapté à mes besoins, ainsi je suis toujours “chez moi”. Sauf que… non, plusieurs soucis apparaissent au-delà des réinstallations qui peuvent du coup être assez chronophages surtout qu’on oublie souvent un utilitaire ou autre. Un problème bien plus handicapant au quotient m’a pas mal frustré, vous avez tous connu cette situation, vous êtes sur un de vos PC et là en travaillant vous trouvez un Alias ZSH qui vous fait gagner des heures ou encore un plug-in Vim génial que vous vous empressez d’installer. Sauf que quelques jours, semaines plus tard vous avez changé de PC et plus moyen de retrouver cet Alias pourtant si utile ou ce plug-in sans lequel vous êtes perdu. Du coup dans ce type de situation vous n’avez pas énormément de possibilités.

Autant vous dire que le choix est vite fait, on automatise !

Du dotfile à la configuration du fond d’écran

Certains d’entre vous peuvent se demander du coup comment j’exécute Ansible en local, c’est très simple celui-ci dispose d’une fonctionnalité lui permettant d’utiliser directement localhost sans avoir besoin de créer un serveur SSH ni de push une clé. Cela réduit pas mal les actions à faire pour pouvoir faire tourner Ansible sur un nouvel ordinateur, juste à installer Python, pip et Ansible et on est parti !

Ensuite on passe au cœur du sujet : automatiser l’installation. Pour cela, j’ai commencé très simplement par les packages que j’utilise, ce qui représente une petite liste d’outils aussi bien issue des dépôts apt que de Python. Il s’agit de fonctionnalité de base intégrée dans Ansible qui m’ont permis de me faire la main avec Ansible et aussi de commencer à réfléchir à l’organisation de ce projet. Voici un extrait du code qui permet d’installer les packages Debian que j’utilise et un package avec pip, simple efficace :

- name: "Install tools and stuff"
  become: "yes"
  apt:
    name: "{{ packages }}"
    state: latest
    autoclean: yes

- name: "Install AWS CLI"
  become: "yes"
  pip: >
   name=awscli
   state=latest

Assez rapidement je suis passé à mon besoin principal : versionner et industrialiser mes dotfiles ! Pour le coup j’ai de la chance, j’utilise Vim en IDE, Tmux en multiplexeur de terminal et zsh comme Shell, donc tout ce gère au travers de dotfiles. Cette partie a été triviale, même si c’est à partir de celle-ci que j’ai réellement commencé à utiliser mon script sur mes différents ordinateurs. Globalement pour industrialiser les fichiers de configuration j’ai deux cas, il n’y a pas besoin d’avoir des données dynamiques, comme pour zsh auquel cas je me contente d’une copie ou il faut le rendre dynamique auquel cas j’utilise les templates :

- name: "Add configuration files"
  become: 'yes'
  copy:
    src: ../files/{{item}}
    dest: "/home/{{ user }}"
    owner: "{{ user }}"
    group: "{{ user }}"
    mode: 0644
  with_items:
    ['.zshrc','.vimrc', '.tmux.conf']

- name: "Configure Gitfile"
  template: src=gitconig.j2 dest="/home/{{ user }}/.gitconfig"
  become: true
  become_user: "{{ user }}"

On passe ensuite à la sécurité, configurer son pare-feu peut mettre du temps du coup là aussi c’est assez rentable de l’automatiser, un petit template et c’est bon. Pour ne pas oublier, je le passe aussi en persistant, histoire qu’elles ne disparaissent pas au démarrage.

J’en profite aussi pour me créer un utilisateur avec une clé SSH (ed25519) et m’ajouter dans les sudœrs, c’est un ordinateur de travail personnellement je reste assez souple sur l’utilisation de sudo. Je ne ré-utilise par contre pas de clé SSH car je veux pouvoir révoquer la clé en fonction du PC, ce qui m’oblige à en créer une par périphérique.

On fini par le plus haut niveau, l’interface graphique Gnome3 et oui, on peut aussi l’automatiser. Celui-ci utilise Dconf en backend de GSettings, pour gérer les paramètres systèmes avec un système clés / valeurs, c’est assez simple à manipuler, le tout est de trouver la valeur et la clé correspondant à ce que l’ont veut modifier. Petit exemple ici, qui permet d’afficher le pourcentage de la batterie :

- name: "Gnome show battery percentage"
  become: "yes"
  become_user: "{{ user }}"
  dconf:
    key: "/org/gnome/desktop/interface/show-battery-percentage"
    value: "true"
    state: present

Vous pouvez découvrir et rechercher les différents paramètres de Gnome3 à l’aide de l’outil Dconf-Editor.

Voilà, pour ce qui est d’Ansible. Je n’ai pas parlé des plug-ins de Firefox, ni d’ailleurs des marque-pages c’est possible, mais à mon sens je préfère passer par la synchronisation native qui est très efficace et me permets de différencier mon environnent web professionnel et personnel totalement à ce niveau. Pour ce qui est des contacts et calendriers, je passe par une instance Nextcloud que j’héberge.

Vers l’infini et l’au-delà !

Au final je l’utilise aujourd’hui pour gérer une bonne partie de mon environnement et j’ai en projet d’ajouter des choses. Néanmoins, c’est parfois un peu frustrant de devoir aller dans le projet, pull les dernières modifications, faire de nouvelles, les appliquer et ensuite les commits. Mais au final c’est un moindre mal, l’automatisation est un sujet que j’adore et une fois son installation de Debian terminée sur un nouveau PC avoir un système qui fait tout pour vous, c’est satisfaisant et agréable.

De plus le code n’a pas besoin d’être ultra complexe pour gérer la majorité des besoins, ce qui est un gros plus.

Bon vous dire que c’est super c’est bien, mais c’est encore mieux de vous montrer à quoi ça ressemble ! Pour cela j’ai partagé le code sur Github : par ici. Le code n’est pas des plus optimal, cela reste un projet de test qui va s’améliorer avec le temps.

Je pense essayer aussi de pousser le concept plus loin, notamment par la mise en place d’un runner Gitlab sur mes PCs pour déployer les nouvelles configurations au commit ou encore développer les quelques features qui sont pour l’heure manuelles, comme par exemple installer ma clé publique PGP, upload automatiquement mes clés ssh créées, etc. Ce n’est clairement pas les possibilités qui manquent, n’hésiter pas à me donner des idées, même farfelues.

Le mot de la fin : Si vous souhaitez vous mettre à Ansible ca tombe bien Xavki sort une version remasterisée de ses vidéos Ansible ! Je ne peux que vous encourager à aller les voirs.