galaxyproject.galaxy

Descripción general Versiones Perspectivas

Galaxy

Un rol de Ansible para instalar y gestionar servidores de Galaxy. A pesar de la confusión de nombres, Galaxy no tiene relación con Ansible Galaxy.

¿Quieres empezar con este módulo? Echa un vistazo a nuestro Tutorial

Requisitos

Este rol tiene las mismas dependencias que el módulo git. Además, se requieren pip y Python virtualenv. Estos pueden instalarse fácilmente mediante una tarea previa en el mismo play que este rol:

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

Si tu ejecutable de git no está en $PATH, puedes especificar su ubicación con la variable git_executable. De igual manera, se aplica a la variable galaxy_virtualenv_command para el ejecutable de virtualenv.

Variables del rol

No todas las variables están listadas o explicadas en detalle. Para más información sobre variables menos comúnmente utilizadas, consulta el archivo de defaults.

Muchas variables controlan dónde se colocan archivos específicos y dónde Galaxy escribe datos. Para simplificar la configuración, puedes seleccionar un layout con la variable galaxy_layout. El layout que elijas afecta a las variables requeridas.

Variables requeridas

Si usas un layout diferente a root-dir:

galaxy_server_dir: Ruta del sistema de archivos donde se instalará el código del servidor Galaxy (clonado).

Si usas root-dir:

galaxy_root: Ruta del sistema de archivos de la raíz de un despliegue de Galaxy, el código del servidor Galaxy se instalará en un subdirectorio de este directorio.

Variables opcionales

La opción galaxy_config_perms controla los permisos a los que se establecerán los archivos de configuración de Galaxy. Esta opción se ha añadido en la versión 0.9.18 del rol y el valor predeterminado es 0640 (usuario lectura-escritura, grupo solo lectura, otros usuarios sin permisos). En versiones anteriores, el rol no controlaba los permisos de los archivos de configuración, así que ten en cuenta que los permisos de tu archivo de configuración pueden cambiar a partir de la versión 0.9.18 y posteriores.

Control de layout

galaxy_layout: los layouts disponibles se pueden encontrar en el subdirectorio vars/ y los valores posibles incluyen:
- root-dir: Todo está organizado en subdirectorios debajo de un único directorio raíz.
- opt: Un layout conforme a FHS en múltiples directorios como /opt, /etc/opt, etc.
- legacy-improved: Todo debajo del directorio del servidor Galaxy, como con run.sh.
- legacy: El layout predeterminado antes de la existencia de galaxy_layout y actualmente el predeterminado para no romper el uso existente de este rol.
- custom: Valores razonables para layouts personalizados, requiere configurar algunas variables como se describe en vars/layout-custom.yml.

Se recomienda utilizar el layout root-dir o opt para nuevas implementaciones de Galaxy.

Las opciones a continuación que controlan la ubicación de archivos o subdirectorios individuales aún pueden sobrescribir los valores predeterminados establecidos por el layout.

Control de procesos con Gravity

El rol puede gestionar el servicio de Galaxy utilizando gravity. Este es el valor predeterminado para Galaxy 22.05 y posteriores. Además, se ha eliminado el soporte para la variable galaxy_restart_handler_name. Si necesitas habilitar tu propio manejador de reinicio personalizado, puedes utilizar la opción "listen" del manejador, como se explica en la documentación del manejador. El manejador debe "escuchar" el tema "restart galaxy".

Temas de Galaxy

Desde la versión 22.01, los usuarios de Galaxy pueden seleccionar entre diferentes temas de interfaz. Puedes definir los temas utilizando la variable galaxy_themes, cuya sintaxis es la misma que el archivo themes_conf.yml descrito en el entrenamiento de temas.

La variable galaxy_manage_themes controla si el rol gestiona las configuraciones de temas y se habilita automáticamente si galaxy_themes está definida. Si solo quieres cargar los temas de ejemplo desde el themes_conf.yml.sample de Galaxy sin definir los tuyos, puedes establecer manualmente galaxy_manage_themes en true.

Subdominios de Galaxy

Desde la versión 22.01, Galaxy puede servir diferentes contenidos estáticos y temas por host (por ejemplo, subdominio).

Al establecer galaxy_manage_subdomain_static: yes, habilitas la creación de directorios estáticos y configuraciones por host.

Para usar esta opción, necesitas crear la siguiente estructura de directorios en files/ (personalizable con la variable galaxy_themes_ansible_file_path):

files/galaxy/static
├──<nombre-de-subdominio-1>
│   └── static
│       ├── dist (opcional)
│       │   └── some-image.png
│       ├── images (opcional)
│       │   └── more-content.jpg
│       └── welcome.html (opcional, de lo contrario se mostrará galaxyproject.org.)
├── <nombre-de-subdominio-2>                            
│   └── static
│       ├── dist (opcional)
│       │   ├── another-static-image.svg
│       │   └── more-static-content-2.svg
│       └── welcome.html (opcional)
... (y muchos más subdominios)

Donde debe coincidir exactamente con el nombre de tu subdominio. El subdirectorio static es obligatorio, mientras que todos los subdirectorios en static son opcionales. Qué subdirectorios y archivos se copian es gestionado por la variable static_galaxy_themes_keys.

También asegúrate de establecer galaxy_themes_welcome_url_prefix, para que tus páginas de bienvenida sean correctamente plantillas.

Es obligatorio establecer las variables bajo galaxy_themes_subdomains como se muestra en el ejemplo en defaults/main.yml. Si habilitaste la variable galaxy_manage_host_filters, también puedes especificar las secciones de herramientas que deberían mostrarse para cada subdominio individual.

Cada subdominio puede tener su propio tema, que se define bajo la clave theme de la entrada del subdominio en galaxy_themes_subdomains. Este tema será el predeterminado para el subdominio, y cualquier otro tema definido globalmente para el servidor también estará disponible para que el usuario lo seleccione. Si el theme de un subdominio no está definido, se usa el valor predeterminado global. Se proporciona un ejemplo en defaults/main.yml.

Control de funciones

Varias variables controlan qué funciones realizará este rol (todas predeterminan a yes excepto donde se anota):

galaxy_create_user (predeterminado: no): Crear el usuario Galaxy. Ejecutar como un usuario dedicado es una buena práctica, pero la mayoría de las instancias de Galaxy en producción que envían trabajos a un clúster administrarán usuarios en un servicio de directorio (por ejemplo, LDAP). Esta opción es útil para servidores independientes. Requiere privilegios de superusuario.
galaxy_manage_paths (predeterminado: no): Crear y gestionar la propiedad/permisos de los caminos configurados de Galaxy. Requiere privilegios de superusuario.
galaxy_manage_clone: Clonar Galaxy del repositorio fuente y mantenerlo en una versión específica (commit), así como configurar un [virtualenv][virtualenv] desde el cual puede ejecutarse.
galaxy_manage_download: Descargar y descomprimir Galaxy desde una URL de archivo remoto, así como configurar un [virtualenv][virtualenv] desde el cual puede ejecutarse.
galaxy_manage_existing: Tomar posesión de un directorio Galaxy que ya existe, así como configurar un [virtualenv][virtualenv] desde el cual puede ejecutarse. galaxy_server_dir debe apuntar a la ruta que ya contiene el código fuente de Galaxy.
galaxy_manage_static_setup: Gestionar archivos de configuración "estáticos" de Galaxy, aquellos que no pueden ser modificados por el propio servidor Galaxy. Como mínimo, este es el archivo de configuración principal de Galaxy, galaxy.ini.
galaxy_manage_mutable_setup: Gestionar archivos de configuración "mutables" de Galaxy, aquellos que pueden ser modificados por Galaxy (por ejemplo, a medida que se instalan herramientas desde el Galaxy Tool Shed).
galaxy_manage_database: Actualizar el esquema de la base de datos según sea necesario, cuando se disponga de nuevas versiones del esquema.
galaxy_fetch_dependencies: Obtener módulos dependientes de Galaxy al virtualenv de Galaxy.
galaxy_build_client: Construir la aplicación cliente de Galaxy (interfaz web).
galaxy_client_make_target (predeterminado: client-production-maps): Establecer el tipo de compilación del cliente. Las opciones incluyen: client, client-production y client-production-maps. Consulta el readme del cliente de Galaxy para más detalles.
galaxy_manage_systemd (predeterminado: no): Instalar una unidad de servicio systemd para iniciar y detener Galaxy con el sistema (y usando el comando systemctl).
galaxy_manage_errordocs (predeterminado: no): Instalar documentos de error HTTP 413 y 502 con estilo Galaxy para nginx. Requiere privilegios de escritura para el directorio de documentos de error de nginx.
galaxy_manage_cleanup (predeterminado: no): Instalar un trabajo cron para limpiar el marco de trabajo de Galaxy y archivos temporales de ejecución de trabajos. Requiere tmpwatch(8) en sistemas basados en RedHat o tmpreaper(8) en sistemas basados en Debian. Consulta las variables galaxy_tmpclean_* en el archivo de defaults para más detalles.

Código y configuración de Galaxy

Opciones para configurar Galaxy y controlar qué versión se instala.

galaxy_config: Los contenidos del archivo de configuración de Galaxy (galaxy.ini por defecto) son controlados por esta variable. Es un hash de hashes (o diccionarios) que se traducirán en el archivo de configuración. Consulta los ejemplos de Playbooks a continuación para su uso.
galaxy_config_files: Lista de hashes (con claves src y dest) de archivos a copiar desde la máquina de control. Por ejemplo, para establecer destinos de trabajos, puedes usar la variable galaxy_config_dir seguida del nombre del archivo como dest, por ejemplo, dest: "{{ galaxy_config_dir }}/job_conf.xml". Asegúrate de agregar la configuración apropiada dentro de galaxy_config para cada archivo agregado aquí (así que, si agregas job_conf.xml asegúrate de que galaxy_config.galaxy.job_config_file apunte a ese archivo).
galaxy_config_templates: Lista de hashes (con claves src y dest) de plantillas a llenar desde la máquina de control.
galaxy_local_tools: Lista de archivos o directorios de herramientas locales a copiar desde la máquina de control, relativa a galaxy_local_tools_src_dir (predeterminado: files/galaxy/tools en el playbook). Los elementos de la lista pueden ser un nombre de archivo de herramienta, o un diccionario con claves file, section_name, y, opcionalmente, section_id. Si no se especifica section_name, las herramientas se colocarán en una sección llamada Local Tools.
galaxy_local_tools_dir: Directorio en el servidor Galaxy donde se instalarán las herramientas locales.
galaxy_dynamic_job_rules: Lista de reglas de trabajos dinámicas a copiar desde la máquina de control, relativa a galaxy_dynamic_job_rules_src_dir (predeterminado: files/galaxy/dynamic_job_rules en el playbook).
galaxy_dynamic_job_rules_dir (predeterminado: {{ galaxy_server_dir }}/lib/galaxy/jobs/rules): Directorio en el servidor Galaxy donde se instalarán las reglas de trabajos dinámicas. Si se cambia del valor predeterminado, asegúrate de que el directorio esté en el $PYTHONPATH de Galaxy (por ejemplo, en {{ galaxy_venv_dir }}/lib/python2.7/site-packages) y configura el plugin de reglas dinámicas en job_conf.xml en consecuencia.
galaxy_repo (predeterminado: https://github.com/galaxyproject/galaxy.git): Repositorio Git upstream desde el cual se debe clonar Galaxy.
galaxy_commit_id (predeterminado: master): Un id de commit, etiqueta, rama u otra referencia válida de Git a la que Galaxy debe actualizarse. Especificar una rama actualizará al último commit de esa rama. Usar un id de commit real es la única forma de bloquear Galaxy en una versión específica de forma explícita.
galaxy_force_checkout (predeterminado: no): Si es yes, se descartarán los archivos modificados en el repositorio de Galaxy.
galaxy_clone_depth (predeterminado: no establecido): Profundidad a utilizar al realizar git clone. Deja sin especificar para clonar todo el historial.

Archivos de configuración adicionales

Algunos archivos de configuración opcionales comúnmente utilizados en servidores de producción de Galaxy pueden configurarse desde variables:

galaxy_dependency_resolvers: Completar el archivo dependency_resolvers_conf.yml. Consulta la configuración XML de muestra para opciones.
galaxy_container_resolvers: Completar el archivo container_resolvers_conf.yml. Consulta la configuración XML de muestra para opciones.
galaxy_job_metrics_plugins: Completar el archivo job_metrics_conf.yml. Consulta la configuración XML de muestra para opciones.

A partir de Galaxy 21.05, los archivos de configuración de muestra para estas características están en XML, pero se admite YAML así:

galaxy_dependency_resolvers:
  - type: <nombre de etiqueta XML>
    <nombre de atributo XML>: <valor de atributo XML>

Por ejemplo:

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

Configuración de rutas

Opciones para controlar dónde se colocan ciertos componentes de Galaxy en el sistema de archivos.

galaxy_venv_dir (predeterminado: <galaxy_server_dir>/.venv): El rol creará un [virtualenv][virtualenv] desde el cual se ejecutará Galaxy, esto controla dónde se colocará el virtualenv.
galaxy_virtualenv_command: (predeterminado: virtualenv): El comando utilizado para crear el virtualenv de Galaxy. Establecer en pyvenv para usar Python 3 en Galaxy >= 20.01.
galaxy_virtualenv_python: (predeterminado: python del primer comando virtualenv o python en $PATH): El binario de python a usar al crear el virtualenv. Para Galaxy < 20.01, usar python2.7 (si no es el predeterminado), para Galaxy >= 20.01, usar python3.5 o superior.
galaxy_config_dir (predeterminado: <galaxy_server_dir>): Directorio que se usará para archivos de configuración "estáticos".
galaxy_mutable_config_dir (predeterminado: <galaxy_server_dir>): Directorio que se usará para archivos de configuración "mutables", debe ser escribible por el usuario que ejecuta Galaxy.
galaxy_mutable_data_dir (predeterminado: <galaxy_server_dir>/database): Directorio que se usará para datos "mutables" y cachés, debe ser escribible por el usuario que ejecuta Galaxy.
galaxy_config_file (predeterminado: <galaxy_config_dir>/galaxy.ini): Archivo de configuración principal de Galaxy.

Gestión de usuarios y separación de privilegios

galaxy_separate_privileges (predeterminado: no): Habilitar el modo de separación de privilegios.
galaxy_user (predeterminado: usuario que ejecuta ansible): El nombre del usuario del sistema bajo el cual se ejecuta Galaxy.
galaxy_privsep_user (predeterminado: root): El nombre del usuario del sistema que posee el código, archivos de configuración y virtualenv de Galaxy (y dependencias en su interior).
galaxy_group: Grupo común entre el usuario Galaxy y el usuario de separación de privilegios. Si se establece y galaxy_manage_paths está habilitado, los directorios que contienen información potencialmente sensible como el archivo de configuración de Galaxy se crearán con permisos de lectura para el grupo, pero no para el mundo. De lo contrario, los directorios se crearán con permisos de lectura para el mundo.

Control del método de acceso

El rol necesita realizar tareas como diferentes usuarios dependiendo de las funciones que hayas habilitado y cómo te estás conectando al host de destino. Por defecto, el rol usará become (es decir, sudo) para realizar tareas como el usuario apropiado si se considera necesario. Se discute más sobre cómo sobrescribir este comportamiento en el archivo de defaults.

systemd

systemd es el demonio de inicio de sistema estándar en la mayoría de las distribuciones modernas de Linux (y en todas las que son admitidas por este rol). Si galaxy_manage_systemd está habilitado, se configurará un servicio galaxy en systemd para ejecutar Galaxy. Este servicio se iniciará automáticamente y se configurará para arrancar al iniciar tu sistema. Puedes controlar el servicio de Galaxy con la utilidad systemctl como usuario root o usando sudo:

# systemctl start galaxy     # iniciar galaxy
# systemctl reload galaxy    # intentar una recarga "suave"
# systemctl restart galaxy   # realizar un reinicio forzado
# systemctl stop galaxy      # detener galaxy

Puedes utilizar el modo usuario de systemd si no tienes privilegios de root en tu sistema estableciendo galaxy_systemd_root en false. Agrega --user a los comandos systemctl anteriores para interactuar con systemd en modo usuario:

Documentos de error

galaxy_errordocs_dir: Instalar documentos de error HTTP 413 y 502 con estilo Galaxy en este directorio. El mensaje de 502 utiliza las inclusiones del lado del servidor de nginx para permitir que los administradores crean un mensaje personalizado en ~/maint cuando Galaxy está fuera de servicio. nginx debe configurarse por separado para servir estos documentos de error.
galaxy_errordocs_server_name (predeterminado: Galaxy): usado para mostrar el mensaje "galaxy_errdocs_server_name no puede ser alcanzado" en la página 502.
galaxy_errordocs_prefix (predeterminado: /error): Ruta del lado web al directorio raíz de documentos de error.

Opciones varias

galaxy_admin_email_to: Si se establece, enviará un correo a esta dirección cuando Galaxy haya sido actualizado. Se asume que el correo está configurado correctamente en el host gestionado.
galaxy_admin_email_from: Dirección desde la cual se enviará el correo mencionado anteriormente.

Dependencias

Ninguna

Ejemplo de Playbook

Básico

Instalar Galaxy en tu sistema local con todas las opciones predeterminadas:

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

Si tu versión de Ansible es >= 2.10.4, cuando ejecutes ansible-playbook playbook.yml debes suministrar un argumento extra -u $USER, de lo contrario recibirás un error.

Una vez instalado, puedes comenzar con:

$ cd /srv/galaxy
$ sh run.sh

Mejores Prácticas

Instalar Galaxy según las mejores prácticas actuales para servidores de producción:

El código de Galaxy (clonado) es "limpio": no hay configuraciones o datos mutables debajo del clone.
El código de Galaxy y las configuraciones estáticas están separadas por privilegios: no son propiedad/escribibles por el usuario que ejecuta Galaxy.
Los archivos de configuración no son legibles por el mundo.
Se utiliza PostgreSQL como base de datos.
Se utiliza la configuración YAML al estilo 18.01+.
Se inician dos mules de manejadores de trabajos.
Cuando se actualiza el código o las configuraciones de Galaxy mediante Ansible, se reiniciará Galaxy utilizando galaxyctl o 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_name }}"
        virtualenv: "{{ galaxy_venv_dir }}"
        gunicorn:
          # opciones de escucha
          bind: "unix:{{ galaxy_mutable_config_dir }}/gunicorn.sock"
          # opciones de rendimiento
          workers: 2
          # Otras opciones que se pasarán a gunicorn
          # Esto permite configurar encabezados 'seguros' como REMOTE_USER (y similares)
          # https://docs.gunicorn.org/en/stable/settings.html#forwarded-allow-ips
          extra_args: '--forwarded-allow-ips="*"'
          # Esto permite que Gunicorn inicie Galaxy completamente antes de dividirlo, lo que es más rápido.
          # 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: Instalar Dependencias
      apt:
        name:
          - sudo
          - git
          - make
          - python3-venv
          - python3-setuptools
          - python3-dev
          - python3-psycopg2
          - gcc
          - acl
          - gnutls-bin
          - libmagic-dev
      become: yes
  roles:
    # Instalar con:
    #   % ansible-galaxy install galaxyproject.postgresql
    - role: galaxyproject.postgresql
      become: yes
    # Instalar con:
    #   % ansible-galaxy install natefoo.postgresql_objects
    - role: galaxyproject.postgresql_objects
      become: yes
      become_user: postgres
    - role: galaxyproject.galaxy