Rol de Ansible: Lmod

Un rol de Ansible que instala Lmod desde el código fuente.

Este rol fue escrito con la instalación conveniente en clústeres HPC en mente. Esto significa que es posible instalar el software real de Lmod en un sistema de archivos global y en red en solo un host, mientras que todos los demás hosts instalan solo las dependencias de Lmod y los archivos de configuración del shell. Sin embargo, también es posible instalar Lmod con este rol en un solo servidor.

Además, con este rol se puede transitar de manera incremental desde otro sistema de módulos a Lmod.

Tabla de Contenidos

• Requisitos
• Variables del Rol
  • Variables Base
  • Caché del Spider del Sistema
  • Configuración del Shell
  • Implementación Incremental
  • Mensajes Administrativos
• Dependencias
• Ejemplo de Playbook
  • Playbook de Alto Nivel
  • Dependencia del Rol
• Licencia
• Información del Autor

Requisitos

• Ansible 2.4
• cron para la actualización regular de la caché del spider del sistema

Variables del Rol

Variables Base

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

Para clústeres HPC: La variable lmod_install debe configurarse como yes solo para el host que realmente instala Lmod en el sistema de archivos global y en red, todos los demás hosts solo instalarán las dependencias. Esto debe establecerse en host_vars, ver ejemplos.

También puedes especificar las rutas de los archivos de módulos que se tomarán en lugar de la ruta predeterminada lmod_module_root_path:

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

Esto puede ser útil si tienes módulos heredados.

Paquete de Sitio

Puedes modificar el SitePackage.lua:

lmod_site_package: path/to/my/templates/SitePackage.lua

Caché del Spider del Sistema

Ubicación de los archivos de caché del spider del sistema:

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

Si se debe instalar el trabajo cron para actualizar la caché del spider del sistema:

lmod_spider_cache_cron: no
lmod_spider_cache_cron_minute: '0'

Cambia las rutas a incluir al generar la caché del spider del sistema:

lmod_spider_cache_cron_modulepath:
  - '$MODULEPATH'

Nota: Puede ser útil agregar otras rutas aquí además de la ruta predeterminada MODULEPATH, especialmente para comunidades dentro de tu sistema que proporcionan sus propios directorios de módulos. Supón que tu predeterminado es /software/modules, que todos reciben, pero también tienes /software/community/group-{a,b,c}/modules, que pueden ser incluidos según se necesite. Al agregar estas rutas a la caché del spider del sistema, incluirá esos módulos transparentemente, es decir, solo podrás encontrarlos con module spider, si has incluido ese directorio de módulos en tu MODULEPATH.

Para clústeres HPC: Esto también es necesario solo en un solo host, siguiendo las mismas reglas que lmod_install, ver ejemplos.

Configuración del Shell

Nombres de los archivos de configuración del shell que se escribirán en /etc/profile.d:

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

Cambiar estos nombres solo es necesario si deben ser source'd en un orden específico, por ejemplo, si otro script requiere las funciones module o ml, deben ser source'd después de los archivos de Lmod.

Implementación Incremental

Este módulo proporciona una manera para la implementación incremental, también conocido como lanzamiento canario. Esto puede ser importante si estás migrando desde otro sistema de módulos de entorno a Lmod.

Nota: Para más información sobre lanzamientos canarios en general, consulta esta publicación de blog. La documentación de Lmod en la que se basa esta implementación incremental se puede encontrar aquí.

lmod_canary: no

Esta variable tiene tres valores posibles:

1. no: no usar implementación incremental, cada usuario inicializará Lmod
2. 'opt-in': instala scripts personalizados que inicializan Lmod solo si el archivo opt-in existe
3. 'opt-in-skel': igual que opt-in más también instala automáticamente a los nuevos usuarios opt-in a través de skeleton en /etc/skel
4. 'opt-out': instala scripts personalizados que no inicializan Lmod si el archivo opt-out existe

Nota: Puedes cambiar de opt-in a opt-in-skel, de ambas variantes de opt-in a opt-out y de opt-out a no, las tareas proporcionadas por este rol manejarán estas transiciones automáticamente.

Estos son los nombres de los archivos para opt-in y opt-out que se buscan en el directorio home de los usuarios:

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

Nota: Si estás utilizando la implementación incremental, solo necesitas hacer saber a tus usuarios que deben touch ~/.lmod-yes para opt-in, touch ~/.lmod-no para opt-out y eliminar estos archivos si quieren volver al comportamiento predeterminado respectivo.

Mensajes Administrativos

Opcionalmente, puedes definir mensajes administrativos para que los módulos se muestren al cargarse:

lmod_admin_messages:

  - pattern: gcc/2%.95
    message: >-
      Este módulo está obsoleto y será eliminado del sistema el 1 de enero
      de 1999. Por favor, cambie a un compilador más nuevo.

  - pattern: /opt/apps/modulefiles/Compiler/gcc/4.7.2/boost/1.55.0
    message: Estamos teniendo problemas.

  - pattern: boost/1%.[5-7].*
    message: Estamos teniendo más problemas.

Dependencias

Este rol depende condicionalmente de geerlingguy.repo-epel para distribuciones basadas en RedHat para instalar dependencias de ejecución y construcción. No todas estas dependencias están incluidas en los repositorios predeterminados.

Ejemplo de Playbook

Añadir a requirements.yml:

---

# opcional
# - src: geerlingguy.repo-epel

- src: idiv-biodiversity.lmod

...

Descargar:

$ ansible-galaxy install -r requirements.yml

Para clústeres HPC: Como se explicó arriba, algunas variables deben configurarse solo en el host principal (como lo llames). Debes establecer estas en el respectivo archivo host_vars, por ejemplo, host_vars/head.yml:

---

lmod_install: yes
lmod_spider_cache_cron: yes

...

Playbook de Alto Nivel

Escribe un playbook de alto nivel:

---

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

...

Dependencia del Rol

Define la dependencia del rol en meta/main.yml:

---

dependencies:

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

...

Licencia

MIT

Información del Autor

Este rol fue creado en 2017 por Christian Krause también conocido como wookietreiber en GitHub, administrador de sistemas de clúster HPC en el Centro Alemán para la Investigación Integrativa de Biodiversidad (iDiv). El soporte para Ubuntu Bionic fue añadido por Tom Schoonjans, ingeniero de software de investigación para HPC y Cloud en el Instituto Rosalind Franklin.