Rôle Ansible Open OnDemand

Ce rôle Ansible installe et configure Open OnDemand sur diverses distributions Linux.

Table des matières

• Compatibilité des versions
• Tags
• Remplacements
  • Utiliser ce rôle pour gérer le cluster et les applications
    • clusters
    • ood_install_apps
    • ood_apps
  • Open ID Connect
    • Installer Dex
• Contributions

Compatibilité des versions

La version de ce rôle suivra approximativement les versions d'Open OnDemand qu'il installe. Les versions majeures et mineures de ce rôle seront compatibles avec les versions majeures et mineures correspondantes d'Open OnDemand. Les mises à jour de ce rôle seront compatibles avec la version d'Open OnDemand qu'il installe et configure, mais elles fourniront des corrections de bogues ou de nouvelles fonctionnalités.

Par exemple, la version 1.8.0 de ce rôle sera compatible avec les versions d'Open OnDemand 1.8.x (qui est actuellement 1.8.20). La version 1.8.1 de ce rôle installera toujours la version 1.8.20 d'Open OnDemand mais offrira quelques corrections de bogues ou nouvelles fonctionnalités pour ce rôle.

Systèmes d'exploitation pris en charge

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

Installer une version spécifique

La variable ondemand_package contrôle la version du package rpm/dep installé. La valeur par défaut de ondemand installera la dernière version du dépôt concerné, mais ne mettra pas à jour une installation existante. Vous pouvez installer une version spécifique en utilisant le nom complet du package (par ex. ondemand-3.0.3) ou en utilisant les opérateurs de comparaison pris en charge par le paramètre name des modules ansible yum ou apt. Utilisez latest pour mettre à jour une installation existante.

Installation à partir de la dernière version ou de la version nocturne

Si vous souhaitez installer un package à partir de nos dépôts latest ou nightly, changez la configuration rpm_repo_url pour télécharger le RPM approprié. Par exemple 'https://yum.osc.edu/ondemand/latest/ondemand-release-web-latest-1-6.noarch.rpm'. Vérifiez yum pour la version correcte de ce RPM.

Lorsque vous installez des packages à partir de la dernière version ou de la version nocturne, vous devrez peut-être exclure des packages en fonction de l'état du projet. Par exemple, lors du développement de 2.1, les RPMs 2.0 sur latest ou nightly doivent exclure des packages.

Utilisez ondemand_package_excludes pour spécifier une liste de packages à exclure lors de l'installation yum. Voici un exemple pour exclure tous les packages 2.1 lors de l'installation de 2.0.20.

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

Tags

Ce rôle a ces tags lorsque vous souhaitez exécuter uniquement certaines tâches.

• configurer - configurera Open OnDemand et toutes les applications
• installer - installera Open OnDemand et toutes les applications
• deps - installer des dépendances (valable uniquement lors de la compilation à partir de la source)
• build - compiler le code source (valable uniquement lors de la compilation à partir de la source)

Remplacements

Le répertoire des défauts a des configurations réparties selon le fichier auquel elles s'appliquent lors de la configuration ou des options lors de la compilation à partir de la source ou de l'installation.

Vérifiez ces fichiers pour les variables que vous pouvez remplacer. Enregistrez tous ces remplacements dans un fichier que vous pouvez ensuite appeler avec [email protected]

Tous les fichiers par défaut sont regroupés par ce à quoi ils s'appliquent. Certains fichiers sont à des fins documentaires et n'ont que des commentaires. Ils sont masqués pour la compatibilité ansible 2.9.X et cette erreur de chargement de fichiers vides.

• .apps.yml - configurations pour l'installation d'applications (masqué car c'est vide).
• build.yml - configurations pour construire OnDemand à partir de la source.
• install.yml - configurations pour installer OnDemand.
• nginx_stage.yml - configurations qui s'appliquent à /etc/ood/config/nginx_stage.yml
• .ondemand.yml - configurations qui s'appliquent à /etc/ood/config/ondemand.d/ondemand.yml (masqué car c'est vide).
• ood_portal.yml - configurations qui s'appliquent à /etc/ood/config/ood_portal.yml

Utiliser ce rôle pour gérer le cluster et les applications

Il y a quelques variables dans ce rôle qui permettent des personnalisations et des configurations d'Open OnDemand.

clusters

Cette configuration écrit son contenu dans /etc/ood/config/clusters.d/<cluster_key>.yml pour chaque élément de ce dictionnaire. Chaque élément du dictionnaire est une chaîne de plusieurs lignes.

Par exemple

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

Produira /etc/ood/config/clusters.d/my_cluster.yml et /etc/ood/config/clusters.d/another_cluster.yml avec le contenu exact.

my_cluster.yml

v2:
  metadata:
    title: my_cluster
  ...

another_cluster.yml

v2:
  metadata:
    title: Another Cluster

Plus de détails peuvent être trouvés dans la documentation d'Open OnDemand et Cluster Config Schema v2.

ood_install_apps

Cette configuration installe des applications à partir de dépôts personnalisés dans le répertoire des applications (par défaut ou personnalisé). Elle accepte un dictionnaire comme ceux du module git. La clé principale est le nom du répertoire résultant où le repo est cloné sous le répertoire dest.

Seul repo: est requis.

Exemple de ood_install_apps

ood_install_apps:
  jupyter:
    repo: https://github.com/OSC/bc_example_jupyter.git
    dest: "{{ ood_sys_app_dir }}"  # valeurs par défaut (facultatif)
    version: master                # valeurs par défaut (facultatif)
  customdir: # créera /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

L'exemple ci-dessus va

• cloner OSC/bc_example_jupyter dans /var/www/ood/apps/sys/jupyter
• cloner OSC/bc_example_rstudio dans /var/www/ood/apps/my/dir/customdir

ood_apps

Cela vous permet de configurer l'application bc_desktop et d'écrire des fichiers d'environnement pour d'autres applications.

Dans le cas le plus simple, lorsqu'une clé env est fournie, elle écrira des paires clé-valeur dans un fichier d'environnement.

Dans le cas plus complexe de bc_desktop, elle écrit son contenu dans un fichier <cluster>.yml (où le nom de fichier est l'attribut cluster du contenu) et écrit le contenu de la clé submit dans le fichier submit.yml.erb.

Les exemples ci-dessous devraient illustrer ces deux points.

Exemple 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

L'exemple ci-dessus créera

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

env produit un fichier key=value. Notez la capitalisation des clés.

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

submit crée un répertoire submit avec un fichier submit.yml.erb contenant les données en chaîne brute que vous avez configurées. Notez que la configuration est des données brutes et non du yaml comme les autres configurations. Cela permet de prendre en charge le modèle Ruby ERB qui n'est pas facilement formaté lorsqu'il est lu par Ansible en tant que 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

Il existe deux façons de configurer Apache pour mod_auth_openidc

La première et la plus simple consiste à utiliser le dictionnaire ood_auth_openidc pour générer un fichier de configuration distinct pour les configurations liées à OIDC.

La seconde consiste à faire en sorte que le générateur du portail ood écrive directement les configurations OIDC dans le fichier ood-portal.conf en utilisant les variables nommées oidc_* comme oidc_provider_metadata_url et oidc_client_id. Vous pouvez consulter les valeurs par défaut oidc pour voir une liste complète disponible. Si vous utilisez le modèle ansible pour générer ood-portal.conf, vous aurez besoin de l'option supplémentaire oidc_settings_samefile définie sur true.

Exemple 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

Il produit un fichier auth_openidc.conf avec les key value listés fusionnés avec les valeurs par défaut. Les valeurs définies sur ood_auth_openidc remplacent les valeurs de default_auth_openidc.

Consultez auth_openidc pour plus d'informations sur ce module.

Installer Dex

Pour installer dex pour OIDC, activez le flag install_ondemand_dex sur true et il installera le package.

Contributions

Si vous rencontrez un problème, avez une demande de fonctionnalité ou avez corrigé un problème, faites-le nous savoir ! Les PR sont les bienvenues ! Même si vous avez juste une question, sentez-vous libre d'ouvrir un ticket.