Add Migrating from uWSGI to Gunicorn and FastAPI document

This commit is contained in:
mvdbeek
2022-03-03 19:39:36 +01:00
parent acea74022e
commit 80f1f00e4e
2 changed files with 46 additions and 0 deletions
+1
View File
@@ -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
+45
View File
@@ -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.