Le Blog Utux

Docker-compose est un outil permettant d'utiliser docker à l'aide d'un simple fichier .yml, facilitant ainsi grandement la vie et les interactions entre les containers d'un même service. Mais il n'est pas exempt de bugs ou de défauts de conception.

Le défaut dont je vais parler concerne le nommage des containers. Prenons par exemple deux projets docker : projet1 et projet2 avec l'arborescence suivante :

.
├── projet1
│   └── src
│       └── docker-compose.yml
└── projet2
    └── src
        └── docker-compose.yml

Nos docker-compose.yml sont identiques et commandent le lancement d'un simple container nginx :

# projet1/src/docker-compose.yml
version: '3'
services:

  nginx:
    image:
        nginx:latest

Et :

# projet2/src/docker-compose.yml
version: '3'
services:

  nginx:
    image:
        nginx:latest

Voyons ce qui arrive lorsque je démarre mon projet1 :

utux@docker:~/projet1/src$ docker-compose up -d
Creating src_nginx_1 ... 
Creating src_nginx_1 ... done

On voit que notre container a été nommé src_nginx_1 suivant la logique suivante : $dossier_$service_$numero. Très bien. Démarrons maintenant le projet2 :

utux@docker:~/projet2/src$ docker-compose up -d
src_nginx_1 is up-to-date

docker-compose dit que le container existe déjà alors que non ! En fait il applique le même raisonnement et veut nommer le container src_nginx_1 aussi alors qu'il existe déjà ! C'est un défaut de conception et c'est problématique car en cas de modification sur l'un des projets, docker-compose va recréer les containers, et donc écraser ceux de l'autre...

Pour palier à ce problème, plusieurs solutions sont possibles :

• Nommer différemment votre dossier de travail. Ce n'est pas toujours possible car on peut avoir un environnement de dev et un environnement de prod avec les mêmes chemins.
• Utiliser l'attribut container_name mais c'est un peu fastidieux car il faut le faire sur tous les services du docker-compose.yml
• Utiliser la variable d'environnement COMPOSE_PROJECT_NAME. Malheureusement on ne peut pas la définir dans le docker-compose.yml malgré les demandes répétées des utilisateurs (ici et là) il faut la mettre dans un fichier .env dans votre projet.

Exemple d'utilisation du COMPOSE_PROJECT_NAME :

.
├── projet1
│   └── src
│       ├── docker-compose.yml
│       └── .env
└── projet2
    └── src
        ├── docker-compose.yml
        └── .env

Avec nos fichiers .env :

# projet1/src/.env
COMPOSE_PROJECT_NAME=projet1

Et :

# projet2/src/.env
COMPOSE_PROJECT_NAME=projet2

Démarrons maintenant notre projet1 puis notre projet2 :

utux@docker:~$ cd projet1/src/
utux@docker:~/projet1/src$ docker-compose up -d
Creating network "projet1_default" with the default driver
Creating projet1_nginx_1 ... 
Creating projet1_nginx_1 ... done
utux@docker:~/projet1/src$ cd ../../projet2/src/
utux@docker:~/projet2/src$ docker-compose up -d
Creating network "projet2_default" with the default driver
Creating projet2_nginx_1 ... 
Creating projet2_nginx_1 ... done

Cette fois les deux projets cohabitent bien et ne se marchent plus sur les pieds. La preuve :

utux@docker:~/projet2/src$ docker ps
CONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS              PORTS                    NAMES
eacabeb7e961        nginx:latest                     "nginx -g 'daemon ..."   4 seconds ago       Up 2 seconds        80/tcp                   projet2_nginx_1
9477b31d2035        nginx:latest                     "nginx -g 'daemon ..."   16 seconds ago      Up 14 seconds       80/tcp                   projet1_nginx_1

En conclusion il ne faut pas avoir une confiance aveugle en docker-compose, qui est un outil bien pratique mais manifestement sujet à des défauts de conception. Imaginez ce genre de confusion de nommage, voire d'écrasement de containers en production. Utilisez COMPOSE_PROJECT_NAME et testez vos projets en pré-production avant de déployer sur la prod.

L'informatique, comme tous les métiers, demande un savoir-faire, celui-ci vient avec l'expérience et la pratique. Mais s'il y a un autre point qui est important et souvent négligé, c'est de savoir refaire. Je vais expliquer.

Imaginez-vous administrateur système dans une entreprise, on vous charge d'installer un serveur web pour afficher une simple page html. Vous allez alors installer Debian + Apache puis placer le fichier html à la racine, rien de difficile jusque là.

Imaginez ensuite qu'au bout de 2 mois ce fichier html soit remplacé par un fichier php un peu plus avancé, vous allez alors installer libapache2-mod-php5 là encore c'est facile. Par la suite le fichier évolue encore et vous oblige à installer des modules, par exemple php5-gd et php5-curl.

Puis le serveur vit sa vie et au bout de 2 ans on vous demande d'en mettre en place un deuxième avec exactement le même rôle. Et là ça se complique car 2 ans c'est long et vous avez probablement oublié tout ce que vous et vos collègues avez fait pour configurer ce serveur au fur et à mesure. S'il est facile d'identifier que apache2 et php5 sont présents, en revanche les modules sont beaucoup moins évidents, surtout si vous avez utilisé des gestionnaires tiers tels que pecl, cpan, pip.

L'une des grandes problématiques est donc de trouver un moyen pour garder une trace et refaire rapidement toutes les étapes qui ont accompagné la vie du serveur. Alors bien sûr le grand classique est d'utiliser un wiki, mais qui vous garanti que ce qu'y s'y trouve représente bien ce qui est en production ? Personne n'est à l'abri d'une modification "urgente" en prod non rapportée sur le wiki.

Une solution que l'on retrouve souvent et qui est appliquée dans Ansible, Docker et NixOS, c'est d'éliminer toutes les manipulations sur la prod. On y touche plus, à la place on travaille sur un fichier de recette, que l'on va ensuite deployer et jouer. Sur Ansible ce sont les playbook, sur docker les Dockerfile, et sur NixOS le fichier configuration.nix.

Cela parait beaucoup plus propre et ça l'est, c'est une rigueur pas forcément naturelle qui paye sur le long terme. Néanmoins ce n'est pas toujours évident, une manipulation rapide à faire sur un serveur peut se transformer en plusieurs minutes voire heures de devops dans Ansible. Let's Encrypt est un exemple, son automatisation n'est pas simple car vous allez devoir gérer deux cas différents selon la présence ou non d'un certificat. En effet certbot peut soit utiliser le mode standalone et donc couper Nginx (car nécessité du port 80) ou alors utiliser le mode webroot et justement passer par Nginx + vhost de votre site, or ce dernier a justement besoin du certificat pour démarrer. Et quid du cas de Docker où vous devez créer un nouveau container et le relier à l'existant juste pour renouveler vos certificats.

En conclusion le boulot de sysadmin, développeur ou devops n'est pas seulement de faire ou réparer les choses mais également de prévoir l'avenir, s'imposer une rigueur même si elle parait contre-productive sur le moment. J'aurai probablement l'occasion de parler de plus en détail de Docker et de NixOS dans de prochains articles, restez branchés.

Après avoir terminé Mass Effect Andromeda et débuté une seconde partie en difficulté plus élevée (Insanity), je livre mon avis sur le jeu. Afin de rendre tout cela plus lisible, je ne vais pas écrire un gros pâté mais parler des points positifs et négatifs qui ont retenu mon attention.

+ Positif

Les combats (environnements). Les environnements ouverts, le système de sauts et de dash font que l'on exploite bien les 3 dimensions (on peut se percher en hauteur d'un bâtiment par exemple) et que l'ensemble est plutôt nerveux. C'est très intéressant.

Les combats (mécaniques). Le joueur n'est plus limité à un système de classe, il peut investir des points dans tous les arbres de compétence (Combat, Biotic, Tech) et les cooldown sont de nouveau individuels comme dans Mass Effect 1. En contrepartie, vous ne pouvez en utiliser que 3 à la fois, mais un système de favoris vous permet de les changer à la volée. Le système de classes (Soldier, Adept...) revient sous forme de profils disponibles en fonction des points investis.

Les compagnons. C'est un des points forts du jeu, les compagnons sont bien écrits, bien doublés en anglais (mention spéciale pour Jaal), et beaucoup de dialogues ont été ajoutés afin de les rendre vivants et profonds. On retrouve l'esprit BioWare.

Les musiques. Elles sont correctes et plutôt bien appropriées à l'ambiance du jeu.

L'histoire. Le scenario ne mérite pas un oscar, il est plutôt basique pour de la SF, mais quand on voit le truc hyper compliqué de Mass Effect 3 et sa fin de merde on se dit qu'on revient de loin et que finalement ce n'est pas si mal. Poutrer des méchants qui veulent tuer les gentils, ça me suffit et je n'en demande pas plus.

La technique. Contrairement à ce qu'on peut lire un peu partout, le jeu n'est pas si bugué, les temps de chargement sont corrects, il faut bien le dire. Pour le reste, des patchs sont déjà disponibles.

Le craft. Peu évident à appréhender à cause de l'ergonomie désastreuse des menus il est finalement assez efficace. Lors de la création d'un objet on peut utiliser des "augmentations" qui vont donner des bonus (santé, cooldowns...).

Lore friendly. Rien à lui reprocher sur ce point, c'est fidèle à Mass Effect.

- Négatif

La VF. Oh mon dieu, je ne sais pas ce qui s'est passé pour la VF, mais c'est une catastrophe, vraiment. Passez le jeu en VOSTFR a plus vite.

L'openworld. Il est clairement moins pénible que dans Dragon Age Inquisition (plus besoin de faire des détours de 20km pour aller d'un point A à un point B), mais on passe beaucoup de temps à faire de la randonnée (à pied ou en voiture). Pas de cycle jour/nuit ni météo.

Les quêtes fedex. Bonjour Ryder, blablablablabla, pourriez-vous me ramener un objet qui est à l'autre bout de la map ?

Les allers-retours au Tempest. Pour lire un e-mail, changer de planète, parler à un compagnon, avancer sur une quête débile, il faut retourner dans le Tempest (le vaisseau du joueur). Et donc se taper la cinématique du décollage systématique, c'est pénible.

Le manque de vie des PNJ. Les PNJ sont statiques, peu nombreux, calmes, les villes sont mortes. On est à des années-lumière d'un The Witcher 3 et de Novigrad, cité médiévale vivante et horrifiante, avec tavernes remplies d'alcooliques, de pugilistes et de joueurs de Gwynt.

La durée de vie. La quête principale est vraiment très courte, je pense qu'elle ne dépasse pas les 5-6h. Et si on ajoute tout l'openworld chiant et les sidequest, on atteint ~50h. C'est une durée suffisante mais j'aurais aimé moins de farm et plus de quête principale.

La navigation dans la galaxie. Il y a de nombreux systèmes à explorer, mais la plupart sont vides et on y trouve rien à part quelques ressources (pas de mini-quêtes éclair comme dans Mass Effect 2). De plus il y a beaucoup trop d'animations lors des déplacements du Tempest.

Les menus. Ils sont mal conçus et peu pratiques. Par exemple quand je suis dans l'inventaire et que je passe en revue mes armes, je n'ai aucun moyen de comparer les stats avec mon équipement actuel. Idem dans les menus d'achats.

Les graphismes. Le jeu est sorti 5 ans après Mass Effect 3 et utilise le Frostbite Engine 3, pourtant on a l'impression que rien n'a évolué. Les personnages ont toujours des cheveux en plastique, peu de polygones, les asari ont toutes le même visage, certaines cinématiques font cheap (un hôpital qui ressemble à un entrepôt), c'est clairement raté.

L'éditeur de personnage. C'est une catastrophe, possibilités très limitées, très peu de coupes de cheveux disponibles, pas d'édition des sourcils... du coup on s'en tient aux 1-2 preset potables.

Le look par défaut Scott & Sarah Ryder. Ils ressemblent à tout sauf à des humains, les traits sont exagérés et les animations robotiques. On est bien loin de John et Jane Shepard qui avaient de la gueule et un certain swag tout en conservant un look endurci.

Résumé

Sorti 2 ans après The Witcher 3 qui a placé la barre très haut et reste selon moi le meilleur RPG des cinq dernières années (et c'est probablement parti pour la décennie jusqu'à Cyberpunk 2077), Mass Effect Andromeda peine à convaincre et même si ses mécaniques de combat sont excellentes (et je dirai presque que le jeu vaut le coup rien que pour ça), il souffre de la formule classique des RPG EA, s'embourbe dans un openworld de meuporgue chiant et chronophage.

Au final est-ce que je vous recommande Mass Effect Andromeda ? Et bien c'est difficile à dire. Globalement oui car j'ai quand même passé un bon moment et de manière générale je vous encourage à vous faire votre propre avis. Néanmoins soyez prévenus que l'accroche n'est pas facile et que si vous n'avez que très peu de temps pour jouer, vous ne le finirez pas.

Un problème existant depuis des années m'a toujours gêné sous KDE : lors de l'ouverture d'un partage samba dans dolphin, l'utilisateur est invité à saisir un identifiant et mot de passe, jusqu'ici tout va bien, mais si je décide d'ouvrir un des fichiers, par exemple une vidéo avec VLC, ce dernier ne parvient pas à y accéder car l'information d'authentification n'est pas conservée.

Ce problème n'est pas présent sur GNOME / MATE / Xfce / Lxde puisque l'authentification se fait à travers le composant gvfs sur lequel les logiciels vont ensuite se baser, c'est à dire qu'une fois le partage samba monté, il est ouvert et accessible comme n'importe quel répertoire local. Sous KDE il semble que ce rôle soit confié à Kio mais cela ne fonctionne visiblement pas et ce depuis très longtemps (j'ai constaté cela à l'époque de Fedora 17). Notez que Windows implémente la même chose puisqu'une fois connecté à un partage, les applications peuvent y accéder sans devoir s'authentifier systématiquement.

Autre point : avec gvfs l'ouverture d'un fichier sur le réseau semble se faire en temps réel alors qu'avec kio une copie en répertoire temporaire local est effectuée ce qui ajoute une latence à l'ouverture.

Ce billet est une question ouverte, si vous êtes utilisateur de KDE et que vous avez résolu ces soucis, je suis preneur de vos solutions par curiosité.

Les remakes, c'est un gros sujet. Certes il est délicat voire malvenu de vouloir "refaire" une chose faisant partie de la pop culture, mais il y a parfois de bonnes surprises. Par exemple j'aime bien Robocop 2014 qui est correct et "met à niveau" l'histoire au 21e siècle, même si l'original reste toujours la référence. Si vous voulez en savoir plus sur les remakes, Le Fossoyeur de Films s'est emparé du sujet et en présente des bons mais aussi des mauvais, c'est très intéressant.

Ghostbusters 2016 est un film qui s'est pris un shit storm avant sa sortie à cause de sa bande annonce très impopulaire sur Youtube (80% de pouces rouges) ainsi que des commentaires très drôles.

En ce qui me concerne je trouve que c'est une bonne chose d'oser prendre des risques dans le cinéma, comme l'a fait Rogue One, ou encore Batman V Superman, deux films qui ont pour point commun un mauvais scenario mais une prise de risque dans la narration et l’esthétique qui méritent le respect. Là on parle de Ghostbusters, une franchise mythique mais dont les films ne se sont jamais vraiment pris au sérieux, alternant entre la science fiction et la comédie, un nouveau film avec casting féminin et humour me paraissent donc d'autant plus appropriés.

Et puis j'ai regardé Ghostbusters 2016, pendant 1h, temps qu'il m'a fallu avant de craquer psychologiquement et de tout arrêter. Je n'accroche simplement pas à l'humour, c'est difficile d'expliquer ce qui ne va pas, mais le ton est beaucoup trop parodique, j'ai presque l'impression de regarder Austin Powers. En plus de ne pas accrocher au look et au surjeu des personnages, j'ai trouvé les gags avec Chris Hemsworth (Thor) gênants et ratés. Je pense que l'idée était d'en faire "une cruche" en version homme, mais tout est artificiel et exagéré, ça ne fonctionne pas. Je pense aussi que le film s'encombre de scènes inutiles, comme la découverte du logo sur un mur ou encore l'utilisation de la première version du proton pack sur roulettes : on s'en fout, on raconte l'histoire de chasseurs de fantômes, donnez-leur juste plein de gadgets cool, n'essayez pas de tout justifier !

En plus de tout cela, je n'ai pas l'impression que le film soit utile, il ne fait que raconter la même histoire avec un nouveau casting, mais rien n'est surprenant, tout est prévisible, on ne fait que redécouvrir tout ce que l'on connaissait déjà donc au final... à quoi bon ? Pourquoi vouloir redémarrer Ghostbusters si c'est pour faire la même chose ?

Au final Ghostbusters 2016 tient plus de la mauvaise parodie que du remake, et si vous voulez un vrai Ghostbusters 3 je vous conseille l'excellent jeu Ghostbusters sorti en 2009 qui est pour le coup un meilleur "remake" (bien que se déroulant à la suite des films) en plus d'avoir des mécaniques de jeu intéressantes et de nombreux puzzles à résoudre pour pouvoir avancer et en découdre avec les fantômes. Prévoyez une manette.