Galaxy4Bioinformatics Développement et intégration d application sous Galaxy

Galaxy4Bioinformatics Développement et intégration d application sous Galaxy Christophe Caron Alexis Dereeper Mars 3, 2015 14pm 17pm ARCHITECTURE GALAXY Installation et paramétrage d une instance

3 jours! Mardi 3 / 14-17H30 : Architecture A. Dereeper, C. Caron, V. Loux Mercredi 4 / 9-18H00 : Intégration des outils A. Lermine, G. Le Corguillé, JF. Dufayard, A. Dereeper, G. Andres, L. Guéguen Jeudi 5 / 9-16H00 : API & ToolShed G. Le Corguillé, M. Monsoor, O. Inizan, A. Lermine, F. Mareuil, O. Doppelt-Azeroual O. Inizan, M. Monsoor, JF. Dufayard, L. Guéguen, V. Loux

4 Mars GT Galaxy Tour de table Galaxy : success story? Architecture Installation standard Architecture plateforme

G4B V2 http://www.france-bioinformatique.fr/?q=fr/groupes-de-travail/galaxy gtgalaxy@groupes.france-bioinformatique.fr

Ecole AVIESAN 01/2013 Who! Contribute Share GT CORE IFB Platform x 6 MetaboHUB x 1 Meeting Teach And Open! Institut Pasteur (e.g. : training) GenOuest Rennes (ToolShed) Visio La Chapelle sur Erdre, Mars 2015 5

What! Animation Training Development La Chapelle sur Erdre, Mars 2015 6

RESULTS La Chapelle sur Erdre, Mars 2015 7

Animation National JOBIM 2013 Galaxy Day 2013 & 2014 x 200 International Galaxy Community Conference Oslo 2013 :» Poster GT» Institut Curie(Galaxy integration into an external information system), URGI (DevOps), ABiMS(Workflow4Metabolomics) Baltimore 2014» Institut Curie (GalaxyDx : A Web-server dedicated to cancer diagnostic data analysis), URGI(Puppet), ABiMS (Tools Integration) Galaxy Team contact : regular meeting ToolShed Extension, etc. Automatic Galaxy environment construction Galaxy-MODAL Deployment of a new Galaxy instance on IFB-cloud Rapsosnp: A workflow for the Rapsodyn project La Chapelle sur Erdre, Mars 2015 8

Federate platform skills Tools Integration : best practices API Tuning Wiki etc. Communities (Bio)-informatician Biologist Ecole AVIESAN Training La Chapelle sur Erdre, Mars 2015 9

Training Galaxy4Bioinformatics V1: Roscoff / IFB-CNRS funding / Nov. 2014 V2: Nantes / IFB-INRA funding / March 2015 Program Architecture Tools Integration API Toolshed ~20 students / 12 teachers La Chapelle sur Erdre, Mars 2015 10

Sharing : API, automatic deployment, How-To, etc. ASR Dev. : Python Architecture IFB/MetaboHub Development Workflow4Metabolomics: a collaborative research infrastructure for computational metabolomics IFB/FG project (ToolShed session) Setup a tools/workfow repository La Chapelle sur Erdre, Mars 2015 11

IFB/FG 18-month project (Oct. 2014 - March 2016) Structuring sequencing facilities and bioinformatics in NGS analyses GT Galaxy Building and offering facilities and services in bioinformatics Aims Distribute tools/workflow Setup a visible and centralized repository La Chapelle sur Erdre, Mars 2015 12

IFB/FG: roadmap JOBIM Clermont Oct. 14 Apr. 15 Oct. 15 Mar. 16 INVENTORY FG platforms / GT Galaxy / Other partners INTEGRATION INTO GALAXY GOOD PRACTICES MANUAL TRAINING SUPPORT Contacts with the Galaxy Team IFB DEV REPOSITORY La Chapelle sur Erdre, Mars 2015 MAIN TOOLSHED IFB TAG 13

IFB/FG: First results Galaxy Team contact New Toolshed Test IFB development Toolshed TAG for IFB Tools in the main Toolshed Work on pipelines : e.g. SarTools (Institut Pasteur / ebio) Improve quality packages automatical testing expert reviewing La Chapelle sur Erdre, Mars 2015 14

PERSPECTIVES La Chapelle sur Erdre, Mars 2015 15

Opened Grants IFB Platforms Federation Project Roadmap 2015! e.g. : Automatic Galaxy environment builder ++ Training 2015 / Galaxy4Bioinformatics V3 : Toulouse / IFB INRA - CIRAD / 2-4 Nov. 2015! Animation Galaxy Day 19 Nov. 2015 Galaxy Community Conference - Norwich July 2015 La Chapelle sur Erdre, Mars 2015 16

Galaxy

«Big Data» http://www.genome.gov/sequencingcosts/ Stein Genome Biology 2010, 11:207 18

Problèmes Accessibilité des outils des workflows Reproductibilité des analyse Transparence des analyses 19

Reproductibilité Exemple : Projet pilote «1000 genomes project» : Série de recomandations sur la procédure d analyse 299 articles publiés en 2011 citent le papier «best practices», 19 sont des projets de re-séquençage avec des design expérimentaux similaires. 10 utilisent les outils recommandés de mapping et de découverte de variants. 4 utilisent le workflow complet. Malgré l effort de description, chacun son pipeline! Pourquoi? Les «NGS» évoluent : séquenceurs, outils d analyse Complexité des analyses et des workflows Accessibilité des workflows 20

Reproductibilité Mat & Met Scripts «maison» non distribués, mal expliqués : Outils précisés, sans la version ni les paramètres. Sur 50 papiers utilisant bwa en 2011, 31 ne citent pas sa version et ses paramètres (et 26 ne donnent pas accès aux données). Moins de 50% des analyses de micro-arrays publiées dans Nature Genetics en 2009 sont répétables. 21

Transparence Mat & Met Données, méta-données. Comment réutiliser les données? 22

Problème critique de reproductibilité Pourtant la reproductibilité est à la base de la démarche scientifique Nature 496, 398 (25 April 2013) 23

Quelles solutions? Outils de construction et d exécution de workflows qui permettent de rejouer une analyse : Mobyle Taverna Kepler Galaxy Développé depuis 2005 par Pen state university Emory university Reprend les bonnes idées des outils précédents Orienté communauté, partage et reproductibilité Accessibilité Reproductibilité Transparence 24

Reproductibilité Objectifs : «democratization of biomedical computation so that even the smallest research units with modest budgets are capable of carrying out analyses using appropriate tools in a reproducible fashion» Environnement pour réaliser et enregistrer des analyses. Permet l utilisation ou l inclusion des ces analyses dans des publications. 25

Accessibilité Pas besoin de programmer ou d apprendre à manier la ligne de commande, de connaître les détails d implémentation d un outil Interface unifiée d obtention et d analyse de données génomiques (ou autres) 26

Portail Galaxy 27

Portail Galaxy 28

Reproductibilité Capturer automatiquement les méta-données : provenance des données paramètres et enchainements des outils Enregistrer les jeux de données et les résultats intermédiaires Fournir les outils de documentation (annotations, tags) et de partage des analyses métadonnées : «ce qui a été fait» annotations : «pourquoi cela a été fait» 29

Reproductibilité Chaque analyse peut être rejouée, extraite sous forme de workflow et partagée Les workflows peuvent et doivent également être annotés 30

Transparence Les jeux de données, historiques d analyses et workflows peuvent être partagés : import/export de l ensemble de l analyse partage entre utilisateurs mise à disposition publique sur une instance de Galaxy Une analyse peut être documentée sous forme de «Galaxy page» 31

Transparence Page Galaxy : page web permettant la documentation complète d une analyse Texte libre (avec éventuellement des figures) Inclusion des jeux de données, historique d analyse et workflows Mécanisme d import permettant de rejouer l ensemble de l analyse sur les données fournies 32

Pages Galaxy 33

GigaDB Données brutes mises à dispositions sur SRA Données primaires mises à disposition sur GigaDB, avec un DOI associé. 34

Références Page web de Galaxy : http://galaxyproject.org/ Use galaxy : galaxy-central Get galaxy : distribution (install locale, cloud) Learn galaxy : tutorials, screencast Get involved : mailing lists and wiki How to cite Galaxy : https://wiki.galaxyproject.org/citinggalaxy Publications : Nekrutenko A, Taylor J: Next-generation sequencing data interpretation: enhancing reproducibility and accessibility. Nat Rev Genet 2012, 13:667 672. Goecks J, Nekrutenko A, Taylor J et al : Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences. Genome Biol 2010, 11:R86. 35

Machines Virtuelles Virtual Box 4.3.12 Extensions Mode USB 2.0 désactivé Guest additions installés CentOS 6.6

Les outils installés sous /usr/local/ Python 2.7.2 ipython 2.3.0 Bioblend 0.5.2 BLAST+ 2.2.28 MEME 7 SAMTOOLS Phylip R 3.1.1 + modules Environnement logiciel

Sessions Deux comptes galaxy Compte qui tourne le serveur Galaxy A utiliser pour se connecter! $HOME = /usr/local/galaxy mot de passe : galak42 root Compte pour installer d éventuelles librairies, etc.

TP myvm Executer la VM Se connecter avec le login galaxy su - galak42

Galaxy Open Source Framework Integrating Tools : biology, ecology, statistical, etc. Data connexion Access Web API

Architecture

Bases de données Stocke les meta-données workflow, historique, API, etc. utilisateurs, droits, etc. 130 tables! Par défaut : SQLite Base de données embarquée Relationnelle Problèmes de gestion des accès concurrents prevent database locking issues that can arise with multiple users. Utiliser MySQL /InnoDB ou PostgreSQL!

Galaxy : Installation - Objectif : encapsuler l instance dans un environnement Python vierge et dédié - Se connecter avec le compte galaxy - d wget http://bitbucket.org/ianb/virtualenv/raw/tip/virtualenv.py python virtualenv.py --no-site-packages galaxy_env - Executer l'environnement virtuel (activé dans le.bashrc) source $HOME/galaxy-dist/galaxy_env/bin/activate - Installer les modules pour l atelier API easy_install bioblend

Galaxy : Installation 1) Installation basique (instance niveau I) 1-1- Créer un utilisateur galaxy (déjà fait ici) et se connecter avec cet utilisateur

Galaxy : Installation 1) Installation basique (instance niveau I) 1-2- Récupérer les sources de Galaxy (en utilisant Mercurial) hg clone https://bitbucket.org/galaxy/galaxy-dist/ cd galaxy-dist hg update stable

Galaxy : Installation 1) Installation basique (instance niveau I) 1-2- Récupérer les sources de Galaxy (en utilisant Mercurial) (Solution sans réseau, récupération des sources sur un dépôt local de Mercurial) En root, lancer le serveur Mercurial su /etc/init.d/hgserver start exit Avec l utilisateur galaxy, clôner le dépot hg clone http://localhost:9000/galaxy-dist/ cd galaxy-dist hg update stable

Galaxy : Installation 1) Installation basique (instance niveau I) 1-3- Lancer le service Galaxy sh run.sh -v Tester l application via l URL: http://localhost:8080/

Galaxy : Installation 2) Test de bon fonctionnement de l instance TP: Tester l upload du fichier multi-fasta /usr/local/galaxy/galaxy-dist/testdata/meme/meme/meme_input_1.fasta Tester le bon fonctionnement de l outil Select lines that match an expression (Filter and sort) sur ce fichier pour ne garder que les noms de séquences Arrêter le service galaxy (Ctrl+C)

Galaxy : Installation 3) Répertoires et principaux fichiers de configuration - Les principaux fichiers de configuration se trouvent dans le répertoire galaxy-dist/config. galaxy.ini: configuration générale de l instance tool_conf.xml: configuration des outils disponibles tool_sheds_conf.xml: configuration des toolshed accessible depuis votre instance shed_tool_conf.xml: configuration des outils déployés sur l instance via un toolshed datatypes_conf.xml: déclaration des différents types de données - Les outils et wrappers se trouvent dans le répertoire galaxy-dist/tools. - Les descripteurs de données (fichier.loc ( location )) sont dans galaxy-dist/tool-data. La liste des génomes disponibles est à renseigner dans shared/ucsc/builds.txt - Le style et les pages HTML sont dans le répertoire galaxy-dist/static. Pour personnaliser la page d accueil, modifier le script galaxy-dist/static/welcome.html - A chaque modification d un de ces fichiers, le service doit être relancé: sh run.sh --daemon (pour lancer le service) sh run.sh --stop-daemon (pour arrêter)

Galaxy : Installation 4) Quelques paramétrages pour une instance (niveau II) Connecter à une base de données postgresql (par défaut SQLlite) - Se connecter sous le user postgres et créer l utilisateur et la base galaxy - Modifier le fichier galaxy.ini.sample pour indiquer les paramètres de connexion à cette base database_connection=postgres://galaxy:galak42@localhost/galaxy - Relancer le service et créer un compte utilisateur galaxy (login => Register) qui sera par la suite configuré en administrateur

4) Quelques paramétrages pour une instance (niveau II) - Gestion des utilisateurs. Dans le fichier galaxy.ini: Demander un accès par login et empêcher la création de compte require_login = True allow_user_creation = False Ajouter des comptes admin admin_users = prenom.nom@monmail.fr - Rendre l instance visible sur le réseau host = 0.0.0.0 - Lier un ToolShed local. Ajouter l info dans le fichier tool_sheds_conf.xml - Autoriser la gestion des quotas Galaxy : Installation <tool_shed name="my Own ToolShed" url="http://mytoolshed.fr/"/> enable_quotas = True

Galaxy : Installation 4) Quelques paramétrages pour une instance (niveau II) - Relancer le service en redirigeant les sorties vers un fichier de log mkdir /usr/local/galaxy/galaxy_logs sh run.sh --daemon --log-file /usr/local/galaxy/galaxy_logs/galaxy.log => TP: Relancer Galaxy sur ce modèle et tester la connexion du mode admin

Galaxy : Mode admin - Gestion des utilisateurs, groupes et rôles - Gestion des données et des librairies partagées - Gestion des quotas d espace disque - Visualisation des data types et data tables - Relance d un outil individuel après modification du wrapper XML d un outil - Gestion des jobs en cours - Gestion des toolsheds: installation d outil via toolshed

Galaxy : Gestion des données - Data libraries : partage de données entre utilisateurs - Création de nouvelles librairies en mode admin - Possibilité de lier des données lourdes stockées sur le serveur. Editer le fichier galaxy.ini: library_import_dir = mydir_of_data Puis aller chercher le fichier en mode admin dans la librairie - Possible également pour les utilisateurs non-admin user_library_import_dir = mydir_of_data => TP: Tester la création d une librairie et y lier un fichier de votre historique, puis un fichier du filesystem

Galaxy : Gestion des utilisateurs - Ajout de nouvel utilisateur, groupe et rôle Plus d infos: https://wiki.galaxyproject.org/learn/securityfeatures - Droits d accès aux librairies de données => TP: Tester la création d un utilisateur associé à un rôle, puis l accès à la librairie partagée à cet utilisateur

Galaxy : PATH et Tool dependencies Gestion du PATH galaxy: Ce que l on préconise: - Ajout des exécutables dans un répertoire bin spécifique à Galaxy. Puis ajout de ce répertoire dans le PATH de l utilisateur galaxy (via.bashrc) => TP: Tester l outil MEME. Puis installer MEME (/usr/local/src/meme_4.9.1) et ajouter l exécutable dans le PATH. (attention: l exécutable s appelle meme.bin) Relancer Galaxy. Retester.

Galaxy : PATH et Tool dependencies Pour les dépendances des outils installés via un ToolShed Les dépendances des outils installés via le toolshed peuvent être installées automatiquement, s ils sont correctement déclarés entre balises <requirement>, puis détaillés dans un fichier tool_dependencies.xml associé à l outil (cf TP Toolshed) Exemple: <requirements> <requirement type="package" version="4.9.1">meme</requirement> </requirements> Pour permettre la gestion de ces dépendances, créer un répertoire tool_dependencies à la racine du compte galaxy et le déclarer dans galaxy.ini en modifiant la directive tool_dependency_dir tool_dependency_dir = /usr/local/galaxy/tool_dependencies

Galaxy : Job configuration - Par défaut, les jobs Galaxy sont exécutés en local sur la machine où l application a été lancée. - De nombreuses options existent pour que les jobs soient lancés sur d autres systèmes, des clusters de calcul ou des machines distantes. - Capable de gérer différents DRMs (Distributed Resource Managers): Torque, SGE, LSF. - Le fichier job_conf.xml permet de spécifier différentes voies par lesquelles les jobs peuvent être exécutées. <plugin id="local" type="runner" load="galaxy.jobs.runners.local:localjobrunner"/> <plugin id="sge" type="runner" load="galaxy.jobs.runners.drmaa:drmaajobrunner"> <destinations> <destination id= local runner= local /> <destination id= remote_cluster runner= sge /> </destinations> - Une collection de Job destination permet de définir les paramètres à utiliser pour faire tourner un job à envoyer sur telle ou telle destination Remplace l ancien default_cluster_job_runner et la section [galaxy:tool_runners] - Par exemple, si un outil doit être exécuté avec des conditions particulières (spécifier une file d attente, davantage de mémoire...)

Galaxy : Job configuration - Autre exemple d application: Permet l envoi de données dans l historique Galaxy depuis un site distant

Galaxy : Job configuration Procédure - Déclarer une nouvelle source de données dans un fichier tools/data_source/mysource.xml <tool name="musa hub" id="mysource" tool_type="data_source"> <description> : Advanced Search Browser</description> <command interpreter="python">data_source.py $output $ app.config.output_size_limit</command> <inputs action="http://banana-genome.cirad.fr/advanced" check_values="false" method="get">... - Puis déclaration de cette source dans la section Get Data du tool_conf.xml. <section name="get Data" id="getext"> <tool file="data_source/upload.xml"/> <tool file="data_source/mysource.xml" /> - Déclarer la destination dans job_conf.xml <destination id= mysource runner= local /> - Enfin, il faut depuis le site distant générer un fichier accessible depuis une URL, puis spécifier un lien vers le tool_runner de galaxy: http://localhost:8080/tool_runner?tool_id=mysource;url=link_to_file

Mode pl@ : Architecture ++

Debug d une instance Mode debug log_level = INFO debug = False use_interactive = False Tracer les jobs cleanup_job = onsuccess

Statistiques d usage Par utilisateurs, mois, etc. Un script run_reports.sh Un fichier de configuration config/reports_wsgi.ini Log : reports_webapp.log Reporting

Reporting

Reporting

TP TP Reporting Activer le processus de reporting Consulter les stats (9001)

Un proxy? Performance Déléguer la gestion des données au serveur HTTP (e.g. : Apache) e.g. : Module XSendFile

Un proxy? Authentification externe Annuaire LDAP Module LDAP Apache LDAP

Un proxy? Exemple de configuration Apache <VirtualHost *:80> DocumentRoot /bidule ServerName mygalak.trotinet.com RewriteEngine on RewriteRule ^(.*) http://localhost:8080$1 [P] <Location "/"> # Apache renvoie les fichiers directement XSendFile on XSendFileAllowAbove on AuthType Basic AuthName "Galaxy Web Site: Use your LDAP login" AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPURL "ldap://myldap.trotinet.com/o=versailles,c=fr?uid?sub?(objectclass=person)" Require valid-user # Set the REMOTE_USER header to the contents of the LDAP query response's "uid" RequestHeader set REMOTE_USER %{AUTHENTICATE_uid}e </Location> </VirtualHost>

Optimisations Infrastructure Calcul Stockage

Optimisations Traitement Connecter un cluster de calcul Couche DRMAA Serveur NFS Middleware type SGE : paramètrage

Optimisations WEB : Proxy upload et download

Optimisations BDD Configuration : galaxy.ini database_engine_option_pool_size = 20 database_engine_option_max_overflow = 40 La base de données : tuning dépendant

Optimisations Instance

Multiplier les gestionnaires WEB : galaxy.ini Optimisation Instance As already mentioned, unloading work from the Galaxy process is important due to the Python Global Interpreter Lock (GIL). The GIL is how Python ensures thread safety, and it accomplishes this by only allowing one thread to control execution at a time. Utiliser le frontal Apache en mode balancer Ex: Formation avec 20 connexions simultanées Job : job_conf.xml https://wiki.galaxyproject.org/admin/config/jobs

FIN