galaxyproject.galaxy

Galaxy

Rola Ansible do instalacji i zarządzania serwerami Galaxy. Mimo mylącej nazwy, Galaxy nie ma związku z Ansible Galaxy.

Chcesz zacząć korzystać z tego modułu? Zobacz nasz Samouczek

Wymagania

Ta rola ma te same zależności, co moduł git. Ponadto wymagane są pip i Python virtualenv. Można je łatwo zainstalować za pomocą pre-task w tym samym playbooku:

- hosts: galaxyservers
  pre_tasks:
    - name: Zainstaluj zależności
      apt:
        name: "{{ item }}"
      become: yes
      when: ansible_os_family == 'Debian'
      with_items:
        - git
        - python-pip
        - python-virtualenv
    - name: Zainstaluj zależności
      yum:
        name: "{{ item }}"
      become: yes
      when: ansible_os_family == 'RedHat'
      with_items:
        - git
        - python-virtualenv
  roles:
    - galaxyproject.galaxy

Jeśli Twój wykonawczy git nie znajduje się w $PATH, możesz określić jego lokalizację zmienną git_executable. To samo dotyczy wykonawczego virtualenv i odpowiadającej mu zmiennej galaxy_virtualenv_command.

Zmienna roli

Nie wszystkie zmienne są wymienione ani szczegółowo wyjaśnione. Po więcej informacji na temat mniej używanych zmiennych zobacz plik domyślny.

Wiele zmiennych kontroluje, gdzie są umieszczane konkretne pliki i gdzie Galaxy zapisuje dane. Aby uprościć konfigurację, możesz wybrać układ za pomocą zmiennej galaxy_layout. Wybrany układ wpływa na wymagane zmienne.

Wymagane zmienne

Jeśli używasz innego układu niż root-dir:

galaxy_server_dir: ścieżka systemu plików, w której kod serwera Galaxy będzie instalowany (klonowany).

Jeśli używasz root-dir:

galaxy_root: ścieżka systemu plików do korzenia wdrożenia Galaxy, kod serwera Galaxy zostanie zainstalowany w podkatalogu tego katalogu.

Opcjonalne zmienne

Opcja galaxy_config_perms kontroluje uprawnienia, jakie będą nadane plikom konfiguracyjnym Galaxy. Opcja ta została dodana w wersji 0.9.18 i domyślna wartość to 0640 (odczyt i zapis dla użytkownika, odczyt dla grupy, inni użytkownicy nie mają uprawnień). W starszych wersjach rola nie kontrolowała uprawnień plików konfiguracyjnych, więc pamiętaj, że uprawnienia plików konfiguracyjnych mogą się zmienić od wersji 0.9.18 i późniejszych.

Kontrola układów

galaxy_layout: dostępne układy można znaleźć w podkatalogu vars/, a możliwe wartości obejmują:
- root-dir: Wszystko jest zorganizowane w podkatalogach pod jednym katalogiem głównym.
- opt: Układ zgodny z FHS w wielu katalogach, takich jak /opt, /etc/opt, itp.
- legacy-improved: Wszystko w katalogu serwera Galaxy, jak w przypadku run.sh.
- legacy: Domyślny układ przed istnieniem galaxy_layout, obecnie domyślny, aby nie zakłócać istniejącego użycia tej roli.
- custom: Rozsądne domyślne dla niestandardowych układów, wymaga ustawienia kilku zmiennych, jak opisano w vars/layout-custom.yml

Zaleca się używanie układu root-dir lub opt dla nowych wdrożeń Galaxy.

Możesz również nadpisywać domyślne ustawienia układu przy pomocy opcji poniżej, które kontrolują umiejscowienie pojedynczych plików lub podkatalogów.

Kontrola procesu z Gravity

Rola może zarządzać usługą Galaxy za pomocą gravity. To jest domyślnie dla Galaxy 22.05 i późniejszych. Dodatkowo, wsparcie dla zmiennej galaxy_restart_handler_name zostało usunięte. Jeśli musisz włączyć własny niestandardowy handler restartu, możesz użyć opcji „listen” w handlerze jak wyjaśniono w dokumentacji handler. Handler powinien „słuchać” na temat „restart galaxy”.

Motywy Galaxy

Od wersji 22.01 użytkownicy Galaxy mogą wybierać między różnymi motywami UI themes. Motywy można zdefiniować za pomocą zmiennej galaxy_themes, której składnia jest taka sama jak w pliku themes_conf.yml opisanym w szkoleniu na temat motywów.

Zmienna galaxy_manage_themes kontroluje, czy rola zarządza konfiguracjami motywów i jest automatycznie włączona, jeśli galaxy_themes jest zdefiniowana. Jeśli chcesz tylko załadować przykładowe motywy z Galaxy themes_conf.yml.sample bez definiowania własnych, możesz ręcznie ustawić galaxy_manage_themes na true.

Subdomeny Galaxy

Od wersji 22.01 Galaxy może serwować różne statyczne treści i motywy dla każdego hosta (np. subdomena).

Ustawiając galaxy_manage_subdomain_static: yes, włączasz tworzenie statycznych katalogów i konfiguracji dla każdego hosta.

Aby skorzystać z tej funkcji, musisz utworzyć następującą strukturę katalogów pod files/ (można ją dostosować zmienną galaxy_themes_ansible_file_path):

files/galaxy/static
├──<subdomain-name-1>
│   └── static
│       ├── dist (opcjonalnie)
│       │   └── some-image.png
│       ├── images (opcjonalnie)
│       │   └── more-content.jpg
│       └── welcome.html (opcjonalnie, w przeciwnym razie będzie wyświetlana strona galaxyproject.org.)
├── <subdomain-name-2>                            
│   └── static
│       ├── dist (opcjonalnie)
│       │   ├── another-static-image.svg
│       │   └── more-static-content-2.svg
│       └── welcome.html (opcjonalnie)
... (i wiele innych subdomen)

Gdzie powinno dokładnie pasować do nazwy Twojej subdomeny. Podkatalog static jest obowiązkowy, while all subdirectories in static are optional. To, które podkatalogi i pliki są kopiowane, zarządza zmienna static_galaxy_themes_keys.

Upewnij się również, że ustawiasz galaxy_themes_welcome_url_prefix, aby Twoje strony powitalne były poprawnie szablonowane.

Obowiązkowe jest ustawienie zmiennych w galaxy_themes_subdomains, jak pokazano w przykładzie w defaults/main.yml. Jeśli włączysz zmienną galaxy_manage_host_filters, możesz również określić sekcje narzędzi, które mają być wyświetlane dla każdej subdomeny.

Każda subdomena może mieć własny motyw, który jest zdefiniowany pod kluczem theme w wpisie subdomeny w galaxy_themes_subdomains. Ten motyw będzie domyślny dla subdomeny, a wszelkie inne motywy zdefiniowane globalnie dla serwera będą również dostępne dla użytkownika do wyboru. Jeśli motyw subdomeny nie jest zdefiniowany, zostanie użyty domyślny motyw globalny. Przykład można znaleźć w defaults/main.yml.

Kontrola funkcji

Kilka zmiennych kontroluje, które funkcje ta rola będzie wykonywać (wszystkie domyślnie ustawione na yes, chyba że zaznaczone):

galaxy_create_user (domyślnie: no): Utwórz użytkownika Galaxy. Praca jako dedykowany użytkownik to najlepsza praktyka, ale większość produkcyjnych instancji Galaxy, które przesyłają zadania do klastra, zarządza użytkownikami w usługach katalogowych (np. LDAP). Ta opcja jest przydatna dla samodzielnych serwerów. Wymaga uprawnień superużytkownika.
galaxy_manage_paths (domyślnie: no): Tworzy i zarządza właścicielstwem/uprawnieniami skonfigurowanych ścieżek Galaxy. Wymaga uprawnień superużytkownika.
galaxy_manage_clone: Klonuje Galaxy z repozytorium źródłowego i utrzymuje go w określonej wersji (commicie), a także ustawia [virtualenv][virtualenv], z którego można go uruchomić.
galaxy_manage_download: Pobiera i rozpakowuje Galaxy z zdalnego adresu URL archiwum, a także ustawia [virtualenv][virtualenv], z którego można go uruchomić.
galaxy_manage_existing: Przejmuje już istniejący katalog Galaxy, a także ustawia [virtualenv][virtualenv], z którego można go uruchomić. galaxy_server_dir musi wskazywać na ścieżkę, która już zawiera kod źródłowy Galaxy.
galaxy_manage_static_setup: Zarządza „statycznymi” plikami konfiguracyjnymi Galaxy - tymi, które nie mogą być modyfikowane przez serwer Galaxy. Minimalnie musi to być główny plik konfiguracyjny Galaxy, galaxy.ini.
galaxy_manage_mutable_setup: Zarządza „zmiennymi” plikami konfiguracyjnymi Galaxy - tymi, które mogą być modyfikowane przez Galaxy (np. podczas instalacji narzędzi z Galaxy Tool Shed).
galaxy_manage_database: Uaktualnia schemat bazy danych w razie potrzeby, gdy nowe wersje schematów stają się dostępne.
galaxy_fetch_dependencies: Pobiera zależne moduły Galaxy do wirtualnego środowiska Galaxy.
galaxy_build_client: Buduje aplikację kliencką Galaxy (interfejs webowy).
galaxy_client_make_target (domyślnie: client-production-maps): Ustala typ budowy klienta. Opcje to: client, client-production i client-production-maps. Zobacz readme klienta Galaxy po szczegóły.
galaxy_manage_systemd (domyślnie: no): Instaluje jednostkę usługi systemd do uruchamiania i zatrzymywania Galaxy z systemem (i za pomocą polecenia systemctl).
galaxy_manage_errordocs (domyślnie: no): Instaluje dokumenty błędów HTTP 413 i 502 stylizowane na Galaxy dla nginx. Wymaga uprawnień do zapisu w katalogu dokumentów błędów nginx.
galaxy_manage_cleanup (domyślnie: no): Instaluje zadanie cron do czyszczenia tymczasowych plików wykonawczych i frameworka Galaxy. Wymaga tmpwatch(8) na systemach opartych na RedHat lub tmpreaper(8) na systemach opartych na Debianie. Zobacz zmienne galaxy_tmpclean_* w pliku domyślnym po szczegóły.

Kod i konfiguracja Galaxy

Opcje konfiguracji Galaxy i kontrolowania, która wersja jest instalowana.

galaxy_config: Treść pliku konfiguracyjnego Galaxy (galaxy.ini domyślnie) jest kontrolowana przez tę zmienną. Jest to hasz haszy (lub słownik), który zostanie przetłumaczony na plik konfiguracyjny. Zobacz Przykłady Playbooków poniżej, aby zobaczyć, jak używać.
galaxy_config_files: Lista haszy (z kluczami src i dest) plików do skopiowania z maszyny kontrolnej. Na przykład, aby ustawić lokalizacje zadań, możesz użyć zmiennej galaxy_config_dir, a następnie jako dest nazwę pliku, np. dest: "{{ galaxy_config_dir }}/job_conf.xml". Upewnij się, że dodasz odpowiednie ustawienia w galaxy_config dla każdego pliku dodawanego tutaj (więc, jeśli dodasz job_conf.xml, upewnij się, że galaxy_config.galaxy.job_config_file odnosi się do tego pliku).
galaxy_config_templates: Lista haszy (z src i dest) szablonów do wypełnienia z maszyny kontrolnej.
galaxy_local_tools: Lista lokalnych plików narzędzi lub katalogów do skopiowania z maszyny kontrolnej, względem galaxy_local_tools_src_dir (domyślnie files/galaxy/tools w playbooku). Elementy listy mogą być albo nazwą pliku narzędzia, albo słownikiem z kluczami file, section_name, i opcjonalnie section_id. Jeśli section_name nie jest określony, narzędzia zostaną umieszczone w sekcji nazwanej Lokalne Narzędzia.
galaxy_local_tools_dir: Katalog na serwerze Galaxy, w którym będą instalowane lokalne narzędzia.
galaxy_dynamic_job_rules: Lista dynamicznych reguł zadań do skopiowania z maszyny kontrolnej, względem galaxy_dynamic_job_rules_src_dir (domyślnie files/galaxy/dynamic_job_rules w playbooku).
galaxy_dynamic_job_rules_dir (domyślnie: {{ galaxy_server_dir }}/lib/galaxy/jobs/rules): Katalog na serwerze Galaxy, w którym zostaną zainstalowane dynamiczne reguły zadań. Jeśli zmienia się z domyślnej wartości, upewnij się, że katalog znajduje się w $PYTHONPATH Galaxy (np. w {{ galaxy_venv_dir }}/lib/python2.7/site-packages) i odpowiednio skonfiguruj wtyczkę reguł dynamicznych w job_conf.xml.
galaxy_repo (domyślnie: https://github.com/galaxyproject/galaxy.git): Repozytorium Git, z którego należy sklonować Galaxy.
galaxy_commit_id (domyślnie: master): Id commit, tag, gałąź lub inna ważna referencja Git, do której Galaxy ma być zaktualizowane. Określenie gałęzi zaktualizuje do ostatniego commita na tej gałęzi. Użycie rzeczywistego id commit jest jedynym sposobem, by jednoznacznie zablokować Galaxy na określonej wersji.
galaxy_force_checkout (domyślnie: no): Jeśli yes, wszelkie zmodyfikowane pliki w repozytorium Galaxy zostaną odrzucone.
galaxy_clone_depth (domyślnie: nie ustawione): Głębokość używana podczas realizacji klonowania git. Pozostaw nieokreśloną, aby sklonować całą historię.

Dodatkowe pliki konfiguracyjne

Kilka opcjonalnych plików konfiguracyjnych powszechnie używanych w produkcyjnych serwerach Galaxy można skonfigurować za pomocą zmiennych:

galaxy_dependency_resolvers: Zapełni plik dependency_resolvers_conf.yml. Zobacz przykładową konfigurację XML po opcje.
galaxy_container_resolvers: Zapełni plik container_resolvers_conf.yml. Zobacz przykładową konfigurację XML po opcje.
galaxy_job_metrics_plugins: Zapełni plik job_metrics_conf.yml. Zobacz przykładową konfigurację XML po opcje.

Od Galaxy 21.05 przykładowe pliki konfiguracyjne dla tych funkcji są w formacie XML, ale YAML jest obsługiwany w następujący sposób:

galaxy_dependency_resolvers:
  - type: <nazwa tagu XML>
    <nazwa atrybutu XML>: <wartość atrybutu XML>

Na przykład:

galaxy_dependency_resolvers:
  - type: galaxy_packages
  - type: conda
    prefix: /srv/galaxy/conda
    auto_init: true
    auto_install: false

Konfiguracja ścieżki

Opcje do kontrolowania, gdzie niektóre komponenty Galaxy są umieszczane w systemie plików.

galaxy_venv_dir (domyślnie: <galaxy_server_dir>/.venv): Rola utworzy [virtualenv][virtualenv], z którego będzie działać Galaxy, kontroluje, gdzie virtualenv zostanie umieszczone.
galaxy_virtualenv_command: (domyślnie: virtualenv): Polecenie używane do tworzenia virtualenv Galaxy. Ustaw pyvenv, aby używać Pythona 3 w Galaxy >= 20.01.
galaxy_virtualenv_python: (domyślnie: python pierwszego virtualenv lub python z $PATH): Binarny plik pythona do użycia podczas tworzenia virtualenv. Dla Galaxy < 20.01 użyj python2.7 (jeśli nie jest to domyślny), dla Galaxy >= 20.01 użyj python3.5 lub wyższy.
galaxy_config_dir (domyślnie: <galaxy_server_dir>): Katalog, który będzie używany do „statycznych” plików konfiguracyjnych.
galaxy_mutable_config_dir (domyślnie: <galaxy_server_dir>): Katalog, który będzie używany do „zmiennych” plików konfiguracyjnych, musi być zapisywalny przez użytkownika uruchamiającego Galaxy.
galaxy_mutable_data_dir (domyślnie: <galaxy_server_dir>/database): Katalog, który będzie używany do „zmiennych” danych i pamięci podręcznych, musi być zapisywalny przez użytkownika uruchamiającego Galaxy.
galaxy_config_file (domyślnie: <galaxy_config_dir>/galaxy.ini): Główny plik konfiguracyjny Galaxy.

Zarządzanie użytkownikami i separacja uprawnień

galaxy_separate_privileges (domyślnie: no): Włącz tryb separacji uprawnień.
galaxy_user (domyślnie: użytkownik uruchamiający ansible): Nazwa systemowego użytkownika, pod którym działa Galaxy.
galaxy_privsep_user (domyślnie: root): Nazwa systemowego użytkownika, który jest właścicielem kodu Galaxy, plików konfiguracyjnych i virtualenv (i odpowiednich zależności).
galaxy_group: Wspólna grupa między użytkownikiem Galaxy a użytkownikiem separacji uprawnień. Jeśli jest ustawiona i zmienna galaxy_manage_paths jest włączona, katalogi zawierające potencjalnie wrażliwe informacje, takie jak plik konfiguracyjny Galaxy, będą tworzone z uprawnieniami grupowymi, ale nie będą ogólnodostępne. W przeciwnym razie katalogi mają uprawnienia ogólnodostępne.

Kontrola metody dostępu

Rola musi wykonywać zadania jako różni użytkownicy w zależności od tego, które funkcje zostały włączone i jak łączysz się z docelowym hostem. Domyślnie rola użyje become (tj. sudo) do wykonywania zadań jako odpowiedni użytkownik, jeśli zajdzie taka potrzeba. Nadpisanie tego zachowania omawiane jest w pliku domyślnym.

systemd

systemd jest standardowym demonem inicjalizacyjnym systemu w większości nowoczesnych dystrybucji Linuksa (i we wszystkich obsługiwanych przez tę rolę). Jeśli galaxy_manage_systemd jest włączone, usługa galaxy zostanie skonfigurowana w systemd do uruchamiania Galaxy. Usługa ta będzie automatycznie uruchamiana i konfigurowana do uruchamiania podczas rozruchu systemu. Możesz kontrolować usługę Galaxy za pomocą narzędzia systemctl jako użytkownik root lub przy użyciu sudo:

# systemctl start galaxy     # uruchom galaxy
# systemctl reload galaxy    # spróbuj "graceful" reload
# systemctl restart galaxy   # wykonaj twardy restart
# systemctl stop galaxy      # zatrzymaj galaxy

Możesz używać trybu użytkownika systemd, jeśli nie masz uprawnień roota w swoim systemie, ustawiając galaxy_systemd_root na false. Dodaj --user do powyższych poleceń systemctl, aby interagować z systemd w trybie użytkownika:

Dokumenty błędów

galaxy_errordocs_dir: Zainstaluj dokumenty błędów HTTP 413 i 502 stylizowane na Galaxy w tym katalogu. Komunikat 502 używa wbudowanych w serwer nginx, aby umożliwić administratorom stworzenie niestandardowej wiadomości w ~/maint, gdy Galaxy jest wyłączone. Nginx musi być skonfigurowany oddzielnie, aby obsługiwać te dokumenty błędów.
galaxy_errordocs_server_name (domyślnie: Galaxy): używane do wyświetlania wiadomości "galaxy_errdocs_server_name nie może być osiągnięty" na stronie 502.
galaxy_errordocs_prefix (domyślnie: /error): Ścieżka po stronie webowej do katalogu dokumentów błędów.

Różne opcje

galaxy_admin_email_to: Jeśli ustawione, wyślij e-mail na ten adres, gdy Galaxy zostanie zaktualizowane. Zakłada, że poczta jest prawidłowo skonfigurowana na zarządzanym hoście.
galaxy_admin_email_from: Adres, z którego wysłany zostanie powyższy e-mail.

Zależności

Brak

Przykład Playbooka

Podstawowy

Zainstaluj Galaxy na swoim lokalnym systemie ze wszystkimi domyślnymi opcjami:

- hosts: localhost
  vars:
    galaxy_server_dir: /srv/galaxy
  connection: local
  roles:
     - galaxyproject.galaxy

Jeśli Twoja wersja Ansible >= 2.10.4, gdy uruchomisz ansible-playbook playbook.yml, powinieneś dostarczyć dodatkowy argument -u $USER, w przeciwnym razie otrzymasz błąd.

Po zainstalowaniu możesz zacząć:

$ cd /srv/galaxy
$ sh run.sh

Najlepsza praktyka

Zainstaluj Galaxy zgodnie z najlepszymi praktykami aktualnych serwerów produkcyjnych:

Kod Galaxy (klon) jest "czysty": żadne konfiguracje ani zmienne dane nie żyją pod klonem
Kod Galaxy i statyczne konfiguracje są oddzielone uprawnieniami: nie są własnością/pisane przez użytkownika, który uruchamia Galaxy
Pliki konfiguracyjne nie są ogólnodostępne
PostgreSQL jest używane jako zaplecze do bazy danych
Używana jest konfiguracja w stylu YAML z 18.01+
Uruchamiane są dwa mule handlerów zadań
Gdy kod Galaxy lub konfiguracje są aktualizowane przez Ansible, Galaxy zostanie zrestartowane przy użyciu galaxyctl lub systemctl restart galaxy-*

- hosts: galaxyservers
  vars:
    galaxy_config_style: yaml
    galaxy_layout: root-dir
    galaxy_root: /srv/galaxy
    galaxy_commit_id: release_23.0
    galaxy_separate_privileges: yes
    galaxy_force_checkout: true
    galaxy_create_user: yes
    galaxy_manage_paths: yes
    galaxy_manage_systemd: yes
    galaxy_user: galaxy
    galaxy_privsep_user: gxpriv
    galaxy_group: galaxy
    postgresql_objects_users:
      - name: galaxy
        password: null
    postgresql_objects_databases:
      - name: galaxy
        owner: galaxy
    galaxy_config:
      gravity:
        process_manager: systemd
        galaxy_root: "{{ galaxy_root }}/server"
        galaxy_user: "{{ galaxy_user }}"
        virtualenv: "{{ galaxy_venv_dir }}"
        gunicorn:
          # opcje nasłuchu
          bind: "unix:{{ galaxy_mutable_config_dir }}/gunicorn.sock"
          # opcje wydajnościowe
          workers: 2
          # Inne opcje, które będą przekazywane do gunicorn
          # To pozwala na ustawienie 'bezpiecznych' nagłówków, takich jak REMOTE_USER (i inne)
          # https://docs.gunicorn.org/en/stable/settings.html#forwarded-allow-ips
          extra_args: '--forwarded-allow-ips="*"'
          # To pozwala Gunicorn na całkowite uruchomienie Galaxy przed forkowaniem, co jest szybsze.
          # https://docs.gunicorn.org/en/stable/settings.html#preload-app
          preload: true
        celery:
          concurrency: 2
          enable_beat: true
          enable: true
          queues: celery,galaxy.internal,galaxy.external
          pool: threads
          memory_limit: 2
          loglevel: DEBUG
        handlers:
          handler:
            processes: 2
            pools:
              - job-handlers
              - workflow-schedulers
      galaxy:
        database_connection: "postgresql:///galaxy?host=/var/run/postgresql"
  pre_tasks:
    - name: Zainstaluj zależności
      apt:
        name:
          - sudo
          - git
          - make
          - python3-venv
          - python3-setuptools
          - python3-dev
          - python3-psycopg2
          - gcc
          - acl
          - gnutls-bin
          - libmagic-dev
      become: yes
  roles:
    # Zainstaluj za pomocą:
    #   % ansible-galaxy install galaxyproject.postgresql
    - role: galaxyproject.postgresql
      become: yes
    # Zainstaluj za pomocą:
    #   % ansible-galaxy install natefoo.postgresql_objects
    - role: galaxyproject.postgresql_objects
      become: yes
      become_user: postgres
    - role: galaxyproject.galaxy