galaxyproject.galaxy

Galaxy

Eine Ansible Rolle zur Installation und Verwaltung von Galaxy Servern. Trotz der Namensverwirrung hat Galaxy keine Verbindung zu Ansible Galaxy.

Möchten Sie mit diesem Modul beginnen? Schauen Sie sich unser Tutorial an.

Anforderungen

Diese Rolle hat die gleichen Abhängigkeiten wie das git-Modul. Zusätzlich werden pip und Python virtualenv benötigt. Diese können einfach über einen Pre-Task im selben Play wie diese Rolle installiert werden:

- hosts: galaxyservers
  pre_tasks:
    - name: Installiere Abhängigkeiten
      apt:
        name: "{{ item }}"
      become: yes
      when: ansible_os_family == 'Debian'
      with_items:
        - git
        - python-pip
        - python-virtualenv
    - name: Installiere Abhängigkeiten
      yum:
        name: "{{ item }}"
      become: yes
      when: ansible_os_family == 'RedHat'
      with_items:
        - git
        - python-virtualenv
  roles:
    - galaxyproject.galaxy

Wenn sich dein git-Ausführungsprogramm nicht im $PATH befindet, kannst du seinen Speicherort mit der Variable git_executable angeben. Gleiches gilt für das virtualenv-Ausführungsprogramm und die entsprechende Variable galaxy_virtualenv_command.

Rollenvariablen

Nicht alle Variablen sind aufgeführt oder im Detail erklärt. Für zusätzliche Informationen über weniger häufig verwendete Variablen siehe die Defaults-Datei.

Viele Variablen steuern, wo spezifische Dateien platziert werden und wo Galaxy Daten schreibt. Um die Konfiguration zu vereinfachen, kannst du ein Layout mit der Variable galaxy_layout auswählen. Welches Layout du wählst, beeinflusst die erforderlichen Variablen.

Erforderliche Variablen

Wenn ein anderes Layout als root-dir verwendet wird:

galaxy_server_dir: Dateisystempfad, wo der Galaxy Server Code installiert (kloniert) wird.

Wenn root-dir verwendet wird:

galaxy_root: Dateisystempfad zum Root-Verzeichnis einer Galaxy-Installation, der Code des Galaxy Servers wird in ein Unterverzeichnis dieses Verzeichnisses installiert.

Optionale Variablen

Die Option galaxy_config_perms steuert die Berechtigungen, die für Galaxy-Konfigurationsdateien festgelegt werden. Diese Option wurde in Version 0.9.18 der Rolle hinzugefügt und der Standardwert ist 0640 (Benutzer Lese- und Schreibrechte, Gruppe nur Leserechte, andere Benutzer haben keine Berechtigungen). In älteren Versionen kontrollierte die Rolle nicht die Berechtigungen von Konfigurationsdateien, sei dir daher bewusst, dass sich die Berechtigungen deiner Konfigurationsdateien ab Version 0.9.18 und später ändern können.

Layoutsteuerung

galaxy_layout: Verfügbare Layouts sind im vars/ Unterverzeichnis zu finden, mögliche Werte sind:
- root-dir: Alles ist in Unterverzeichnissen unter einem einzigen Root-Verzeichnis angeordnet.
- opt: Ein FHS-konformes Layout über mehrere Verzeichnisse wie /opt, /etc/opt, usw.
- legacy-improved: Alles befindet sich unter dem Galaxy Serververzeichnis, wie bei run.sh.
- legacy: Das Standardlayout vor der Existenz von galaxy_layout und derzeit das Standardlayout, um bestehende Verwendungen dieser Rolle nicht zu brechen.
- custom: Angemessene Standardeinstellungen für benutzerdefinierte Layouts, erfordert das Setzen einiger Variablen wie in vars/layout-custom.yml beschrieben.

Für neue Galaxy-Installationen wird entweder das Layout root-dir oder opt empfohlen.

Optionen, die die Platzierung einzelner Dateien oder Unterverzeichnisse steuern, können weiterhin die Vorgaben des Layouts überschreiben.

Prozesssteuerung mit Gravity

Die Rolle kann den Galaxy-Dienst mit gravity verwalten. Dies ist die Standardmethode für Galaxy 22.05 und später. Außerdem wurde die Unterstützung für die Variable galaxy_restart_handler_name entfernt. Wenn du deinen eigenen benutzerdefinierten Neustart-Handler aktivieren musst, kannst du die Option "listen" für den Handler wie in der Handler-Dokumentation erklärt verwenden. Der Handler sollte auf das Thema "restart galaxy" "lauschen".

Galaxy-Themen

Seit Version 22.01 können Galaxy-Nutzer zwischen verschiedenen UI Themen wählen. Du kannst Themen mithilfe der Variable galaxy_themes definieren, wobei die Syntax derselben wie die der Datei themes_conf.yml ist, die im Themen-Training beschrieben ist.

Die Variable galaxy_manage_themes steuert, ob die Rolle die Themenkonfiguration verwaltet und wird automatisch aktiviert, wenn galaxy_themes definiert ist. Wenn du nur die Beispieldateien von Galaxys themes_conf.yml.sample laden möchtest, ohne deine eigenen zu definieren, kannst du galaxy_manage_themes manuell auf true setzen.

Galaxy-Subdomains

Seit Version 22.01 kann Galaxy verschiedene statische Inhalte und Themen pro Host (z.B. Subdomain) bereitstellen.

Durch das Setzen von galaxy_manage_subdomain_static: yes aktivierst du das Erstellen von statischen Verzeichnissen und Konfigurationen pro Host.

Um diese Funktion zu nutzen, musst du die folgende Verzeichnisstruktur unter Dateien/ (konfigurierbar mit der Variable galaxy_themes_ansible_file_path) erstellen:

files/galaxy/static
├──<subdomain-name-1>
│   └── static
│       ├── dist (optional)
│       │   └── some-image.png
│       ├── images (optional)
│       │   └── more-content.jpg
│       └── welcome.html (optional, galaxyproject.org wird andernfalls angezeigt.)
├── <subdomain-name-2>                            
│   └── static
│       ├── dist (optional)
│       │   ├── another-static-image.svg
│       │   └── more-static-content-2.svg
│       └── welcome.html (optional)
... (und viele weitere Subdomains)

Dabei sollte der genau mit dem Namen deiner Subdomain übereinstimmen. Das Unterverzeichnis static ist verpflichtend, während alle Unterverzeichnisse in static optional sind. Welche Unterverzeichnisse und Dateien kopiert werden, wird durch die Variable static_galaxy_themes_keys verwaltet.

Stelle sicher, dass du auch galaxy_themes_welcome_url_prefix festlegst, damit deine Willkommensseiten korrekt gerendert werden.

Es ist zwingend erforderlich, die Variablen unter galaxy_themes_subdomains so zu setzen, wie im Beispiel in defaults/main.yml gezeigt. Wenn du die Variable galaxy_manage_host_filters aktiviert hast, kannst du auch die Werkzeugsektionen angeben, die für jede einzelne Subdomain angezeigt werden sollen.

Jede Subdomain kann ihr eigenes Thema haben, das unter dem Schlüssel theme des Eintrags der Subdomain in galaxy_themes_subdomains definiert wird. Dieses Thema wird das Standardthema für die Subdomain, und alle anderen Themen, die global für den Server definiert sind, stehen ebenfalls für die Benutzer zur Auswahl. Wenn das Thema einer Subdomain nicht definiert ist, wird das globale Standardthema verwendet. Ein Beispiel ist in defaults/main.yml enthalten.

Funktionssteuerung

Mehrere Variablen steuern, welche Funktionen diese Rolle ausführt (alle standardmäßig auf yes, es sei denn, es ist anders angegeben):

galaxy_create_user (Standard: no): Erstelle den Galaxy-Benutzer. Die Ausführung als dedizierter Benutzer ist eine bewährte Methode, aber die meisten Produktionsgalaxy-Instanzen, die Jobs an einen Cluster übermitteln, verwalten Benutzer in einem Verzeichnisdienst (z.B. LDAP). Diese Option ist nützlich für Standalone-Server. Benötigt Superuser-Rechte.
galaxy_manage_paths (Standard: no): Erstelle und verwalte Besitz/Berechtigungen für konfigurierte Galaxy-Pfade. Benötigt Superuser-Rechte.
galaxy_manage_clone: Klone Galaxy aus dem Quell-Repository und halte es auf einer spezifischen Version (Commit) sowie richte ein [virtualenv][virtualenv] ein, von dem aus es ausgeführt werden kann.
galaxy_manage_download: Lade Galaxy von einer externen Archiv-URL herunter und entpacke es, sowie richte ein [virtualenv][virtualenv] ein, von dem aus es ausgeführt werden kann.
galaxy_manage_existing: Übernehme ein bereits vorhandenes Galaxy-Verzeichnis und richte ein [virtualenv][virtualenv] ein, von dem aus es ausgeführt werden kann. galaxy_server_dir muss auf den Pfad verweisen, der bereits den Quellcode von Galaxy enthält.
galaxy_manage_static_setup: Verwaltet "statische" Galaxy-Konfigurationsdateien - solche, die vom Galaxy-Server selbst nicht modifiziert werden können. Mindestanforderung ist die primäre Galaxy-Konfigurationsdatei galaxy.ini.
galaxy_manage_mutable_setup: Verwaltet "veränderliche" Galaxy-Konfigurationsdateien - solche, die vom Galaxy (z.B. beim Installieren von Tools aus dem Galaxy Tool Shed) modifiziert werden können.
galaxy_manage_database: Aktualisiere das Datenbankschema nach Bedarf, wenn neue Schema-Versionen verfügbar sind.
galaxy_fetch_dependencies: Beschaffe Galaxy-abhängige Module für das Galaxy-virtualenv.
galaxy_build_client: Baue die Galaxy-Clientanwendung (Web-UI).
galaxy_client_make_target (Standard: client-production-maps): Setze den Typ des Client-Builds. Optionen sind: client, client-production und client-production-maps. Siehe Galaxy Client Readme für Details.
galaxy_manage_systemd (Standard: no): Installiere ein systemd Dienstmodul, um Galaxy mit dem System zu starten und zu stoppen (und den systemctl Befehl zu verwenden).
galaxy_manage_errordocs (Standard: no): Installiere Galaxy-stilisierte 413 und 502 HTTP-Fehlerdokumente für nginx. Benötigt Schreibrechte für das nginx-Fehlerdokumentverzeichnis.
galaxy_manage_cleanup (Standard: no): Installiere einen Cron-Job, um temporäre Dateien des Galaxy-Frameworks und der Jobausführung zu bereinigen. Benötigt tmpwatch(8) auf RedHat-basierten Systemen oder tmpreaper(8) auf Debian-basierten Systemen. Siehe die Variablen galaxy_tmpclean_* in der Defaults-Datei für Details.

Galaxy-Code und -Konfiguration

Optionen zur Konfiguration von Galaxy und zur Steuerung, welche Version installiert wird.

galaxy_config: Die Inhalte der Galaxy-Konfigurationsdatei (galaxy.ini standardmäßig) werden durch diese Variable gesteuert. Es handelt sich um einen Hash von Hashes (oder Wörterbuchern), der in die Konfigurationsdatei übersetzt wird. Siehe die Beispiel-Playbooks unten für die Verwendung.
galaxy_config_files: Liste von Hashes (mit src und dest Schlüsseln) von Dateien, die vom Steuerungsrechner kopiert werden sollen. Zum Beispiel, um Jobziele festzulegen, kannst du die Variable galaxy_config_dir gefolgt vom Dateinamen als dest verwenden, z.B. dest: "{{ galaxy_config_dir }}/job_conf.xml". Stelle sicher, dass du die entsprechende Einrichtung innerhalb von galaxy_config für jede hier hinzugefügte Datei hinzufügst (also, wenn du job_conf.xml hinzufügst, stelle sicher, dass galaxy_config.galaxy.job_config_file auf diese Datei verweist).
galaxy_config_templates: Liste von Hashes (mit src und dest Schlüsseln) von Vorlagen, die vom Steuerungsrechner ausgefüllt werden sollen.
galaxy_local_tools: Liste von lokalen Tooldateien oder -verzeichnissen, die relativ zum galaxy_local_tools_src_dir (standardmäßig files/galaxy/tools im Playbook) kopiert werden sollen. Die Listenelemente können entweder ein Tooldateiname oder ein Wörterbuch mit den Schlüsseln file, section_name und optional section_id sein. Wenn kein section_name angegeben ist, werden die Tools in einer Sektion namens Local Tools platziert.
galaxy_local_tools_dir: Verzeichnis auf dem Galaxy-Server, in dem lokale Tools installiert werden.
galaxy_dynamic_job_rules: Liste von dynamischen Jobregeln, die relativ zu galaxy_dynamic_job_rules_src_dir (standardmäßig files/galaxy/dynamic_job_rules im Playbook) kopiert werden sollen.
galaxy_dynamic_job_rules_dir (standardmäßig: {{ galaxy_server_dir }}/lib/galaxy/jobs/rules): Verzeichnis auf dem Galaxy-Server, in dem die dynamischen Jobregeln installiert werden. Wenn vom Standard abgewichen wird, stelle sicher, dass das Verzeichnis im $PYTHONPATH von Galaxy vorhanden ist (z.B. in {{ galaxy_venv_dir }}/lib/python2.7/site-packages) und konfiguriere das Plugin für dynamische Regeln entsprechend in job_conf.xml.
galaxy_repo (Standard: https://github.com/galaxyproject/galaxy.git): Das Upstream-Git-Repository, aus dem Galaxy geklont werden soll.
galaxy_commit_id (Standard: master): Eine Commit-ID, Tag, Branch oder ein anderer gültiger Git-Referenz, auf die Galaxy aktualisiert werden soll. Das Angabe eines Branchs aktualisiert auf den neuesten Commit dieses Branchs. Die Verwendung einer echten Commit-ID ist der einzige Weg, um Galaxy auf einer spezifischen Version explizit zu sperren.
galaxy_force_checkout (Standard: no): Wenn yes, werden alle modifizierten Dateien im Galaxy-Repository verworfen.
galaxy_clone_depth (Standard: nicht gesetzt): Tiefe, die beim Ausführen des Git-Klons verwendet werden soll. Unbestimmt lassen, um die gesamte Historie zu klonen.

Zusätzliche Konfigurationsdateien

Einige optionale Konfigurationsdateien, die häufig auf Produktions-Galaxy-Servern verwendet werden, können über Variablen konfiguriert werden:

galaxy_dependency_resolvers: Fülle die Datei dependency_resolvers_conf.yml. Siehe die Beispiel-XML-Konfiguration für Optionen.
galaxy_container_resolvers: Fülle die Datei container_resolvers_conf.yml. Siehe die Beispiel-XML-Konfiguration für Optionen.
galaxy_job_metrics_plugins: Fülle die Datei job_metrics_conf.yml. Siehe die Beispiel-XML-Konfiguration für Optionen.

Ab Galaxy 21.05 befinden sich die Beispielkonfigurationsdateien für diese Funktionen im XML-Format, aber YAML wird auch unterstützt:

galaxy_dependency_resolvers:
  - type: <XML tag name>
    <XML attribute name>: <XML attribute value>

Beispiel:

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

Pfade konfigurieren

Optionen zur Steuerung, wo bestimmte Galaxy-Komponenten auf dem Dateisystem platziert werden.

galaxy_venv_dir (Standard: <galaxy_server_dir>/.venv): Die Rolle erstellt ein [virtualenv][virtualenv], von dem aus Galaxy gestartet wird, dies steuert, wo das virtualenv platziert wird.
galaxy_virtualenv_command: (Standard: virtualenv): Der Befehl, der zum Erstellen von Galaxys virtualenv verwendet wird. Setze dies auf pyvenv, um Python 3 in Galaxy >= 20.01 zu verwenden.
galaxy_virtualenv_python: (Standard: Python der ersten virtualenv oder python-Befehls in $PATH): Der Python-Binary, der zum Erstellen des virtualenv verwendet werden soll. Für Galaxy < 20.01, verwende python2.7 (falls nicht der Standard), für Galaxy >= 20.01, verwende python3.5 oder höher.
galaxy_config_dir (Standard: <galaxy_server_dir>): Verzeichnis, das für "statische" Konfigurationsdateien verwendet wird.
galaxy_mutable_config_dir (Standard: <galaxy_server_dir>): Verzeichnis, das für "veränderliche" Konfigurationsdateien verwendet wird, muss beschreibbar sein von dem Benutzer, der Galaxy ausführt.
galaxy_mutable_data_dir (Standard: <galaxy_server_dir>/database): Verzeichnis, das für "veränderliche" Daten und Caches verwendet wird, muss beschreibbar sein von dem Benutzer, der Galaxy ausführt.
galaxy_config_file (Standard: <galaxy_config_dir>/galaxy.ini): Die primäre Konfigurationsdatei von Galaxy.

Benutzermanagement und Trennung der Berechtigungen

galaxy_separate_privileges (Standard: no): Aktiviert den Modus zur Trennung der Berechtigungen.
galaxy_user (Standard: Benutzer, der Ansible ausführt): Der Name des Systembenutzers, unter dem Galaxy läuft.
galaxy_privsep_user (Standard: root): Der Name des Systembenutzers, der den Galaxy-Code, die Konfigurationsdateien und das virtualenv (und die darin vorhandenen Abhängigkeiten) besitzt.
galaxy_group: Gemeinsame Gruppe zwischen dem Galaxy-Benutzer und dem Benutzer mit separierten Berechtigungen. Wenn dies gesetzt ist und galaxy_manage_paths aktiviert ist, werden Verzeichnisse, die potenziell sensible Informationen wie die Galaxy-Konfigurationsdatei enthalten, erstellt, die für die Gruppe, aber nicht für die Welt lesbar sind. Andernfalls werden Verzeichnisse als weltweit lesbar erstellt.

Zugriffsmethodensteuerung

Die Rolle muss Aufgaben als verschiedene Benutzer ausführen, abhängig von den aktivierten Funktionen und wie du dich mit dem Zielhost verbindest. Standardmäßig verwendet die Rolle become (d.h. sudo), um Aufgaben bei Bedarf als den entsprechenden Benutzer auszuführen. Das Überschreiben dieses Verhaltens wird in der Defaults-Datei besprochen.

Systemd

systemd ist der Standard-System-Init-Daemon auf den meisten modernen Linux-Varianten (und allen, die von dieser Rolle unterstützt werden). Wenn galaxy_manage_systemd aktiviert ist, wird ein galaxy-Dienst in systemd konfiguriert, um Galaxy auszuführen. Dieser Dienst wird automatisch gestartet und so konfiguriert, dass er beim Booten deines Systems startet. Du kannst den Galaxy-Dienst mit dem Dienstprogramm systemctl als root-Benutzer oder mit sudo steuern:

# systemctl start galaxy     # galaxy starten
# systemctl reload galaxy    # einen "sanften" Reload versuchen
# systemctl restart galaxy   # einen harten Neustart durchführen
# systemctl stop galaxy      # galaxy stoppen

Du kannst den systemd-Benutzermodus verwenden, wenn du keine Root-Rechte auf deinem System hast, indem du galaxy_systemd_root auf false setzt. Füge bei den obigen systemctl-Befehlen --user hinzu, um in Benutzermodus mit systemd zu interagieren.

Fehlerdokumente

galaxy_errordocs_dir: Installiere Galaxy-stilisierte HTTP 413 und 502 Fehlerdokumente in diesem Verzeichnis. Die 502-Nachricht verwendet nginx-Server-Seiteneinfügungen, um Administratoren zu ermöglichen, eine benutzerdefinierte Nachricht in ~/maint zu erstellen, wenn Galaxy ausgefallen ist. Nginx muss separat konfiguriert werden, um diese Fehlerdokumente bereitzustellen.
galaxy_errordocs_server_name (Standard: Galaxy): Wird verwendet, um die Nachricht "galaxy_errdocs_server_name kann nicht erreicht werden" auf der 502-Seite anzuzeigen.
galaxy_errordocs_prefix (Standard: /error): Webseitiger Pfad zum Fehlerdokumentenstamm.

Verschiedene Optionen

galaxy_admin_email_to: Wenn gesetzt, wird diese Adresse per E-Mail benachrichtigt, wenn Galaxy aktualisiert wurde. Setzt voraus, dass die E-Mail auf dem verwalteten Host ordnungsgemäß konfiguriert ist.
galaxy_admin_email_from: Adresse, von der die oben genannte E-Mail gesendet wird.

Abhängigkeiten

Keine

Beispiel-Playbook

Grundlegend

Installiere Galaxy auf deinem lokalen System mit allen Standardoptionen:

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

Wenn deine Ansible-Version >= 2.10.4 ist, dann solltest du beim Ausführen von ansible-playbook playbook.yml ein zusätzliches Argument -u $USER angeben, andernfalls erhältst du einen Fehler.

Nach der Installation kannst du mit folgendem beginnen:

$ cd /srv/galaxy
$ sh run.sh

Beste Praktiken

Installiere Galaxy gemäß den aktuellen Best Practices für Produktionsserver:

Der Galaxy-Code (Klon) ist "sauber": keine Konfigurationen oder veränderlichen Daten leben unter dem Klon.
Der Galaxy-Code und die statischen Konfigurationen sind berechtigungsgetrennt: nicht im Besitz/schreibbar von dem Benutzer, der Galaxy ausführt.
Konfigurationsdateien sind nicht weltweit lesbar.
PostgreSQL wird als zugrunde liegende Datenbank verwendet.
Der YAML-Konfigurationstyp 18.01+ wird verwendet.
Zwei Job-Handler-Mules werden gestartet.
Wenn der Galaxy-Code oder die Konfigurationen von Ansible aktualisiert werden, wird Galaxy mit galaxyctl oder systemctl restart galaxy-* neu gestartet.

- 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_name }}"
        virtualenv: "{{ galaxy_venv_dir }}"
        gunicorn:
          # Listening-Optionen
          bind: "unix:{{ galaxy_mutable_config_dir }}/gunicorn.sock"
          # Leistungsoptionen
          workers: 2
          # Andere Optionen, die an gunicorn übergeben werden
          # Dies erlaubt das Setzen von 'sicheren' Headern wie REMOTE_USER (und ähnliches)
          # https://docs.gunicorn.org/en/stable/settings.html#forwarded-allow-ips
          extra_args: '--forwarded-allow-ips="*"'
          # Dies lässt Gunicorn Galaxy vollständig starten, bevor es forked, was schneller ist.
          # 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: Installiere Abhängigkeiten
      apt:
        name:
          - sudo
          - git
          - make
          - python3-venv
          - python3-setuptools
          - python3-dev
          - python3-psycopg2
          - gcc
          - acl
          - gnutls-bin
          - libmagic-dev
      become: yes
  roles:
    # Installieren mit:
    #   % ansible-galaxy install galaxyproject.postgresql
    - role: galaxyproject.postgresql
      become: yes
    # Installieren mit:
    #   % ansible-galaxy install natefoo.postgresql_objects
    - role: galaxyproject.postgresql_objects
      become: yes
      become_user: postgres
    - role: galaxyproject.galaxy