Rol de Ansible para Open OnDemand

Este rol de Ansible instala y configura Open OnDemand en varias distribuciones de Linux.

Tabla de Contenidos

• Compatibilidad de versiones
• Etiquetas
• Anulaciones
  • Usando este rol para gestionar clústeres y aplicaciones
    • clústeres
    • ood_install_apps
    • ood_apps
  • Open ID Connect
    • Instalar Dex
• Contribuyendo

Compatibilidad de versiones

La versionación de este rol seguirá de manera general las versiones de Open OnDemand que instala. Las versiones mayor y menor de este rol serán compatibles con las versiones mayor y menor correspondientes de Open OnDemand. Las versiones de parches en este rol serán compatibles con la versión de Open OnDemand que instala y configura, pero proporcionarán correcciones de errores o nuevas funciones.

Por ejemplo, la versión 1.8.0 de este rol será compatible con las versiones de Open OnDemand 1.8.x (que actualmente es 1.8.20). La versión 1.8.1 de este rol seguirá instalando la versión 1.8.20 de Open OnDemand, pero proporcionará algunas correcciones de errores o nuevas funciones a este rol.

Sistemas Operativos Soportados

• CentOS
• Debian
• Fedora
• RedHat
• Rocky Linux
• Suse
• Ubuntu 18
• Ubuntu 20

Instalando una versión específica

La variable ondemand_package controla la versión del paquete rpm/dep que se instala. El valor predeterminado de ondemand instalará la última versión del repositorio correspondiente, pero no actualizará una instalación existente. Puedes instalar una versión específica utilizando el nombre completo del paquete (por ejemplo, ondemand-3.0.3) o usar los operadores de comparación compatibles con el parámetro name de los módulos de Ansible yum o apt. Usa latest para actualizar una instalación existente.

Instalando desde el último o nocturno

Si deseas instalar un paquete desde nuestros repositorios latest o nightly, simplemente cambia la configuración rpm_repo_url para descargar el RPM apropiado. Por ejemplo, 'https://yum.osc.edu/ondemand/latest/ondemand-release-web-latest-1-6.noarch.rpm'. Verifica yum para la versión correcta de este RPM.

Al instalar paquetes desde la última o nocturna, es posible que debas excluir paquetes dependiendo del estado del proyecto. Por ejemplo, al desarrollar 2.1, los RPM de 2.0 en los repositorios más recientes o nocturnos necesitan excluir paquetes.

Usa ondemand_package_excludes para especificar una lista de paquetes a excluir durante la instalación de yum. Aquí hay un ejemplo para excluir todos los paquetes 2.1 al instalar 2.0.20.

ondemand_package: 'ondemand-2.0.20'
ondemand_package_excludes:
  - '*-2.1'

Etiquetas

Este rol tiene estas etiquetas cuando deseas ejecutar solo ciertas tareas.

• configurar - configurará Open OnDemand y cualquier aplicación
• instalar - instalará Open OnDemand y cualquier aplicación
• deps - instalar dependencias (solo válido al construir desde la fuente)
• build - construir el código fuente (solo válido al construir desde la fuente)

Anulaciones

El directorio defaults tiene configuraciones desglosadas por el archivo al que se aplican al configurar o durante la construcción desde la fuente o la instalación.

Consulta estos archivos para encontrar variables que puedes anular. Guarda todas estas anulaciones en un archivo que luego puedes llamar con [email protected].

Todos los archivos por defecto están agrupados por a lo que se aplican. Algunos archivos son solo para fines de documentación y solo tienen comentarios. Están ocultos para la compatibilidad de Ansible 2.9.X y este error de carga de archivos vacíos.

• .apps.yml - configuraciones para instalar aplicaciones (oculto porque está vacío).
• build.yml - configuraciones para construir OnDemand desde la fuente.
• install.yml - configuraciones para instalar OnDemand.
• nginx_stage.yml - configuraciones que se aplican a /etc/ood/config/nginx_stage.yml
• .ondemand.yml - configuraciones que se aplican a /etc/ood/config/ondemand.d/ondemand.yml (oculto porque está vacío).
• ood_portal.yml - configuraciones que se aplican a /etc/ood/config/ood_portal.yml

Usando este rol para gestionar clústeres y aplicaciones

Hay algunas variables en este rol que permiten personalizaciones y configuraciones de Open OnDemand.

clusters

Esta configuración escribe su contenido en /etc/ood/config/clusters.d/<cluster_key>.yml para cada elemento del clúster en este diccionario. Cada elemento del diccionario es una cadena multilinea.

Por ejemplo:

clusters:
  my_cluster: |
    ---
    v2:
      metadata:
        title: my_cluster
      login:
        host: my_host
      job:
        adapter: slurm
        bin: /usr/local
      batch_connect:
        basic:
          script_wrapper: "module restore\n%s"
  another_cluster: |
    ---
    v2:
      metadata:
        title: Another Cluster

Esto producirá /etc/ood/config/clusters.d/my_cluster.yml y /etc/ood/config/clusters.d/another_cluster.yml con el contenido exacto.

my_cluster.yml

v2:
  metadata:
    title: my_cluster
  ...

another_cluster.yml

v2:
  metadata:
    title: Another Cluster

Más detalles se pueden encontrar en documentación de Open OnDemand y Esquema de Configuración de Clúster v2.

ood_install_apps

Esta configuración instala aplicaciones desde repositorios personalizados en el directorio de aplicaciones (predeterminado o personalizado). Acepta un diccionario similar a los del módulo git. La clave principal es el nombre del directorio resultante donde se clona el repo en el directorio dest.

Solo repo: es requerido.

Ejemplo de ood_install_apps

ood_install_apps:
  jupyter:
    repo: https://github.com/OSC/bc_example_jupyter.git
    dest: "{{ ood_sys_app_dir }}"  # valores por defecto (opcional)
    version: master                # valores por defecto (opcional)
  customdir: # creará /var/www/ood/apps/my/dir/customdir
    repo: https://github.com/OSC/bc_example_rstudio
    dest: /var/www/ood/apps/my/dir
    version: v1.0.1

El ejemplo anterior hará:

• clonar OSC/bc_example_jupyter a /var/www/ood/apps/sys/jupyter
• clonar OSC/bc_example_rstudio a /var/www/ood/apps/my/dir/customdir

ood_apps

Esto te permite configurar la aplicación bc_desktop y escribir archivos de entorno para otras aplicaciones.

En el caso más simple, cuando se le da una clave env, escribirá pares clave-valor en un archivo de entorno.

En el caso más complejo de bc_desktop, escribe su contenido en un archivo <cluster>.yml (donde el nombre del archivo es el atributo cluster del contenido) y escribe el contenido de la clave submit en el archivo submit.yml.erb.

Los ejemplos a continuación deben ilustrar estos dos puntos.

Ejemplo de ood_apps

ood_apps:
  bc_desktop:
    title: "xfce desktop"
    cluster: "my_cluster"
    form:
      - desktop
      - hours
    attributes:
      hours:
        value: 1
      desktop: "xfce"
    submit: |
      ---
      script:
        native:
          - "-t"
          - "<%= '%02d:00:00' % hours %>"
  files:
    env:
      ood_shell: /bin/bash

El ejemplo anterior creará:

/etc/ood/config
└── apps
    ├── bc_desktop
    │   ├── my_cluster.yml
    │   └── submit
    │       └── submit.yml.erb
    └── files
        └── env

env producirá un archivo key=value. Nota la capitalización de las claves.

$ cat /etc/ood/config/apps/files/env
OOD_SHELL=/bin/bash

submit crea un directorio submit con un submit.yml.erb que contiene los datos de cadena en bruto que has configurado. Tenga en cuenta que la configuración es datos en bruto y no yaml como las demás configuraciones. Esto es para soportar la plantilla Ruby ERB que no se formatea fácilmente cuando se lee con Ansible como yaml.

$ cat /etc/ood/config/apps/bc_desktop/submit/submit.yml.erb
---
script:
  native:
    - "-t"
    - "<%= '%02d:00:00' % hours %>"

$ cat /etc/ood/config/apps/bc_desktop/submit/my_cluster.yml
title: "remote desktop"
cluster: my_cluster
attributes:
  hours:
    value: 1
  desktop: "xfce"

Open ID Connect

Hay dos maneras de configurar Apache para mod_auth_openidc.

La primera y más simple es usar el diccionario ood_auth_openidc para generar un archivo de configuración separado para los ajustes relacionados con OIDC.

La segunda es permitir que ood-portal-generator escriba la configuración OIDC directamente en el archivo ood-portal.conf utilizando las variables nombradas oidc_*, como oidc_provider_metadata_url y oidc_client_id. Puedes ver los valores predeterminados de oidc para ver una lista completa disponible. Si estás utilizando la plantilla de ansible para generar ood-portal.conf, necesitarás la bandera adicional oidc_settings_samefile configurada como verdadera.

Ejemplo de ood_auth_openidc

ood_auth_openidc:
  OIDCSessionMaxDuration: 28888
  OIDCClientID: myid
  OIDCProviderMetadataURL: https://localhost/
  OIDCCryptoPassphrase: mycryptopass
  "LDAPTrustedGlobalCert CA_BASE64": /etc/ssl/my/cert/path

default_auth_openidc:
  OIDCRedirectURI: "https://{{ servername }}{{ oidc_uri }}"
  OIDCSessionInactivityTimeout: 28800
  OIDCSessionMaxDuration: 28800
  OIDCRemoteUserClaim: preferred_username
  OIDCPassClaimsAs: environment
  OIDCStripCookies: mod_auth_openidc_session mod_auth_openidc_session_chunks mod_auth_openidc_session_0 mod_auth_openidc_session_1

Esto produce un archivo auth_openidc.conf con las key value listadas combinadas con los valores predeterminados. Los valores definidos en ood_auth_openidc sobreescriben cualquier valor de default_auth_openidc.

Consulta auth_openidc para más información sobre ese módulo.

Instalar Dex

Para instalar dex para OIDC, establece la bandera install_ondemand_dex como verdadera y se instalará el paquete.

Contribuyendo

Si encuentras un problema o tienes una solicitud de función o arreglaste algún problema, ¡háznoslo saber! ¡Las PR son bienvenidas! Incluso si solo tienes una pregunta, no dudes en abrir un ticket.