osc.open_ondemand
Open OnDemand Ansible Rolle
Diese Ansible-Rolle installiert und konfiguriert Open OnDemand auf verschiedenen Linux-Distributionen.
Inhaltsverzeichnis
Versionskompatibilität
Die Versionsverwaltung dieser Rolle folgt grob den Versionen von Open OnDemand, die installiert werden. Die Haupt- und Nebenversionen dieser Rolle sind kompatibel mit den entsprechenden Haupt- und Nebenversionen von Open OnDemand. Patch-Versionen dieser Rolle sind kompatibel mit der Version von Open OnDemand, die installiert und konfiguriert wird, und bieten Fehlerbehebungen oder neue Funktionen.
Zum Beispiel ist die Version 1.8.0 dieser Rolle kompatibel mit den Versionen von Open OnDemand 1.8.x (derzeit 1.8.20). Die Version 1.8.1 dieser Rolle installiert weiterhin die Version 1.8.20 von Open OnDemand, bietet jedoch einige Fehlerbehebungen oder neue Funktionen für diese Rolle.
Unterstützte Betriebssysteme
- CentOS
- Debian
- Fedora
- RedHat
- Rocky Linux
- Suse
- Ubuntu 18
- Ubuntu 20
Installation einer spezifischen Version
Die Variable ondemand_package
steuert die Version des installierten rpm/dep-Pakets. Der Standardwert ondemand
installiert die neueste Version aus dem entsprechenden Repository, aktualisiert jedoch keine bestehende Installation. Sie können eine spezifische Version installieren, indem Sie den vollständigen Paketnamen verwenden (z.B. ondemand-3.0.3
) oder die Vergleichsoperatoren nutzen, die vom name
Parameter der Ansible- yum
oder apt Module unterstützt werden. Verwenden Sie latest
, um eine bestehende Installation zu aktualisieren.
Installation von der neuesten oder nächtlichen Version
Wenn Sie ein Paket aus unseren latest
oder nightly
Repositories installieren möchten, ändern Sie einfach die rpm_repo_url
-Konfiguration, um das entsprechende RPM herunterzuladen. Zum Beispiel 'https://yum.osc.edu/ondemand/latest/ondemand-release-web-latest-1-6.noarch.rpm'
. Überprüfen Sie yum für die richtige Version dieses RPMs.
Bei der Installation von Paketen aus den neuesten oder nächtlichen Versionen müssen möglicherweise Pakete ausgeschlossen werden, abhängig vom Status des Projekts. Zum Beispiel, wenn Sie 2.1 entwickeln, müssen die 2.0 RPMs in der neuesten oder nächtlichen Version Pakete ausschließen.
Verwenden Sie ondemand_package_excludes
, um eine Liste von Paketen anzugeben, die während der yum-Installation ausgeschlossen werden sollen. Hier ist ein Beispiel, um alle 2.1
-Pakete beim Installieren von 2.0.20
auszuschließen.
ondemand_package: 'ondemand-2.0.20'
ondemand_package_excludes:
- '*-2.1'
Tags
Diese Rolle hat folgende Tags, wenn Sie nur bestimmte Aufgaben ausführen möchten.
- configure - konfiguriert Open OnDemand und alle Apps
- install - installiert Open OnDemand und alle Apps
- deps - installiert Abhängigkeiten (nur gültig, wenn aus dem Quellcode gebaut wird)
- build - baut den Quellcode (nur gültig, wenn aus dem Quellcode gebaut wird)
Überschreibungen
Das Verzeichnis defaults enthält Konfigurationen, die nach den Dateien aufgeteilt sind, auf die sie angewendet werden, wenn Konfigurationen oder Optionen während des Builds aus dem Quellcode oder der Installation angewendet werden.
Überprüfen Sie diese Dateien auf Variablen, die Sie überschreiben können. Speichern Sie alle diese Überschreibungen in einer Datei, die Sie dann mit [email protected]
aufrufen können.
Alle Standarddateien sind nach ihrem Anwendungsbereich gruppiert. Einige Dateien sind nur für Dokumentationszwecke und enthalten nur Kommentare. Sie sind aufgrund der Kompatibilität mit Ansible 2.9.X und diesem Fehler beim Laden leerer Dateien verborgen.
.apps.yml
- Konfigurationen für die Installation von Apps (versteckt, da leer).build.yml
- Konfigurationen zum Bauen von OnDemand aus dem Quellcode.install.yml
- Konfigurationen für die Installation von OnDemand.nginx_stage.yml
- Konfigurationen, die auf/etc/ood/config/nginx_stage.yml
angewendet werden..ondemand.yml
- Konfigurationen, die auf/etc/ood/config/ondemand.d/ondemand.yml
angewendet werden (versteckt, da leer).ood_portal.yml
- Konfigurationen, die auf/etc/ood/config/ood_portal.yml
angewendet werden.
Verwendung dieser Rolle zur Verwaltung von Clustern und Apps
Es gibt einige Variablen in dieser Rolle, die Anpassungen und Konfigurationen für Open OnDemand ermöglichen.
clusters
Diese Konfiguration schreibt ihren Inhalt in /etc/ood/config/clusters.d/<cluster_key>.yml
für jedes Cluster-Element in diesem Wörterbuch. Jedes Wörterbuch-Element ist eine mehrzeilige Zeichenfolge.
Beispiel
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
Erzeugt /etc/ood/config/clusters.d/my_cluster.yml
und /etc/ood/config/clusters.d/another_cluster.yml
mit dem gleichen Inhalt.
my_cluster.yml
v2:
metadata:
title: my_cluster
...
another_cluster.yml
v2:
metadata:
title: Another Cluster
Weitere Informationen finden Sie in der Open OnDemand-Dokumentation und im Cluster-Konfigurationsschema v2.
ood_install_apps
Diese Konfiguration installiert Anwendungen aus benutzerdefinierten Repositories in das App-Verzeichnis (Standard oder benutzerdefiniert). Sie akzeptiert ein Wörterbuch wie das des git-Moduls. Der Hauptschlüssel ist der Name des Verzeichnisses, in das repo
im dest
-Verzeichnis geklont wird.
Nur repo:
ist erforderlich.
Beispiel für ood_install_apps
ood_install_apps:
jupyter:
repo: https://github.com/OSC/bc_example_jupyter.git
dest: "{{ ood_sys_app_dir }}" # Standardeinstellungen (optional)
version: master # Standardeinstellungen (optional)
customdir: # erstellt /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
Das obige Beispiel bewirkt, dass
OSC/bc_example_jupyter
nach/var/www/ood/apps/sys/jupyter
geklont wirdOSC/bc_example_rstudio
nach/var/www/ood/apps/my/dir/customdir
geklont wird
ood_apps
Dies ermöglicht es Ihnen, die Anwendung bc_desktop
zu konfigurieren und Umgebungsdateien für andere Anwendungen zu erstellen.
Im einfachsten Fall, wenn Ihnen ein env
-Schlüssel gegeben wird, wird eine Datei mit Schlüssel-Wert-Paaren geschrieben.
Im komplexeren Fall von bc_desktop
wird der Inhalt in eine <cluster>.yml
-Datei geschrieben (wobei der Dateiname das cluster
-Attribut des Inhalts ist) und der Inhalt des submit
-Schlüssels wird in die submit.yml.erb
-Datei geschrieben.
Die folgenden Beispiele sollten diese beiden Punkte veranschaulichen.
Beispiel für 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
Das obige Beispiel erstellt
/etc/ood/config
└── apps
├── bc_desktop
│ ├── my_cluster.yml
│ └── submit
│ └── submit.yml.erb
└── files
└── env
Die env
-Datei produziert eine key=value
-Datei. Beachten Sie die Großschreibung der Schlüssel.
$ cat /etc/ood/config/apps/files/env
OOD_SHELL=/bin/bash
Die submit
-Datei erstellt ein submit-Verzeichnis mit einer submit.yml.erb
, die die konfigurierten rohen Zeichenfolgendaten enthält. Beachten Sie, dass diese Konfiguration rohe Daten und kein YAML wie die anderen Konfigurationen enthält. Dies unterstützt die Ruby ERB-Template-Engine, die beim Lesen durch Ansible nicht einfach als YAML formatiert werden kann.
$ 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
Es gibt zwei Möglichkeiten, um Apache für mod_auth_openidc zu konfigurieren
Die erste und einfachste besteht darin, das Wörterbuch ood_auth_openidc
zu verwenden, um eine separate Konfigurationsdatei für OIDC-bezogene Konfigurationen zu generieren.
Die zweite Möglichkeit besteht darin, dass der ood-portal-generator die OIDC-Konfigurationen direkt in die ood-portal.conf
-Datei schreibt, indem er die benannten oidc_*
-Variablen wie oidc_provider_metadata_url
und oidc_client_id
verwendet. Sie können die OIDC-Standardwerte einsehen, um eine vollständige Liste der verfügbaren Werte zu sehen. Wenn Sie die Ansible-Vorlage verwenden, um ood-portal.conf
zu erzeugen, benötigen Sie das zusätzliche Flag oidc_settings_samefile
, das auf true gesetzt ist.
Beispiel für 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
Dies erzeugt eine auth_openidc.conf
-Datei mit aufgeführten key value
, die mit Standardwerten zusammengeführt wird. Werte, die in ood_auth_openidc
definiert sind, überschreiben alle Werte von default_auth_openidc
.
Weitere Informationen zu diesem Modul finden Sie in auth_openidc.
Dex installieren
Um Dex für OIDC zu installieren, setzen Sie das Flag install_ondemand_dex
auf true, und es wird das Paket installiert.
Beiträge
Wenn Sie auf ein Problem stoßen oder einen Funktionswunsch haben oder ein Problem behoben haben, lassen Sie es uns wissen! PRs sind willkommen! Selbst wenn Sie nur eine Frage haben, können Sie gerne ein Ticket eröffnen.
Installs and configures Open OnDemand on various Linux distributions.
ansible-galaxy install osc.open_ondemand