Virtualisez pour plus de reproductibilité

Virtualisez pour plus de reproductibilité

Pour commencer

Vous avez enten­du par­ler de repro­duc­ti­bi­li­té. Vous vou­lez vous y mettre ? Vous vous dites que la vir­tua­li­sa­tion vous aide­rait à uti­li­ser tou­jours la même ver­sion d'un outil pré­cis. En savoir plus sur Docker vous aide­rait bien ? Cet article est donc pour vous. Je pro­fite de l'occasion pour par­ler aus­si de Sin­gu­la­ri­ty. Mais pour bien com­men­cer, on va expli­quer le concept des Machines Vir­tuelles.

Une Machine Virtuelle c'est quoi ?

Alors pour tous ceux qui se posent la ques­tion, un grille-pain en réa­li­té vir­tuelle n'est pas une Machine Vir­tuelle. Une Machine Vir­tuelle c'est la simu­la­tion d'un sys­tème infor­ma­tique qui repro­duit son uti­li­sa­tion réelle. Une notion voi­sine est l'ému­la­tion, outil bien connu des retro-gamers, qui va simu­ler un maté­riel pour repro­duire son uti­li­sa­tion.

Dans notre cas, c'est la vir­tua­li­sa­tion qui nous inté­resse. Le grand inté­rêt étant de pou­voir faire abs­trac­tion de toutes les carac­té­ris­tiques du sys­tème sur lequel on est et de simu­ler un autre sys­tème pour avoir un envi­ron­ne­ment trans­por­table et donc repro­duc­tible d'une machine à une autre.

Java fonc­tionne sur ce prin­cipe de Machine Vir­tuelle (et oui, JVM c'est pour Java Vir­tual Machine). Vir­tual Box est un des outils les plus connus per­met­tant de faire des Machines Vir­tuelles.

Les environnements virtuels

Alors oui, les Machines Vir­tuelles c'est bien joli, mais c'est un peu lourd. Du coup si au lieu de simu­ler le sys­tème dans son inté­gra­li­té, on ne simu­lait que ce dont on avait besoin, c'est-à-dire les appli­ca­tions. Bon quelques librai­ries ça peut être pra­tique aus­si, mais vous voyez l'idée.

Le grand inté­rêt d'utiliser des envi­ron­ne­ments vir­tuels c'est aus­si de pou­voir com­par­ti­men­ter et iso­ler ces envi­ron­ne­ments dans des conte­neurs. Et par exemple, de pou­voir ins­tal­ler plu­sieurs ver­sions de Python et plu­sieurs outils uti­li­sant plu­sieurs ver­sions sans trop s'embêter. Les adeptes de Python et de vir­tua­lenv se recon­naî­tront.

Docker c'est quoi ?

Docker c'est un outil qui s'appuie sur les fonc­tion­na­li­tés du sys­tème d'exploitation sous-jacent (le noyau Linux). Docker s'interface avec le noyau Linux et pro­pose plu­sieurs ins­tances de vir­tua­li­sa­tion iso­lées. Ces ins­tances sont appe­lées conte­neurs, et ils sont donc très légers (com­pa­rés aux Machines Vir­tuelles clas­siques). Une simple recherche sur votre moteur de recherche pré­fé­ré vous amène faci­le­ment sur des tuto­riaux si le work­shop de l'IFB et le site de Docker ne vous suf­fisent pas. Pour la petite his­toire, Docker a été créé par un fran­co-amé­ri­cain, et la des­si­na­trice Lau­rel y tra­vaille actuel­le­ment et elle fait entre autres choses de jolis auto­col­lants.

Les avantages et les inconvénients ?

Le grand avan­tage de Docker est sa sim­pli­ci­té de mise en place et d'utilisation. Les conte­neurs donnent accès à des envi­ron­ne­ments iso­lés et contrô­lés. Docker-Hub est le site de dépôt de Docker, conçu pour faci­li­ter la recherche et le par­tage de conte­neurs Docker.

Créer son propre conte­neur Docker est aus­si simple. Il suf­fit de le construire à par­tir d'un fichier de confi­gu­ra­tion Docker­file qui contient toutes les com­mandes néces­saires à sa construc­tion. Si votre Docker­file est ver­sion­né sur GitHub, une construc­tion auto­ma­tique du conte­neur peut être réa­li­sée sur les ser­veurs de Docker à chaque push. Ce qui per­met une véri­fi­ca­tion sup­plé­men­taire du bon fonc­tion­ne­ment de votre conte­neur.

Le gros incon­vé­nient de Docker est qu'il fonc­tionne en root sur votre machine. Ce qui signi­fie qu'il a tous les droits. Ce qui peut poten­tiel­le­ment être un pro­blème de sécu­ri­té, et fait que cet outil n'est sou­vent pas dis­po­nible sur les clus­ters de cal­culs.

Avant d'utiliser un conte­neur, soyez sûr de sa pro­ve­nance ;-).

Quelles sont les initiatives en Bioinformatique ?

Du coup, main­te­nant vous vous dites, eh mais ça m'intéresse ça jus­te­ment, j'aimerais bien avoir un conte­neur avec BWA pour ali­gner mes séquences, et il m'en fau­drait aus­si un avec GATK pour conti­nuer mes ana­lyses.

Bien évi­dem­ment ç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 contai­ners, pas de sou­cis, Ikea est là.

Euh non, c'est quand même plus simple à mon­ter ;-). Comme expli­qué plus haut, vous pou­vez cher­cher sur Docker-Hub. Mais il n'y a pas que ça, Bio­Con­tai­ners et Bio­Sha­dock sont des ini­tia­tives qui four­nissent des conte­neurs d'outils bio­in­for­ma­tiques.

Et Singularity dans tout ça ?

Gros­so modo c'est pareil que Docker sans le sou­cis d'utilisateur root. Et c'est aus­si un poil plus com­pli­qué pour rapi­de­ment exé­cu­ter un conte­neur. Mais le pro­jet est récent, et facile d'utilisation. Leur pla­te­forme Sin­gu­la­ri­ty-Hub a qua­si­ment les mêmes fonc­tion­na­li­tés que Docker-Hub. Bref, c'est à sur­veiller.

On peut avoir un exemple ?

J'ai un fichier .bam sur mon ordi, il me paraît plu­tôt petit, et je me demande donc ce qu'il s'est pas­sé avec ce fichier. Je vou­drais notam­ment véri­fier quel génome de réfé­rence a été uti­li­sé lors du trai­te­ment de ce fichier. Un simple samtools view -H monFichier.bam aurait nor­ma­le­ment suf­fit à me don­ner le hea­der qui répon­dra à cette ques­tion. Mais j'ai réins­tal­lé mon ordi il y a plu­sieurs mois, et n'ai pas vrai­ment eu besoin de samtools depuis, et là c'est le drame… Bon, je pour­rais l'installer, c'est facile, mais je pour­rais pas faire d'exemple pour cet article… Et puis, si je ne l'ai pas déjà ré-ins­tal­lé, c'est vrai­sem­bla­ble­ment que j'en ai pas super besoin, on va donc uti­li­ser Docker.
Le début de la com­mande change un petit peu, et je vais l'expliquer en détail

Ce qui nous donne tout sim­ple­ment :

Et voi­là, en deux rela­ti­ve­ment simples com­mandes, on a pu uti­li­ser deux ver­sions d'un même pro­gramme en moins de 5 min.

En regar­dant plus en détail le fichier de confi­gu­ra­tion du conte­neur Docker uti­li­sé (cf BioContainers/samtools/1.3.1/Dockerfile):

On peut voir que ce conte­neur est basé sur un autre conte­neur et que samtools est ici ins­tal­lé en uti­li­sant conda . En regar­dant cet autre conte­neur source :

On se rend compte qu'il contient la plu­part des outils pour com­pi­ler et ins­tal­ler des outils. J'ai donc envie d'utiliser une autre image plus légere que je vais réa­li­ser moi même :

J'ai choi­si une approche dif­fé­rente, me base sur debian:8.6 et n'installe que le strict néces­saire pour com­pi­ler samtools avec make. Mon conte­neur est donc plus léger que celui de bio­con­tai­ners. Je n'ai construit ici qu'un seul simple conte­neur, et n'utilise pas un conte­neur ser­vant de base à plus de 50 conte­neurs dif­fé­rents. L'approche de bio­con­tai­ners est expli­cable par le nombre de conte­neurs à gérer, et j'aurai pro­ba­ble­ment la même approche pour un pro­jet de grande ampleur.

Quelque soit le conte­neur que vous uti­li­sez, l'important est que vous puis­siez être sur de tou­jours uti­li­ser le même, et de le faire uti­li­ser à vos col­la­bo­ra­teurs ou vos uti­li­sa­teurs. C'est l'essentiel de la repro­duc­ti­bi­li­té.

Conflits d'intérêts

Aucun.

Remerciements

Je remer­cie Yoann M. pour sa moti­va­tion concer­nant cet article, ain­si que Norore, M4rsu et Lroy bien-aimés relec­teurs pour leurs avis et dis­cus­sions.