Le Blog Utux

Mark Shuttleworth annonce l'abandon d'Unity (LinuxFR).

Mouarf. Il y a quelques temps je me plaignais de ne pas avoir assez d'inspiration pour écrire, alors que maintenant je dirai presque qu'il y a trop de sujet sur lesquels j'ai envie de troller réagir.

Je trouve cela dommage car même s'il y a à mon sens pas mal de bugs, Unity est un excellent environnement qui arrive à proposer des choses intéressantes sans pour autant casser les habitudes des gens. Je trouve d'autant plus dommage de choisir GNOME comme futur environnement et je ne comprends pas ce choix, car ce qui plaît aux débutants et à un large public en général, c'est Linux Mint et son bureau Cinamon. Peut-être était-ce un choix par défaut étant donné qu'il existe déjà des variantes officielles pour tous les bureaux alternatifs (kubuntu, xubuntu...).

Au final je ne sais pas trop quoi penser, j'y vois un choix pragmatique, Ubuntu sacrifie son identité au profil de l'efficacité et cela ne présage rien de bon. J'espère que la distribution saura rebondir et nous convaincre que Canonical est toujours en bonne santé.

EDIT : Mir abandonné aussi... bon ça je m'y attendais, ce projet avait de moins en moins de sens et de plus en plus de retard.

Next INpact devient accessible sur abonnement et repense son modèle économique

Avant d'aller plus loin, je tiens à préciser que :

• Je suis déjà abonné à NextINpact, payant, parce que j'adore ce site et que j'ai réellement envie de les soutenir.
• NextINpact est un très bon site d'actu informatique.
• L'équipe de NextINpact a l'air assez au courant des enjeux de la publicité sur le web et de la difficulté à se financer, j'imagine que c'est une décision réfléchie.
• Je comprends que sur le web ce n'est pas facile de se financer. J'en parlais dans mon article La gratuité du web .

Mais quand mon abonnement sera terminé, je ne pense pas le renouveler.

Je suis contre ce passage au modèle payant, même si j'ai conscience que ma réaction est égoïste puisque je suis un lecteur passif qui se contente de consommer les articles sans réellement réaliser le coût de l'information. Mais je suis aussi un geek qui a grandit avec un web gratuit, communautaire, partageur, sorte d'utopie dans laquelle il n'y a pas que de la haine comme beaucoup le disent et où l'information circule librement sans frontières. Le problème est que depuis 10 ans on a d'un côté les réseaux sociaux qui cloisonnent ce web en rendant l'information hermétique, obligeant les utilisateurs à s'inscrire pour consulter les contenus, et de l'autre des sites qui ferment leurs portes à ceux qui refusent de sortir leur carte bleue.

Et c'est merdique de se dire que le web aujourd'hui se résume aux immenses décharges que sont les réseaux sociaux, aux contenus gratuits publicitaires putaclick et à des sites qui se renferment sur eux-mêmes pour survivre. Plus on avance et moins il y a de quoi être optimiste.

On va tous mourir et c'était mieux avant.

C'est un article écrit à chaud, donc court, qui fait suite à l'aperçu positif que j'ai posté il y a quelques jours.

Le début est plutôt cool, on se laisse guider dans le prologue qui pose les marques de la quête principale, on fait connaissance avec nos compagnons et nos ennemis... et puis on enchaîne sur la phase openworld chiante. Et le mot qui décrit le mieux cette chiantitude, c'est Inquisition. Je fais bien sûr référence à Dragon Age Inquisition, un autre jeu EA qui a aussi une quête principale grandiose, mais un openworld chiant, chronophage, vide, mort qui constitue la majeure partie du jeu. En fait c'est un MMO (pardon, meuporgue) non assumé.

Je pense détailler un peu plus mon avis dans un article beaucoup plus complet, mais je peux déjà vous dire que j'ai rage quit car j'en avais marre de me faire interrompre tous les 10m par un PNJ statique au regard vide qui me demande d'aller lui ramasser une connerie sur une autre planète. C'est simple en jouant à ce jeu j'ai l'impression de bosser, pas de jouer.

Du coup je ne vous recommande pas Mass Effect Andromeda. Si vous aimez les RPG, The Witcher 3 reste loin devant, à des années lumière même, c'est le cas de le dire.

Je suis un "huge fan" de la saga des Mass Effect, et j'attendais cette suite, Andromeda, avec impatience. Maintenant que le jeu est officiellement sorti, j'ai pu passer quelques heures dessus.

Et pour le moment, je suis plutôt content. Les cinématiques sont impressionnantes, les combats sont dynamiques, la technique est impeccable (temps de chargement plus que raisonnables), et on retrouve cette tendance à ramasser des quêtes à droite à gauche, caractéristique des Mass Effect et des RPG en général.

Alors oui ce n'est plus un scoop, les animations faciales sont un peu à la rue. Oxhorn parle de uncanny valley, c'est assez adéquat. Plus vulgairement on pourrait dire qu'on se croit parfois dans Toy Story, ou que les PNJ ont des paralysies faciales. Mais ça n'impacte pas la qualité du jeu. Le seul point négatif pour le moment ce sont les menus de l'interface avec lesquels je me bagarre un peu.

Étant encore au début du jeu, je ne peux vous recommander ou non de l'acheter, ni apposer mon "Seal of approval" pour le moment. Mais je suis plutôt content des premières heures passées sur ce jeu, et j'ai hâte de continuer.

Ansible est un logiciel d'automatisation et de déploiement, il permet de créer des listes de tâches qui peuvent ensuite être jouées sur un ou plusieurs serveurs.

Attention cet article n'est pas un tutoriel (pour cela je vous renvoie vers la documentation officielle), mon but est de faire un petit retour d'expérience et montrer un exemple de projet Ansible.

Pourquoi Ansible ?

Il existe de nombreuses solutions de ce type mais il y a selon moi deux points qui distinguent Ansible : il est simple à prendre en main (excellente documentation et syntaxe yaml humainement lisible) et il ne nécessite pas d'agent pour fonctionner. En effet sur vos cibles, vous avez uniquement besoin de Python et SSH, présents en standard sur quasiment toutes les distributions Linux. Ansible marche aussi avec Windows et FreeBSD.

Pourquoi pas un script Bash / Perl / Python ?

Ben oui, il y a beaucoup de gens qui se sont fait leur propre script afin de configurer rapidement leur serveur. Mais en vrai les scripts c'est pas idéal :

• C'est long à développer et ce n'est pas forcément votre métier.
• Plus le script est complexe moins il sera lisible.
• Le script doit être copié et exécuté à la main sur chaque serveur.
• Il se contente d'exécuter une série de commandes sans se soucier du résultat.
• Bon courage pour gérer un inventaire centralisé et des variables dynamiques.
• Même en documentant votre script, vous serez le seul à comprendre réellement comment il marche.
• Qui n'a jamais eu à déboguer un script obscur vieux de 10 ans ?

Ansible est beaucoup plus propre car depuis une unique machine vous gérez votre inventaire de serveurs et vos playbooks dans un même projet. Vous ne vous souciez que du résultat, vous ne demandez pas à ansible de faire un apt-get install curl, vous lui dites juste que le paquet curl doit être présent, à lui de faire en sorte de l'installer si besoin .Et c'est important non seulement car Ansible sait ce qu'il fait, mais il sait aussi le faire plusieurs fois, c'est ce qu'on appelle l'idempotence (sous réserve de ne pas faire n'importe quoi avec les playbooks, bien entendu). Enfin, il y a une énorme communauté d'utilisateurs et beaucoup de modules tiers, on trouve donc toujours des solutions aux problèmes

Exemple d'utilisation

Avertissement : Il y a plusieurs moyens de structurer un projet Ansible, consultez la page Best Practises. L'organisation que j'ai choisi n'engage que moi, vous êtes libre de faire autrement si ça colle mieux à vos besoins !

Voici un exemple de projet Ansible qui utilise un inventaire, des playbooks et des roles. Il sera utilisé pour configurer les nouveaux serveurs fraîchement installés. Objectifs :

• Installer une liste de paquets de base
• Configurer le /etc/hostname avec le nom du serveur
• Configurer la locale fr_FR.UTF-8.
• Configurer la timezone Europe/Paris.
• Installer Nginx et Php-fpm sur les serveurs web
• Tout en étant compatible Debian 8 & Ubuntu 16.04 (les paquets php n'ont pas le même nom !)

Arborescence du projet :

├── deploy-newserver.yml
├── group_vars
│   └── all
├── host_vars
│   ├── server01.example.org
│   └── web01.example.org
├── production.ini
└── roles
    ├── configure-newserver
    │   └── tasks
    │       └── main.yml
    │   └── templates
    │       └── hostname.j2
    ├── install-nginx
    |   └── tasks
    |       └── main.yml
    └── install-php-fpm
        └── tasks
            └── main.yml

Détail des fichiers :

---
# deploy-newserver.yml

- hosts: all
  roles:
    - configure-newserver

- hosts: webservers
  roles:
    - install-nginx
    - install-php-fpm

---
# group_vars/all
ansible_user: root

---
# host_vars/server01.example.org

ansible_host: 172.16.42.190

---
# host_vars/web01.example.org

ansible_host: 172.16.42.180

# production.ini
server01.example.org

[webservers]
web01.example.org

---
# roles/configure-newserver/tasks/main.yml

  - name: set hostname (volatile)
    hostname:
      name: '{{ inventory_hostname }}'

  - name: set hostname (permanent)
    template:
      src: hostname.j2
      dest: /etc/hostname
      force: yes

  - name: generate locales
    locale_gen:
      name: '{{ locale }}'
      state: present
    with_items:
      - en_EN.UTF-8
      - fr_FR.UTF-8

  - name: set default locale
    lineinfile:
      dest: /etc/default/locale
      regexp: '^LANG=.*$'
      line: 'LANG=fr_FR.UTF-8'
      create: yes
      state: present

  - name: set timezone
    file:
      src: /usr/share/zoneinfo/Europe/Paris
      dest: /etc/localtime
      force: yes
      state: link

  - name: common packages
    apt:
      name: "{{ item }}"
      state: present
    with_items:
      - apt-transport-https
      - bsd-mailx
      - ca-certificates
      - htop
      - manpages
      - net-tools
      - openssl
      - pciutils
      - postfix
      - ntp
      - ntpdate
      - rsync
      - tree
      - tzdata
      - ufw
      - unzip
      - vim

# roles/configure-newserver/templates/hostname.j2
{{ inventory_hostname }}

---
# roles/install-nginx/tasks/main.yml

  - name: install
    apt:
      name: nginx
      state: present

---
# roles/install-php-fpm/tasks/main.yml

  - name: php5-fpm if Debian <= 8
    apt:
      name: '{{ item }}'
      state: present
    with_items:
      - php5-fpm
      - php5-gd
    when:
      - ansible_distribution == "Debian" and ansible_distribution_major_version <= '8'

  - name: php7.0-fpm if Ubuntu => 16
    apt:
      name: '{{ item }}'
      state: present
    with_items:
      - php7.0-fpm
      - php7.0-xml
      - php7.0-gd
    when:
      - ansible_distribution == "Ubuntu" and ansible_distribution_major_version >= '16'

Lancer en dry-run (ne modifie rien) :

$ ansible-playbook -i production.ini deploy-newserver.yml --check

Lancer le déploiement :

$ ansible-playbook -i production.ini deploy-newserver.yml

Lancer le déploiement sur web01.example.org uniquement :

$ ansible-playbook -i production.ini deploy-newserver.yml --limit web01.example.org

Et voilà.

Ansible et moi

J'utilise régulièrement Ansible et maintient des playbooks pour des projets persos et pro, et j'en suis très satisfait. La documentation m'a permis d'être autonome et à l'aise assez vite et m'a même poussé à automatiser plus de choses que nécessaire, comme le déploiement de sites web alors que je pensais me limiter à la stack nginx / php-fpm / letsencrypt.

Même si je suis pleinement convaincu et satisfait par Ansible, je rencontre quand même certaines limitations. Par exemple l'inventaire n'est pas idéal quand on a beaucoup de serveurs et de groupes, ça peut rapidement devenir illisible. Il y a aussi certains modules tels que authorized_key pour lesquels j'aimerai plus de fonctionnalités, en l’occurrence pouvoir utiliser le paramètre 'exclusive' avec plusieurs clés.

Petits conseils en vrac

• Ansible évolue vite, utilisez une version récente, disponible dans les backports debian ou via pip.
• Le state: present est souvent implicite, vous n'avez donc pas besoin de le mettre, cependant c'est mieux de le faire, pour rendre le playbook plus évident à comprendre.
• Pensez à utiliser les variables, pour les URLs ou les numéros de version.
• Ne mettez pas de mot de passe ou de credential dans les playbooks, utilisez des variables passées au moment de l'exécution, ou dans un fichier que vous prendrez soin d'exclure si vous utilisez un repo public.
• Faites un dry-run pour tester vos playbooks, on ne sait jamais.
• Attention au module file et plus particulièrement aux permissions, surtout quand vous travaillez sur des fichiers existants (tels que le resolv.conf).
• La commande ansible hostname -m setup vous permet de récupérer tous les 'facts' (OS, version, ip...) d'une cible, ils peuvent être utilisés dans les playbooks.
• Testez vos playbooks jusqu'au bout : redémarrez le serveur pour vérifier que les modifications ne sont pas volatiles.
• Faites des choses propres et simples. Si vos besoins sont trop variés ou spécifiques, n'utilisez pas Ansible, ou limitez vous au minimum.
• La machine sur laquelle vous exécutez Ansible est critique, car en général vous aurez l'accès root without-password à tous vos serveurs, c'est donc un point d'entrée que vous devez sécuriser au maximum.

Conclusion

Si vous souhaitez unifier, accélérer et automatiser vos déploiements ou tout simplement vous initier au devops, Ansible est un outil que je recommande fortement, l'essayer c'est l'adopter.