Déployer un service

Dans un environnement Conda

Les définitions des environnements Conda sont situées dans le groupe conda.

Ces définitions comprennent deux fichiers:

Un fichier meta.yml qui contient des informations générales à propos de l'environnement,
Un fichier de définition env.yml.

Lors du push, l'environnement conda sera automatiquement créé à partir du fichier env.yml avec un nom sous la forme [nom_du_projet]-[nom_de_la_branche]-rpbs et placé dans /shared/software/conda/envs/.

Un fichier module sera également créé et placé dans /shared/software/modulefiles/.

On pourra alors charger le module en tapant par exemple:

module load alphafold/2.1.1-rpbs

Note: le symbole -rpbs est automatiquement ajouté au nom de la branche / version pour éviter toute confusion avec les environnements déployés via le NNCR.

On peut également déployer l'environnement en déclenchant manuellement un pipeline. Pour cela:

Se rendre dans CI/CD > Pipelines,
Cliquer sur Run pipeline,
Dans le menu Run for branch name or tag, sélectionner la branche/version,
Cliquer sur Run pipeline.

Dans un container (Docker/Singularity)

Les définitions des containers Docker/Singularity sont situées dans le groupe docker.

Ces définitions comprennent un fichier Dockerfile et tous les fichiers nécessaires à la construction du container.

Lors du push, le container sera automatiquement créé à partir du fichier Dockerfile avec un nom sous la forme [nom_du_projet]-[nom_de_la_branche]-rpbs.sif et placé dans /shared/software/singularity/images/.

Si le nom de la branche / version ne contient pas le symbole -dev, les dossiers définis par la variable PATH (par exemple: /usr/local/bin) seront scannés à la recherche de fichiers executables puis un fichier wrapper sera créé pour chacun d'entre eux et placé dans /shared/software/singularity/wrappers/.

Un fichier module sera également créé et placé dans /shared/software/modulefiles/.

On pourra alors charger le module en tapant par exemple:

module load pepfold-core/1.0-rpbs

Note: le symbole -rpbs est automatiquement ajouté au nom de la branche / version pour éviter toute confusion avec les environnements déployés via le NNCR.

On peut également déployer l'environnement en déclenchant manuellement un pipeline. Pour cela:

Se rendre dans CI/CD > Pipelines,
Cliquer sur Run pipeline,
Dans le menu Run for branch name or tag, sélectionner la branche/version,
Cliquer sur Run pipeline.

Inclusion de sous-modules Git

Les sous-modules permettent de gérer un dépôt Git comme un sous-répertoire d'un autre dépôt Git. Cela permet de cloner des dépöts dans le projet et de garder isolés les commits de ce dépôt.

Pour ajouter un sous-module:

git submodule add git@172.27.7.118:src/PyPDB.git src/PyPDB

ou:

git submodule add ../src/PyPDB.git src/PyPDB

Attention, le dépôt inclu comme sous-module doit impérativement être public pour qu'il soit accessible par le pipeline d'intégration de Gitlab.

Ne pas oublier de tracker le fichier .gitmodules nouvellement créé:

git add .gitmodules

Pour tirer la dernière version du sous-module:

git submodule update --remote

Ne pas oublier de refaire un commit du dépôt Git principal pour que Git mette à jour les pointeurs vers les sous-modules.

Note: le pipeline d'intégration Gitlab tire toujours la dernière version disponible des sous-modules lors de la construction des containers.

Écrire un pipeline

Pour lancer un pipeline python qui utilise la bibliothèque cluster.py, il faut charger l'environnement conda adéquat:

Pour les pipelines python2:

module load rpbs_services/py2-rpbs

Pour les pipelines python3 :

module load rpbs_services/py3-rpbs

Utilisation de la bibliothèque python cluster

runTasks(command, args, tasks, tasks_from, environment_module, log_prefix, map_list, job_name, job_opts, joinFiles, progress, partition, account, qos, wait)

command : chemin vers l'exécutable.
args : liste contenant les arguments au format string à passer à la commande. Le symbole "map_item" est substitué par l'élément courant de la liste fournie par l'argument map_list.
tasks : nombre de tâches à accom1) plir (job array). Chaque itération incrémente d'une unité la variable d'environnement SLURM_ARRAY_TASK_ID. Défaut = 1.
tasks_from : valeur initiale pour la variable d'environnement SLURM_ARRAY_TASK_ID. Défaut = 1.
environment_module : nom de l'environment/version à charger. Doit être spécifié de la même façon qu'avec module load.
log_prefix : préfix des fichiers .log et .err retournés par Slurm. Défaut = slurm.
map_list : lance autant de tâches que d'éléments contenus dans la liste. Chaque élément est substitué au symbole "map_item" fourni par args.
job_name : nom attribué au job. Défaut = environment_module:command.
job_opts : ajouter des options de paramétrage pour Slurm.
joinFiles : fusionner tous les fichiers de logs en un seul. Si paramétré sur False, un fichier de log sera créé par tâche. Défaut = True.
progress : affichage de la progression (Mobyle). Défaut = True.
partition : partition Slurm sur laquelle envoyer le job. Défaut = partition du job principal.
account : compte Slurm sur lequel envoyer le job. Défaut = compte du job principal.
qos : spécification du QoS (Quality of Service) du job. Défaut = QoS du job principal.

Exemple simple de script python utilisant la bibliothèque cluster:

#!/usr/bin/env python

import cluster.cluster as cluster

cmd = "PyPPP3Exec"

args = ["-s %s" % self.options.seqFile,
        "-l %s" % self.options.label,
        "-v"]                         


cluster.runTasks(cmd, args, environment_module = "pyppp3-light/1.0-rpbs", log_prefix = "ppp")

Exemple de script qui va itérer sur une liste:

#!/usr/bin/env python

import cluster.cluster as cluster

cmd = "SiteAlignReverse_service"

args = [ "map_item",
         "%s.pdbqt" % os.path.splitext(ps_input_file)[0],
         "%s" % p_args.scoring_method,
         "%s" % DFLT_BS_BANK ]

pdbid_list = ['1kid', '2r7g', '1i27']

cluster.runTasks(cmd, s_args, environment_module = patchsearch/2.0, map_list = pdbid_list, log_prefix = "sitealign")