Rola Ansible: Lmod

Rola Ansible, która instaluje Lmod ze źródła.

Ta rola została napisana z myślą o wygodnej instalacji na klastrach HPC. Oznacza to, że możliwe jest zainstalowanie samego oprogramowania Lmod w globalnym, sieciowym systemie plików tylko na jednym hoście, podczas gdy wszystkie inne hosty instalują jedynie zależności Lmod oraz pliki konfiguracji powłoki. Niemniej jednak, ta rola pozwala również na instalację Lmod na jednym serwerze.

Rola ta umożliwia również stopniowe przechodzenie z innego systemu modułów do Lmod.

Spis treści

• Wymagania
• Zmienne roli
  • Zmienne bazowe
  • Cache systemu Spider
  • Konfiguracja powłoki
  • Stopniowe wprowadzenie
  • Wiadomości administracyjne
• Zależności
• Przykładowy Playbook
  • Playbook na najwyższym poziomie
  • Zależność roli
• Licencja
• Informacje o autorze

Wymagania

• Ansible 2.4
• cron do regularnego aktualizowania cache systemu spider

Zmienne roli

Zmienne bazowe

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

Dla klastrów HPC: Zmienna lmod_install powinna być ustawiona na yes wyłącznie dla hosta, który faktycznie instaluje Lmod w globalnym, sieciowym systemie plików. Wszystkie inne hosty zainstalują tylko zależności. To powinno być ustalone w host_vars, zobacz przykłady.

Możesz również określić ścieżki do plików modułów, które będą używane zamiast domyślnej lmod_module_root_path:

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

Może to być przydatne, jeśli masz legacy modules.

Pakiet lokalny

Możesz zmodyfikować plik SitePackage.lua:

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

Cache systemu Spider

Lokalizacja plików cache systemu spider:

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

Czy zainstalować zadanie cron do aktualizacji cache systemu spider:

lmod_spider_cache_cron: no
lmod_spider_cache_cron_minute: '0'

Zmień ścieżki do załączenia podczas generowania cache systemu spider:

lmod_spider_cache_cron_modulepath:
  - '$MODULEPATH'

Uwaga: Może być przydatne dodanie tutaj ścieżek innych niż domyślny MODULEPATH, zwłaszcza dla społeczności w Twoim systemie, które dostarczają własne katalogi modułów. Powiedzmy, że domyślny to /software/modules, z którego korzystają wszyscy, ale również masz /software/community/group-{a,b,c}/modules, które można dołączyć na żądanie. Dodając te ścieżki do cache systemu spider, zostaną one włączone przezroczysto, tj. znajdziesz je tylko za pomocą module spider, jeśli dołączyłeś ten katalog modułów do swojego MODULEPATH.

Dla klastrów HPC: To również jest potrzebne tylko na jednym hoście, zgodnie z tym samymi zasadami co lmod_install, zobacz przykłady.

Konfiguracja powłoki

Nazwy plików konfiguracyjnych powłoki, które będą zapisane w /etc/profile.d:

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

Zmiana tych nazw jest wymagana tylko w przypadku, gdy muszą być source'd w określonej kolejności, np. jeśli inny skrypt wymaga funkcji module lub ml, muszą być source'd po plikach Lmod.

Stopniowe wprowadzenie

Ten moduł zapewnia sposób na stopniowe wprowadzenie aka wydanie kanarkowe. Może to być ważne, jeśli migrujesz z innego systemu modułów środowiska do Lmod.

Uwaga: Aby uzyskać więcej informacji na temat wydań kanarkowych ogólnie, zobacz ten wpis na blogu. Dokumentacja Lmod, na której oparta jest ta konkretna stopniowa implementacja, jest dostępna tutaj.

lmod_canary: no

Ta zmienna ma trzy możliwe wartości:

1. no: nie używaj stopniowego wprowadzania, każdy użytkownik zainicjuje Lmod
2. 'opt-in': instaluje niestandardowe skrypty, które inicjalizują Lmod tylko wtedy, gdy istnieje plik opt-in
3. 'opt-in-skel': to samo co opt-in plus automatycznie instaluje nowe skrypty opt-in dla nowych użytkowników za pomocą szkieletu w /etc/skel
4. 'opt-out': instaluje niestandardowe skrypty, które nie inicjują Lmod, jeśli istnieje plik opt-out

Uwaga: Możesz przełączyć się z opt-in na opt-in-skel, z obu wariantów opt-in na opt-out oraz z opt-out na no. Zadania tej roli obsłużą te przejścia automatycznie.

To są nazwy plików dla opt-in i opt-out, które są szukane w domowym katalogu użytkownika:

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

Uwaga: Jeśli korzystasz ze stopniowego wprowadzania, wystarczy, że poinformujesz swoich użytkowników, że muszą touch ~/.lmod-yes dla opt-in, touch ~/.lmod-no dla opt-out oraz usunięcie tych plików, jeśli chcą powrócić do odpowiedniego domyślnego zachowania.

Wiadomości administracyjne

Opcjonalnie, możesz zdefiniować wiadomości administracyjne dla modułów, które będą wyświetlane, gdy będą ładowane:

lmod_admin_messages:

  - pattern: gcc/2%.95
    message: >-
      Ten moduł jest przestarzały i zostanie usunięty z systemu 1 stycznia
      1999. Proszę przejść na nowszy kompilator.

  - pattern: /opt/apps/modulefiles/Compiler/gcc/4.7.2/boost/1.55.0
    message: Mamy problemy.

  - pattern: boost/1%.[5-7].*
    message: Mamy więcej problemów.

Zależności

Ta rola warunkowo zależy od geerlingguy.repo-epel dla dystrybucji opartych na RedHat, aby zainstalować zależności runtime i kompilacji. Nie wszystkie z tych zależności są zawarte w domyślnych repozytoriach.

Przykładowy Playbook

Dodaj do requirements.yml:

---

# opcjonalnie
# - src: geerlingguy.repo-epel

- src: idiv-biodiversity.lmod

...

Pobierz:

$ ansible-galaxy install -r requirements.yml

Dla klastrów HPC: Jak wyjaśniono powyżej, niektóre zmienne muszą być ustawione tylko na hoście master/head (jak go nazywasz). Powinieneś ustawić je w odpowiednim pliku host_vars, np. host_vars/head.yml:

---

lmod_install: yes
lmod_spider_cache_cron: yes

...

Playbook na najwyższym poziomie

Napisz playbook na najwyższym poziomie:

---

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

...

Zależność roli

Zdefiniuj zależność roli w meta/main.yml:

---

dependencies:

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

...

Licencja

MIT

Informacje o autorze

Ta rola została stworzona w 2017 roku przez Christian Krause, znanego jako wookietreiber na GitHubie, administrator systemu klastrów HPC w Niemieckim Centrum Zintegrowanych Badań nad Różnorodnością Biologiczną (iDiv). Wsparcie dla Ubuntu Bionic zostało dodane przez Tom Schoonjans, Inżyniera Oprogramowania Badawczego dla HPC i Chmury w Instytucie Rosalind Franklin.