Rôle Ansible : Lmod

Un rôle Ansible qui installe Lmod à partir des sources.

Ce rôle a été conçu pour une installation pratique sur des clusters HPC. Cela signifie qu'il est possible d'installer le logiciel Lmod sur un seul hôte dans un système de fichiers partagé global, tandis que tous les autres hôtes n'installeront que les dépendances de Lmod et les fichiers de configuration de shell. Toutefois, il est bien sûr possible d'installer Lmod avec ce rôle sur un seul serveur.

De plus, il est possible avec ce rôle de passer progressivement d'un autre système de modules à Lmod.

Table des matières

• Exigences
• Variables du rôle
  • Variables de base
  • Cache d'araignée système
  • Configuration de shell
  • Déploiement progressif
  • Messages administratifs
• Dépendances
• Exemple de Playbook
  • Playbook de haut niveau
  • Dépendance de rôle
• Licence
• Informations sur l'auteur

Exigences

• Ansible 2.4
• cron pour la mise à jour régulière du cache d'araignée système

Variables du rôle

Variables de base

lmod_version: '7.7.14'
lmod_install: no
lmod_prefix: '/opt/apps'
lmod_module_root_path: '{{ lmod_prefix }}/modulefiles'

Pour les clusters HPC : La variable lmod_install doit être définie sur yes uniquement pour l'hôte qui installe réellement Lmod sur le système de fichiers partagé global, tandis que tous les autres hôtes n'installeront que les dépendances. Cela doit être défini dans host_vars, voir exemples.

Vous pouvez également spécifier les chemins des fichiers de modules qui remplaceront le chemin par défaut lmod_module_root_path :

lmod_module_paths:
  - '/software/modulefiles/compiler'
  - '/software/modulefiles/libraries'
  - '/software/modulefiles/tools'

Cela peut être utile si vous avez des modules hérités.

Package du site

Vous pouvez modifier le SitePackage.lua :

lmod_site_package: chemin/vers/mes/templates/SitePackage.lua

Cache d'araignée système

Emplacement des fichiers de cache d'araignée système :

lmod_spider_cache_dir: '{{ lmod_module_root_path }}/.spider-cache'
lmod_spider_cache_stamp_file: '{{ lmod_module_root_path }}/.spider-cache.stamp'

S'il faut installer le travail cron de mise à jour du cache d'araignée système :

lmod_spider_cache_cron: no
lmod_spider_cache_cron_minute: '0'

Changez les chemins à inclure lors de la génération du cache d'araignée système :

lmod_spider_cache_cron_modulepath:
  - '$MODULEPATH'

Note : Il peut être utile d'ajouter ici des chemins autres que le MODULEPATH par défaut, surtout pour les communautés au sein de votre système qui fournissent leurs propres répertoires de modules. Supposons que votre défaut soit /software/modules, que tout le monde utilise, mais que vous ayez aussi /software/community/group-{a,b,c}/modules, qui peuvent être inclus à la demande. En ajoutant ces chemins au cache d'araignée système, il inclura ces modules de manière transparente, c'est-à-dire que vous ne pourrez les trouver avec module spider que si vous avez inclus ce répertoire de modules dans votre MODULEPATH.

Pour les clusters HPC : Cela n'est également nécessaire que sur un seul hôte, suivant les mêmes règles que pour lmod_install, voir exemples.

Configuration de shell

Noms des fichiers de configuration de shell qui seront écrits dans /etc/profile.d :

lmod_init_bash_file: 'z00-lmod.sh'
lmod_init_csh_file: 'z00-lmod.csh'

Changer ces noms n'est nécessaire que s'ils doivent être source'd dans un ordre spécifique, par exemple si un autre script nécessite les fonctions module ou ml, elles doivent être source'd après les fichiers Lmod.

Déploiement progressif

Ce module offre un moyen de déploiement progressif, ou canary release. Ceci peut être important si vous migrez d'un autre système de modules d'environnement à Lmod.

Note : Pour plus d'informations sur les déploiements progressifs en général, voir cet article de blog. La documentation de Lmod sur ce déploiement progressif peut être trouvée ici.

lmod_canary: no

Cette variable a trois valeurs possibles :

1. no: ne pas utiliser le déploiement progressif, chaque utilisateur initialise Lmod
2. 'opt-in': installe des scripts personnalisés qui initient Lmod uniquement si un fichier opt-in existe
3. 'opt-in-skel': idem que opt-in mais installe automatiquement l'opt-in pour les nouveaux utilisateurs via squelette dans /etc/skel
4. 'opt-out': installe des scripts personnalisés qui n'initient pas Lmod si un fichier opt-out existe

Note : Vous pouvez passer de opt-in à opt-in-skel, des deux variantes opt-in à opt-out et de opt-out à no, les tâches fournies par ce rôle géreront automatiquement ces transitions.

Voici les noms de fichiers pour opt-in et opt-out qui sont recherchés dans le répertoire personnel des utilisateurs :

lmod_canary_opt_in_file: '.lmod-yes'
lmod_canary_opt_out_file: '.lmod-no'

Note : Si vous utilisez le déploiement progressif, il vous suffit d'informer vos utilisateurs qu'ils doivent créer le fichier ~/.lmod-yes pour opt-in, ~/.lmod-no pour opt-out et supprimer ces fichiers s'ils souhaitent revenir au comportement par défaut respectif.

Messages administratifs

Facultativement, vous pouvez définir des messages administratifs pour les modules qui seront affichés lors de leur chargement :

lmod_admin_messages:

  - pattern: gcc/2%.95
    message: >-
      Ce module est obsolète et sera retiré du système le 1er janvier
      1999. Veuillez passer à un compilateur plus récent.

  - pattern: /opt/apps/modulefiles/Compiler/gcc/4.7.2/boost/1.55.0
    message: Nous avons des problèmes.

  - pattern: boost/1%.[5-7].*
    message: Nous avons encore plus de problèmes.

Dépendances

Ce rôle dépend conditionnellement de geerlingguy.repo-epel pour les distributions basées sur RedHat afin d'installer les dépendances d'exécution et de compilation. Toutes ces dépendances ne sont pas incluses dans les dépôts par défaut.

Exemple de Playbook

Ajoutez au requirements.yml :

---

# facultatif
# - src: geerlingguy.repo-epel

- src: idiv-biodiversity.lmod

...

Téléchargez :

$ ansible-galaxy install -r requirements.yml

Pour les clusters HPC : Comme expliqué ci-dessus, certaines variables doivent être définies uniquement sur l'hôte maître/tête (selon le nom que vous lui donnez). Vous devriez définir celles-ci dans le fichier host_vars respectif, par exemple host_vars/head.yml :

---

lmod_install: yes
lmod_spider_cache_cron: yes

...

Playbook de haut niveau

Écrivez un playbook de haut niveau :

---

- name: serveur principal
  hosts: head
  roles:
    - role: idiv-biodiversity.lmod
      tags:
        - lmod
        - modules
  vars:
    lmod_prefix: '/software'
    lmod_install: yes
    lmod_canary: 'opt-in'

...

Dépendance de rôle

Définissez la dépendance de rôle dans meta/main.yml :

---

dependencies:

  - role: idiv-biodiversity.lmod
    vars:
      lmod_prefix: '/software'
      lmod_canary: 'opt-in'
    tags:
      - lmod
      - modules

...

Licence

MIT

Informations sur l'auteur

Ce rôle a été créé en 2017 par Christian Krause alias wookietreiber sur GitHub, administrateur de systèmes de cluster HPC au Centre Allemand de Recherche Biodiversité Intégrative (iDiv). Le support d'Ubuntu Bionic a été ajouté par Tom Schoonjans, Ingénieur logiciel de recherche pour HPC et Cloud au Rosalind Franklin Institute.