Le Blog Utux

Dans l'article Configuration et déploiement avec Ansible je livrais déjà quelques conseils issus de mon expérience. J'ai eu la chance de continuer à travailler sur cette technologie en entreprise et je livre donc les compléments suivants:

• L'idempotence est importante, c'est à dire la capacité à rejouer le même rôle une seconde fois. Si votre playbook doit créer un utilisateur (Unix ou mysql), pensez à ce qui peut se passer au bout de 6 mois. Imaginez qu'entre temps un collègue a changé le mot de passe root de Mysql et ne l'a pas mis à jour dans Ansible. Si vous rejouez le rôle, il sera écrasé et votre prod pourra potentiellement tomber. Pour cela restez à l'affut des options des modules, par exemple pour mysql_user on a update_password: on_create (on ne change le mot de passe que lors de la création du user, on y touche pas s'il existe déjà). C'est pareil avec le module user, si vous mettez le groupe "sudo", l'utilisateur sera mis dans ce groupe et retiré des autres! A moins d'utiliser l'option append: yes. Idempotence et anticipation!
• La documentation et le guide des bonnes pratiques de Ansible recommandent de faire des playbook webservers.yml, dbservers.yml, etc. Mais en pratique il est parfois plus approprié d'avoir 1 playbook par serveur (srv-web-01.yml, srv-web-02.yml, etc). Car dans la réalité de la production on a pas toujours la même chose sur les serveurs.
• Évitez d'éparpiller vos variables partout. Mettez-les dans le .yml du serveur si possible, puis dans le group_vars/groupe et c'est tout. Évitez les host_vars ou encore les roles/truc/vars car cela peut rapidement devenir un enfer de retrouver où sont définies les variables. Parfois il vaut mieux faire moins optimisé mais plus lisible.
• Ne faites pas trop de groupes, car l'inventaire de base (constitué d'un fichier) peut rapidement devenir impossible à maintenir. On peut être tenté de faire des groupes par location géographique, par type d'environnement, par type d'applicatif, mais il sera alors chargé et illisible ce qui entrainera des erreurs dans les playbook (oubli de certains serveurs).
• Soyez verbeux, utilisez le module debug pour afficher des informations. Pour les opérations sensibles utilisez le module pause permettant de valider l'exécution d'une opération, exemple: "Installation de Gluster 3.5.2-4 sur Debian Jessie, infra Paris. Enter pour valider ou CTRL+C pour annuler" (un cluster constitué de différentes versions de Gluster peut crasher, d'où l'intérêt de bien vérifier les versions).
• Documentez clairement, faites des README dans chaque rôle expliquant leur utilité.
• Faites des templates pour que vos collègues/successeurs aient des exemples de playbook utilisant vos rôles.

A l'année prochaine pour l'Ep3...

Ansible vault permet de stocker de manière chiffrée certaines informations, par exemple des variables utilisables dans vos playbooks.

Exemple d'information sensible lisible dans un playbook (sans vault):

---
- hosts: localhost
  remote_user: root
  tasks:
    - name: ensure 'utux' user exists
      user:
        name: utux
        append: yes
        groups: sudo
        shell: /bin/bash
        password: "{{ utux_passwd }}"
        generate_ssh_key: yes
        state: present
  vars:
    utux_passwd: "{{ 'secret' | password_hash('sha256') }}"

C'est lisible mais le mot de passe ('secret') se promène en clair, ce qui n'est pas top surtout si vous stockez votre projet sur un dépôt. La solution est d'utiliser ansible vault pour stocker dans un fichier sécurisé le mot de passe.

Création d'un vault:

$ mkdir -p group_vars/all
$ ansible-vault --ask-vault-pass create group_vars/all/vault

On y met une variable contenant notre mot de passe:

vault_utux_passwd: "{{ 'secret' | password_hash('sha256') }}"

Comme on peut le voir, notre fichier est bien chiffré:

$ cat group_vars/all/vault 
$ANSIBLE_VAULT;1.1;AES256
66623865616561613766343831613161343936636563373530643933323037333363363139666235
6135616635313332626637636466666236346365373037620a356436363133343161636239313133
36343539626564316431323135626533366462306631323761633330623231386434613734653934
3263383130386164620a663561363238303035336631326437643337646430653139643939363039
62663533626261373863323137316562643038613737333139303536623162633931

Et si on veut l'éditer:

$ ansible-vault --ask-vault-pass edit group_vars/all/vault

On adapte notre playbook:

---
- hosts: localhost
  remote_user: root
  tasks:
    - name: ensure 'utux' user exists
      user:
        name: utux
        append: yes
        groups: sudo
        shell: /bin/bash
        password: "{{ utux_passwd }}"
        generate_ssh_key: yes
        state: present
  vars:
    utux_passwd: "{{ vault_utux_passwd }}"

On exécute notre playbook:

ansible-playbook myuser.yml --ask-vault-pass

Ça marche, mais c'est un peu lourd car il faut taper le mot de passe vault à chaque exécution du playbook. Heureusement on peut le définir dans un fichier. On prendra soin de faire un gitignore pour ce fichier, voire même le placer dans un autre dossier:

$ echo "motdepassevault" > vault_passwd
$ echo "vault_passwd" >> .gitignore

On doit ensuite spécifier à Ansible où trouver ce fichier. Vous pouvez le définir au niveau du /etc/ansible/ansible.cfg ou dans le ansible.cfg local du projet (ce que je préfère faire, ainsi il est commité dans le dépôt et tout le monde a la bonne version):

# ansible.cfg
[defaults]
vault_password_file = vault_passwd

Vous devriez maintenant pouvoir exécuter votre playbook sans le --ask-vault-pass.

Après le semi-marathon Nantes 2017, j'ai décidé de m'attaquer à celui de Auray-Vannes. Malheureusement j'ai perdu l'enregistrement Strava, mon téléphone s'est éteint à cause de la pluie :( Du coup j'ai du attendre le classement officiel. Mes stats :

C'est 4min de mieux que le semi-marathon de Nantes (~2h00 en temps réel)! Petit aperçu du parcours tiré de la page Strava d'une des participantes:

Mon ressenti :

Énorme ambiance! La musique au départ, la foule qui nous acclame, les spectateurs dans le fossé sur quasiment tout le parcours, l'homme costumé en tortue qui lançait des bonbons dans son sillage, c'était quelque chose de fort!

Conscient qu'il y avait pas mal de dénivelé je visais un temps honorable de 2h, j'ai finalement fait 1h54 ce dont je suis plutôt satisfait! J'ai pu tenir un rythme constant du début à la fin et surtout je suis arrivé dans un état à peu près convenable alors que j'avais vraiment souffert lors du semi-marathon de Nantes 2017. J'attribue cet excellent résultat à plusieurs facteurs:

• L'entrainement, j'ai beaucoup bossé pour améliorer mon cardio et appris à gérer certains éléments (ne pas trop se couvrir, bien boire et manger même si on ne ressent pas le besoin).
• La météo, pas de soleil et un petit vent frais, ça facilite la gestion de son eau et ça aide à évacuer la chaleur du corps.
• Les 370km à vélo sur les côtes bretonnes qui m'ont habitué à gravir les cotes, je n'ai pas senti les dénivelés alors que cela semblait affecter beaucoup d'autres participants.
• Une bonne gestion de l'eau et la nourriture: je me suis forcé à boire et manger dès les premiers ravitaillements pour éviter "le mur" qui peut frapper si on gère mal même sur de petites distances.
• L'effet de nouveauté du parcours et sa non-redondance, ça motive.

Les derniers km se sont fait sous la pluie, à chaque fois qu'un de mes pieds frappait le sol, de l'eau jaillissait de chaque cm2 de mes vêtements et ma peau, j'étais vraiment trempé. L'arrivée a été marquée par le froid car une fois qu'on franchit la ligne d'arrivée et qu'on s'arrête, on commence immédiatement à se refroidir et la pluie + le vent deviennent alors mordants, il faut vite se couvrir ou rentrer se mettre à l'abri!

En conclusion le semi-marathon Auray-Vannes c'est génial, très bon parcours, excellente ambiance et bon défi! J'espère le refaire l'année prochaine!

Lorsque que Canonical a annoncé l'abandon de Unity, j'ai dit que c'était dommage car cette interface était intéressante et proposait une alternative à ce qui existe à côté. Mais à côté de cela j'ai cru comprendre qu'il était facile de refaire la même chose avec GNOME 3 et quelques extensions. Et en effet, c'est possible:

Il s'agit d'une capture d'écran réalisée sur openSUSE Tumbleweed en version GNOME bien entendu, avec les modifications suivantes:

• Extension Alternatetab (aperçu des fenêtres lors du ALT+TAB, de base on ne voit que l'icône).
• Extension Dash to dock (le dock, personnalisable).
• Extension Topicons Plus (systray).
• Gnome tweak (inclus dans GNOME) pour remettre les boutons de miniaturisation et maximisation sur les bordures de fenêtres.
• Nemo qui remplace Nautilus, un peu plus personalisable.
• (et le wallpaper mais vous l'avez déjà remarqué).

Il manque encore certains éléments mais je pense qu'il est possible d'y remédier:

• Un thème d'icônes et de fenêtres plus colorés.
• Un gestionnaire de bureaux virtuels visible directement permettant de switcher rapidement sans devoir entrer dans le menu activités.
• Des bordures de fenêtre moins épaisses.

L'orientation de Canonical vers GNOME permettra donc à Ubuntu de conserver son identité visuelle tout en s'épargnant énormément de développement redondant avec ce qui existe déjà (une habitude pour la firme). J'attends avec impatiente de voir ce que va donner Ubuntu 17.10.

Pour la rigolage, installons Trinity Desktop, continuation de KDE3, sur Debian :

Ça fonctionne plutôt bien, les paquets ont été correctement renommés pour ne pas entrer en conflit avec ceux de KDE5, par exemple konqueror-trinity donc la cohabitation se passe bien. Cette capture d'écran nous rappelle à quel point KDE3 était une usine à gaz et un foutoir, avec un sous-menu "Internet" déjà saturé lors de l'installation ou encore la présence d'éléments redondants: est-il nécessaire d'avoir des sous-menu Settings, System, Utilities, Trinity Control Center, System Menu ? Naviguer dans mes fichiers avec Konqueror, c'est pas la joie, Dolphin (arrivé avec KDE4) est bien meilleur.

Il est amusant de noter que MATE, continuation de GNOME2 est un projet vivant et fournit dans quasiment toutes les distributions alors que TDE est clairement mal aimé. Le projet n'est certes pas abandonné mais aucune distribution ne l'intègre, probablement parce que la transition de KDE3 à KDE4 fut assez logique et naturelle pour les utilisateurs, contrairement à GNOME3.

Passer de KDE3 à KDE4 c'est un peu comme échanger le bureau de Windows XP par celui de Windows 7, certes on peut râler parce que c'est un peu plus lourd, mais c'est aussi plus moderne et surtout on l'utilise quasiment de la même façon, nos habitudes ne sont pas brisées.

Je suis curieux de savoir s'il y a des utilisateurs de TDE... si c'est le cas manifestez-vous ;)