[PoC] Granian #4596
[PoC] Granian #4596
Conversation
Source? Their git repo seems to be very active. Apparently it doesn't push new large features anymore, but why should it if it works perfectly fine with all its features now? ... |
Bnyro
left a comment
There was a problem hiding this comment.
Please convert the PR to a draft for now.
Sorry I will modify by "bugfix only", according to their website: https://uwsgi-docs.readthedocs.io/
|
| printf 'Listen on %s\n' "${BIND_ADDRESS}" | ||
| exec uwsgi --master --uid searxng --gid searxng --http-socket "${BIND_ADDRESS}" "${UWSGI_SETTINGS_PATH}" | ||
| #exec uwsgi --master --uid searxng --gid searxng --http-socket "${BIND_ADDRESS}" "${UWSGI_SETTINGS_PATH}" | ||
| exec granian --interface wsgi searx.webapp:app --workers 3 --host 0.0.0.0 --port 8080 |
There was a problem hiding this comment.
As Granian doesn't support config files, we would also need to port all the config here: https://github.com/searxng/searxng/blob/master/dockerfiles/uwsgi.ini to CLI arguments
|
I personally think it's generally a good idea to move away from Uwsgi and Granian looks like a good choice, however it's crucial that it still remains possible to run SearXNG with other wsgis (if not used via docker) so that we don't break existing installations. |
|
Lack of config files is kind of a problem, as this PR seems to be focused on just Docker I'm going to pretend that everyone hasn't done weird hacks to run other WSGI servers with the default container image. I've thought about allowing configuration through the CMD keyword in the Dockerfile itself, and then having the script passthrough all the parameters to granian. This would allow the default values to be easily modified if necessary. |
|
On docker, we have |
|
I would prefer not to create new abstractions to configure other programs. I don't mind configuring granian with flags (as long as they are not hardcoded), but if really necessary, we could request a new feature for config file support. |
|
The current docker image is built for linux/arm/v7 (Raspberry Pi 3 and some other SBC). Granian does not have wheels for arm/v7. We need to
[EDIT] no more relevant: there are now wheels for armv7 |
@gi0baro do you see a chance to support wheels for arm/v7 in Granian? |
I see the maturin action supports
In addition, I have no access to such kind of hardware to actually test the builds, so even if a build step can be added and it actually compiles, sounds quite far from "supporting armv7" tbh. |
🤔 .. the software is not in a state where everything works fine, one example can be found in Pitfalls of the Tyrant mode .. and what distributors do with uWSGI is little mess / distributors have their own concepts .. see: Distributors If we get rid of "Distributor's concepts" and install (with Granain) directly from PyPi, I think the setup would be much easier. All in all, with uWSGI we have a poorly maintained product that will not be improved any further and that has to be set up on the various distros in different ways. On the other hand, with Granian we have a product that is actively maintained and the maintainer (thanks goes to @gi0baro) who is already actively supporting us here in our thread :-) |
|
Out of curiosity, I successfully run a build workflow with Again, I have no idea if those wheels actually work. |
|
There are now (experimental) wheels for armv7, thank you @gi0baro : https://github.com/emmett-framework/granian/releases/tag/v2.2.3 |
|
I have done a production deploy with this change on https://search.inetol.net instance to pick up performance telemetry and properly configure granian. All the errors that are coming out will be published on https://github.com/inetol-infrastructure/searxng-container/issues to avoid polluting this PR. |
are you using arm/v7 on the host? |
No, only x86. I'm not building the images for arm/v7 there, as I don't have the hardware to test it. |
The test of @inetol should be limited to the SearXNG's migration from uWSGI to Granian ... a functional test of Granian on 32bit should be done by someone else (not really in the scope of the SearXNG project) .. a 32bit hardware is not required for this, it can be emulated with Qemu on a 64bit architecture (Pi2 Model has a Cortex-A7 CPU). |
|
There don't seem to be any other problems with Granian apart from the issue with static files. Obviously, this PR needs to be updated with the Granian env settings from my repo. As I'm using a somewhat tight SXNG settings there might be something I missed, so if anyone wants to quickly spin up a new instance for testing this I'm now publishing the container images to the registry. |
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary unless the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4818 Supersedes searxng#4596 Related searxng#4479
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary unless the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4818 Supersedes searxng#4596 Related searxng#4479
…nt and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. Those changes are reflected in the documentation, which also received a rework. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4894 Closes searxng#4818 Closes searxng#4802 Supersedes searxng#4596 Related searxng#4479
|
superseded by #4820 |
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4894 Closes searxng#4818 Closes searxng#4802 Supersedes searxng#4596 Related searxng#4479
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4894 Closes searxng#4818 Closes searxng#4802 Supersedes searxng#4596 Related searxng#4479
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4894 Closes searxng#4818 Closes searxng#4802 Supersedes searxng#4596 Related searxng#4479
* [mod] container: replace uWSGI with Granian The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes #4894 Closes #4818 Closes #4802 Supersedes #4596 Related #4479 * [mod] docs: add container/granian All container documentation has been recreated. A new documentation page has been created for Granian. * [enh] misc: apply suggestions Minor documentation changes. Suggested #4820 (comment) Suggested #4820 (comment) Suggested #4820 (comment) Suggested #4820 (comment) Suggested #4820 (comment) --------- Signed-off-by: Markus Heiser <markus.heiser@darmarit.de> Co-authored-by: Ivan Gabaldon <igabaldon@inetol.net> Co-authored-by: Markus Heiser <markus.heiser@darmarit.de>
What does this PR do?
This PR replace uWSGI with granian.
It is a Proof of Concept, it works but Granian configuration has to be tuned correctly.
Also all uWSGI files need to be cleaned (uwsgi.ini as well as docker entrypoint)
Why is this change important?
uWSGI is in bug fix only. A more modern solution should be used.
The project is in maintenance mode (only bugfixes and updates for new languages apis). Do not expect quick answers on github issues and/or pull requests (sorry for that) A big thanks to all of the users and contributors since 2009.Related issues
#4479