Le Blog Utux

La nouvelle a été relayée avec plus ou moins de gravité selon les journalistes.

Comme je le disais en aout, on sentait la fin arriver depuis des mois au travers des divers bugs et services Microsoft qui ne fonctionnaient plus (Onedrive) et la désertion radicale des éditeurs tiers. J'ai même eu le Windows store indisponible un après midi entier (ma connexion fonctionnait bien).

Les mécréants n'ayant jamais utilisé un Windows Phone pourront nous pointer du doigt en faisant "Ah Ah!". En effet Microsoft débarque en grandes pompes en retard sur le marché des smartphones en déclarant que tous ses modèles seront suivi et auront les mises à jour de l'OS alors que ce ne fut pas le cas, et on se retrouve aujourd'hui avec l'abandon de la plateforme. Par contre un utilisateur de Windows Phone ne pourra qu'être attristé de cette nouvelle. Le matériel et l'OS étaient simples et efficaces, pas très chers et bien optimisés surtout si on le compare à Android qui demande aujourd'hui plus de ressources qu'un PC et dont les flagship dépassent les 1000€.

Pour la fin d'année, je vais devoir me résigner à acheter un smartphone Android. Le choix est quasiment déjà fait (Nokia 5), mais je compte garder le Lumia 950 encore quelques temps avant de m'en séparer.

Au début des années 2000 on pouvait trouver des hébergements web gratuit moyennement l'ajout de bandeaux publicitaires. Si vous êtes nostalgique de cette époque, remerciez Wikipedia qui a décidé de remettre ça en couvrant l'écran d'horribles publicités agressives et omniprésentes, mendiant de l'argent au visiteur:

Je ne lis même pas, ça m'agace. Vous allez me dire que j'exagère, Wikipedia c'est le savoir de l'humanité, libre et gratuit, et s'il venait à disparaître ce serait une catastrophe. C'est vrai, mais en quoi Wikipédia est plus légitime qu'un autre ? C'est aussi l'argument utilisé par la presse en ligne, désactive uBlock et bouffe notre pub ou crève, on a des salariés à faire vivre et on veut pas mourir. Pourrir l'expérience utilisateur avec de mauvaises pratiques publicitaires est impardonnable, il ne fait qu'agacer les visiteurs et inciter les autres à faire pareil.

Du coup y'en a marre, Wikipedia tu vas dans uBlock, ça t'apprendra le respect:

En espérant qu'il n'y en a pas d'autres...

Un petit billet hors sujet pour parler d'un phénomène que je trouve intriguant. Étant toujours en panne de voiture je redécouvre les joies du covoiturage avec blablacar, le site de partage que tout le monde connait et dont les tarifs ont beaucoup augmenté depuis ma première visite (2014), les joies du monopole, mais ce n'est pas le sujet.

Qu'est-ce que le covoiturage ? C'est avant tout un partage. Le conducteur partage sa voiture et les passagers partagent le coût du voyage. C'est un système entre particuliers, un arrangement plus rentable économiquement que le train (dont le coût du billet est exorbitant), plutôt convivial et écologique.

Il y a bien entendu des règles de base qui tiennent du savoir vivre: communiquer rapidement les bonnes informations à ses compagnons, être amical, faire preuve de souplesse dans vos horaires ou trajets si cela est possible, etc. Mais il y a une chose plutôt récente que j'ai remarqué, c'est que certaines personnes prennent cela beaucoup trop au sérieux. L'exemple que j'ai en tête c'est le conducteur qui vous confirme 10 fois par SMS que votre trajet est validé (vous le savez déjà), vous propose d'office de venir vous prendre là où ça vous arrange (alors que vous n'avez rien demandé), vous fait presque des courbettes ce qui en soit est plutôt gentil mais on a l'impression d'être dans une relation entreprise - client alors que ce n'est pas le cas, nous sommes deux particuliers qui s'arrangent pour partager un voyage.

Faut-il y voir une course aux étoiles ? Car oui nous sommes jugés à l'aide d'un système de notation qui peut d'abord paraître légitime vu qu'on voyage la plupart du temps avec des inconnus mais qui à mon avis s'étend un peu plus. On peut juger la conduite, la ponctualité, l'humeur mais mon exemple précédent semble indiquer qu'il y a d'autres critères. On juge le service rendu voire la personne elle-même et on créé une concurrence entre les usagers, une uberisation ou macronisation du service ce qui à mon avis va un peu trop loin.

Dans le cas où je serai amené à utiliser le service en tant que conducteur, ma philosophie serait la suivante: je conduits bien, je suis fiable, ponctuel, je vous donne toutes les infos nécessaires et vous tient au courant en cas de changement, mais je considère mes passagers comme mes égaux et non comme des clients. Je ne leur vend pas un service, c'est un échange de bons procédés entre particuliers.

En tant que passager, je n'ai jamais eu de mauvaise surprise. Si le chauffeur est à l'heure et conduit bien, je mets un 5/5. Si le courant ne passe pas bien ou si la conduite n'est pas idéale, je m'abstiens de noter et ce n'est arrivé qu'une seule fois.

Conclusion ? En fait non, ce n'est qu'une observation, je ne prétends pas avoir assez de statistiques ou même une qualification me permettant de livrer une explication à tout ceci car cela ferait appel à un mélange de sciences sociales et d'économie. Je livre simplement un constat et invite les gens à ne pas surjouer et rester eux-mêmes. Le covoiturage est à mon sens une des révolutions positives les plus importantes des 10 dernières années permises grâce à internet et on y fait beaucoup de rencontres sympathiques. Ne changez pas le système!

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.