Rola Ansible dla Open OnDemand

Ta rola Ansible instaluję i konfiguruje Open OnDemand na różnych dystrybucjach systemu Linux.

Spis treści

• Kompatybilność wersji
• Tagi
• Właściwości
  • Używanie tej roli do zarządzania klastrami i aplikacjami
    • klastry
    • ood_install_apps
    • ood_apps
  • Open ID Connect
    • Instalacja Dex
• Wkład

Kompatybilność wersji

Wersjonowanie tej roli będzie luźno podążać za wersjami Open OnDemand, które instaluję. Główne i pomocnicze wersje tej roli będą kompatybilne z odpowiadającymi im wersjami Open OnDemand. Poprawki w tej roli będą kompatybilne z wersją Open OnDemand, którą instaluje i konfiguruje, ale będą zawierać poprawki błędów lub nowe funkcje.

Na przykład wersja 1.8.0 tej roli będzie kompatybilna z wersjami Open OnDemand 1.8.x (aktualnie 1.8.20). Wersja 1.8.1 tej roli nadal zainstaluje wersję 1.8.20 Open OnDemand, ale wprowadzi poprawki błędów lub nowe funkcje do tej roli.

Obsługiwane systemy operacyjne

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

Instalacja konkretnej wersji

Zmienna ondemand_package kontroluje wersję zainstalowanego pakietu rpm/dep. Domyślna wartość ondemand zainstaluje najnowszą wersję z odpowiedniego repozytorium, ale nie zaktualizuje istniejącej instalacji. Możesz zainstalować konkretną wersję, używając pełnej nazwy pakietu (np. ondemand-3.0.3) lub używając operatorów porównania obsługiwanych przez parametr name modułów Ansible yum lub apt. Użyj latest, aby zaktualizować istniejącą instalację.

Instalacja z najnowszej lub nocnej wersji

Jeśli chcesz zainstalować pakiet z naszych repozytoriów latest lub nightly, po prostu zmień konfigurację rpm_repo_url, aby pobrać odpowiedni RPM. Na przykład 'https://yum.osc.edu/ondemand/latest/ondemand-release-web-latest-1-6.noarch.rpm'. Sprawdź yum pod kątem poprawnej wersji tego RPM.

Podczas instalacji pakietów z najnowszej lub nocnej wersji może być konieczne wykluczenie niektórych pakietów w zależności od stanu projektu. Na przykład, gdy opracowujemy wersję 2.1, pakiety 2.0 w najnowszej lub nocnej wersji należy wykluczyć.

Użyj ondemand_package_excludes, aby określić listę pakietów do wykluczenia podczas instalacji yum. Oto przykład wykluczający wszystkie pakiety 2.1 podczas instalacji 2.0.20.

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

Tagi

Ta rola ma następujące tagi, gdy chcesz uruchomić tylko określone zadania.

• configure - skonfiguruje Open OnDemand i wszelkie aplikacje
• install - zainstaluje Open OnDemand i wszelkie aplikacje
• deps - zainstaluje zależności (ważne tylko podczas budowania ze źródła)
• build - zbuduje kod źródłowy (ważne tylko podczas budowania ze źródła)

Właściwości

Folder domyślny zawiera konfiguracje podzielone według tego, do którego pliku się odnoszą przy konfigurowaniu lub opcjach podczas budowania ze źródła lub instalacji.

Sprawdź te pliki pod kątem zmiennych, które możesz nadpisać. Zapisz wszystkie te nadpisania do pliku, który możesz następnie wywołać za pomocą [email protected]

Wszystkie pliki domyślne są pogrupowane według tego, do czego się odnoszą. Niektóre pliki mają jedynie charakter dokumentacyjny i zawierają tylko komentarze. Są ukryte dla zgodności z ansible 2.9.X oraz ten błąd ładowania pustych plików.

• .apps.yml - konfiguracje do instalacji aplikacji (ukryty, ponieważ jest pusty).
• build.yml - konfiguracje do budowania OnDemand ze źródła.
• install.yml - konfiguracje do instalacji OnDemand.
• nginx_stage.yml - konfiguracje, które dotyczą /etc/ood/config/nginx_stage.yml
• .ondemand.yml - konfiguracje, które dotyczą /etc/ood/config/ondemand.d/ondemand.yml (ukryty, ponieważ jest pusty).
• ood_portal.yml - konfiguracje, które dotyczą /etc/ood/config/ood_portal.yml

Używanie tej roli do zarządzania klastrami i aplikacjami

Istnieje kilka zmiennych w tej roli, które umożliwiają dostosowanie i konfigurację Open OnDemand.

klastry

Ta konfiguracja zapisuje zawartość do /etc/ood/config/clusters.d/<cluster_key>.yml dla każdego elementu klastra w tym słowniku. Każdy element słownika jest wielowierszowym ciągiem.

Na przykład

klastry:
  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

Wygeneruje /etc/ood/config/clusters.d/my_cluster.yml oraz /etc/ood/config/clusters.d/another_cluster.yml z dokładną zawartością.

my_cluster.yml

v2:
  metadata:
    title: my_cluster
  ...

another_cluster.yml

v2:
  metadata:
    title: Another Cluster

Więcej szczegółów można znaleźć w dokumentacji Open OnDemand i Cluster Config Schema v2.

ood_install_apps

Ta konfiguracja instaluje aplikacje z niestandardowych repozytoriów do katalogu aplikacji (domyślny lub niestandardowy). Akceptuje słownik w stylu modułu git. Głównym kluczem jest nazwa rezultatu katalogu, pod którą repozytorium jest klonowane do katalogu dest.

Tylko repo: jest wymagane.

przykład ood_install_apps

ood_install_apps:
  jupyter:
    repo: https://github.com/OSC/bc_example_jupyter.git
    dest: "{{ ood_sys_app_dir }}"  # domyślnie (opcjonalnie)
    version: master                # domyślnie (opcjonalnie)
  customdir: # utworzy /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

Powyższy przykład spowoduje

• sklonowanie OSC/bc_example_jupyter do /var/www/ood/apps/sys/jupyter
• sklonowanie OSC/bc_example_rstudio do /var/www/ood/apps/my/dir/customdir

ood_apps

Pozwala to na skonfigurowanie aplikacji bc_desktop i zapisanie plików środowiskowych dla innych aplikacji.

W najprostszym przypadku, gdy podany jest klucz env, zapisuje pary klucz-wartość w pliku env.

W bardziej skomplikowanym przypadku bc_desktop, zapisuje jego zawartość do pliku <cluster>.yml (gdzie nazwa pliku to atrybut cluster zawartości) i zapisuje zawartość klucza submit do pliku submit.yml.erb.

Poniższe przykłady powinny ilustrować te dwa punkty.

przykład 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

Powyższy przykład stworzy

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

env produkuje plik key=value. Zauważ wielkie litery kluczy.

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

submit tworzy katalog submit z plikiem submit.yml.erb, zawierającym surowe dane konfiguracyjne, które ustawiłeś. Zauważ, że konfiguracja jest surowymi danymi, a nie yaml, jak inne konfiguracje. Jest to potrzebne do wspierania Ruby ERB templating, które nie jest łatwe do sformatowania, gdy jest odczytywane przez Ansible jako 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

Jeśli chcesz skonfigurować Apache dla mod_auth_openidc,

Pierwsza i najprostsza metoda polega na użyciu słownika ood_auth_openidc, aby wygenerować osobny plik konfiguracyjny dla konfiguracji związanych z OIDC.

Drugą metodą jest pozwolenie generowaniu ood-portal-generator na zapisanie konfiguracji OIDC bezpośrednio do pliku ood-portal.conf poprzez użycie nazwanych zmiennych oidc_*, takich jak oidc_provider_metadata_url i oidc_client_id. Możesz zobaczyć domyślne wartości oidc, aby zobaczyć pełną listę. Jeśli używasz szablonu ansible do generowania ood-portal.conf, to będziesz potrzebować dodatkowego flaga oidc_settings_samefile ustawiona na true.

przykład 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

Tworzy to plik auth_openidc.conf z wymienionymi klucz wartość połączonymi z domyślnymi wartościami. Wartości zdefiniowane w ood_auth_openidc nadpisują jakiekolwiek wartości default_auth_openidc.

Zobacz auth_openidc po więcej informacji na temat tego modułu.

Instalacja Dex

Aby zainstalować dex dla OIDC, ustaw flagę install_ondemand_dex na true, a pakiet zostanie zainstalowany.

Wkład

Jeśli napotkasz jakiś problem lub masz pomysł na nową funkcjonalność, daj nam znać! PRy są mile widziane! Nawet jeśli masz tylko pytanie, nie wahaj się otworzyć zgłoszenia.