Virtualisez pour plus de reproductibilité

Pour commencer

Vous avez entendu parler de reproductibilité. Vous voulez vous y mettre ? Vous vous dites que la virtualisation vous aiderait à utiliser toujours la même version d'un outil précis. En savoir plus sur Docker vous aiderait bien ? Cet article est donc pour vous. Je profite de l'occasion pour parler aussi de Singularity. Mais pour bien commencer, on va expliquer le concept des Machines Virtuelles.

Une Machine Virtuelle c'est quoi ?

Alors pour tous ceux qui se posent la question, un grille-pain en réalité virtuelle n'est pas une Machine Virtuelle. Une Machine Virtuelle c'est la simulation d'un système informatique qui reproduit son utilisation réelle. Une notion voisine est l'émulation, outil bien connu des retro-gamers, qui va simuler un matériel pour reproduire son utilisation.

Dans notre cas, c'est la virtualisation qui nous intéresse. Le grand intérêt étant de pouvoir faire abstraction de toutes les caractéristiques du système sur lequel on est et de simuler un autre système pour avoir un environnement transportable et donc reproductible d'une machine à une autre.

Java fonctionne sur ce principe de Machine Virtuelle (et oui, JVM c'est pour Java Virtual Machine). Virtual Box est un des outils les plus connus permettant de faire des Machines Virtuelles.

Les environnements virtuels

Alors oui, les Machines Virtuelles c'est bien joli, mais c'est un peu lourd. Du coup si au lieu de simuler le système dans son intégralité, on ne simulait que ce dont on avait besoin, c'est-à-dire les applications. Bon quelques librairies ça peut être pratique aussi, mais vous voyez l'idée.

Le grand intérêt d'utiliser des environnements virtuels c'est aussi de pouvoir compartimenter et isoler ces environnements dans des conteneurs. Et par exemple, de pouvoir installer plusieurs versions de Python et plusieurs outils utilisant plusieurs versions sans trop s'embêter. Les adeptes de Python et de virtualenv se reconnaîtront.

Docker c'est quoi ?

Docker c'est un outil qui s'appuie sur les fonctionnalités du système d'exploitation sous-jacent (le noyau Linux). Docker s'interface avec le noyau Linux et propose plusieurs instances de virtualisation isolées. Ces instances sont appelées conteneurs, et ils sont donc très légers (comparés aux Machines Virtuelles classiques). Une simple recherche sur votre moteur de recherche préféré vous amène facilement sur des tutoriaux si le workshop de l'IFB et le site de Docker ne vous suffisent pas. Pour la petite histoire, Docker a été créé par un franco-américain, et la dessinatrice Laurel y travaille actuellement et elle fait entre autres choses de jolis autocollants.

Les avantages et les inconvénients ?

Le grand avantage de Docker est sa simplicité de mise en place et d'utilisation. Les conteneurs donnent accès à des environnements isolés et contrôlés. Docker-Hub est le site de dépôt de Docker, conçu pour faciliter la recherche et le partage de conteneurs Docker.

Créer son propre conteneur Docker est aussi simple. Il suffit de le construire à partir d'un fichier de configuration Dockerfile qui contient toutes les commandes nécessaires à sa construction. Si votre Dockerfile est versionné sur GitHub, une construction automatique du conteneur peut être réalisée sur les serveurs de Docker à chaque push. Ce qui permet une vérification supplémentaire du bon fonctionnement de votre conteneur.

Le gros inconvénient de Docker est qu'il fonctionne en root sur votre machine. Ce qui signifie qu'il a tous les droits. Ce qui peut potentiellement être un problème de sécurité, et fait que cet outil n'est souvent pas disponible sur les clusters de calculs.

Avant d'utiliser un conteneur, soyez sûr de sa provenance ;-).

Quelles sont les initiatives en Bioinformatique ?

Du coup, maintenant vous vous dites, eh mais ça m'intéresse ça justement, j'aimerais bien avoir un conteneur avec BWA pour aligner mes séquences, et il m'en faudrait aussi un avec GATK pour continuer mes analyses.

Bien évidemment ça marche avec n'importe quoi d'autre. Mais si vous n'avez pas envie de vous prendre la tête à créer vos propres containers, pas de soucis, Ikea est là.

Euh non, c'est quand même plus simple à monter ;-). Comme expliqué plus haut, vous pouvez chercher sur Docker-Hub. Mais il n'y a pas que ça, BioContainers et BioShadock sont des initiatives qui fournissent des conteneurs d'outils bioinformatiques.

Et Singularity dans tout ça ?

Grosso modo c'est pareil que Docker sans le soucis d'utilisateur root. Et c'est aussi un poil plus compliqué pour rapidement exécuter un conteneur. Mais le projet est récent, et facile d'utilisation. Leur plateforme Singularity-Hub a quasiment les mêmes fonctionnalités que Docker-Hub. Bref, c'est à surveiller.

On peut avoir un exemple ?

J'ai un fichier .bam sur mon ordi, il me paraît plutôt petit, et je me demande donc ce qu'il s'est passé avec ce fichier. Je voudrais notamment vérifier quel génome de référence a été utilisé lors du traitement de ce fichier. Un simple samtools view -H monFichier.bam aurait normalement suffit à me donner le header qui répondra à cette question. Mais j'ai réinstallé mon ordi il y a plusieurs mois, et n'ai pas vraiment eu besoin de samtools depuis, et là c'est le drame... Bon, je pourrais l'installer, c'est facile, mais je pourrais pas faire d'exemple pour cet article... Et puis, si je ne l'ai pas déjà ré-installé, c'est vraisemblablement que j'en ai pas super besoin, on va donc utiliser Docker.
Le début de la commande change un petit peu, et je vais l'expliquer en détail

Ce qui nous donne tout simplement:

Et voilà, en deux relativement simples commandes, on a pu utiliser deux versions d'un même programme en moins de 5 min.

En regardant plus en détail le fichier de configuration du conteneur Docker utilisé (cf BioContainers/samtools/1.3.1/Dockerfile):

On peut voir que ce conteneur est basé sur un autre conteneur et que samtools est ici installé en utilisant conda. En regardant cet autre conteneur source:

On se rend compte qu'il contient la plupart des outils pour compiler et installer des outils. J'ai donc envie d'utiliser une autre image plus légere que je vais réaliser moi même:

J'ai choisi une approche différente, me base sur debian:8.6 et n'installe que le strict nécessaire pour compiler samtools avec make. Mon conteneur est donc plus léger que celui de biocontainers. Je n'ai construit ici qu'un seul simple conteneur, et n'utilise pas un conteneur servant de base à plus de 50 conteneurs différents. L'approche de biocontainers est explicable par le nombre de conteneurs à gérer, et j'aurai probablement la même approche pour un projet de grande ampleur.

Quelque soit le conteneur que vous utilisez, l'important est que vous puissiez être sur de toujours utiliser le même, et de le faire utiliser à vos collaborateurs ou vos utilisateurs. C'est l'essentiel de la reproductibilité.

Conflits d'intérêts

Aucun.

Remerciements

Je remercie Yoann M. pour sa motivation concernant cet article, ainsi que Norore, M4rsu et Lroy bien-aimés relecteurs pour leurs avis et discussions.