mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-10-29 17:42:12 +08:00
Add Migrating from uWSGI to Gunicorn and FastAPI document
This commit is contained in:
@@ -24,3 +24,4 @@ This documentation is in the midst of being ported and unified based on resource
|
||||
reports
|
||||
useful_scripts
|
||||
options
|
||||
migrating_to_gunicorn
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Migrating from uWSGI to Gunicorn and FastAPI
|
||||
|
||||
## Why do we migrate away from uWSGI
|
||||
|
||||
Starting with Galaxy release 22.01 the default application webserver is [Gunicorn](https://gunicorn.org/), which replaces [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/).
|
||||
We have made this move because uWSGI support for newer Python versions has been problematic and because
|
||||
we have modernized the API portion of our backend. The Galaxy web application is now an ASGI application
|
||||
driven by [FastAPI](https://fastapi.tiangolo.com/) and [Starlette](https://www.starlette.io/).
|
||||
This will enable numerous important features in the future that would not be possible (or more complicated to set up)
|
||||
otherwise. Importantly [FastAPI's documentation](https://fastapi.tiangolo.com/tutorial/) is very good and
|
||||
should increase developer productivity.
|
||||
|
||||
The main advantage for our Users today is that Galaxy hosts documentation for its API as an [OpenAPI](https://www.openapis.org/)
|
||||
document that is directly generated from Galaxy's source code, and so will never be out of date or differ
|
||||
from the actual Implementation.
|
||||
Note that not all API endpoints have been modernized as of yet, this is an ongoing process.
|
||||
|
||||
To see the API documentation for your Galaxy server you can go to `<galaxy_url>/api/docs`.
|
||||
Another immediate advantage is that all incoming Parameters are validated against a [Pydantic](https://pydantic-docs.helpmanual.io/) Schema.
|
||||
This will lead to fewer subtle bugs and make it easier to interface with Galaxy's API.
|
||||
|
||||
In the future we are going to use Websockets and asynchronous programming to increase the reactivity
|
||||
of history events in Galaxy. This would not be as simple under uWSGI.
|
||||
|
||||
## How do I upgrade my instance to use Gunicorn
|
||||
|
||||
If you are using `run.sh` to start Galaxy and have not set up job handling via uWSGI mules
|
||||
you do not need to do anything to start Galaxy under Gunicorn.
|
||||
|
||||
If you are using uwSGI mules please read the [Scaling and Load Balancing Documentation](scaling.md).
|
||||
You will most likely want to set up the **Gunicorn + Webless** strategy.
|
||||
|
||||
If you are using an upstream proxy server such as NGINX or Apache and you've been
|
||||
using the the uWSGI protocol you need to replace `uwsgi_pass` and `mod_proxy_uwsgi`.
|
||||
You can find detailed documentation in the [NGINX](nginx.md) and [Apache](apache.md)
|
||||
documentation.
|
||||
|
||||
If you are managing your Galaxy server via Ansible you can continue to run Galaxy
|
||||
under uWSGI while we are working on updating the Ansible roles for installing Galaxy.
|
||||
We will update instructions here and on the [Galaxy Training Network](https://training.galaxyproject.org/).
|
||||
|
||||
If you are starting Web and Job Handlers using an external Process manager like
|
||||
systemd or supervisor please read the [Scaling and Load Balancing Documentation](scaling.md).
|
||||
As mentioned in the scaling documentation, you can use gravity to generate supervisor configuration files
|
||||
that you can either use directly or as a basis to update your existing configuration.
|
||||
Reference in New Issue
Block a user