Use gunicorn instead of the Werkzeug development server #132
Conversation
src/pve_exporter/cli.py
Outdated
| 'bind': f'{params.address}:{params.port}', | ||
| 'threads': 2, | ||
| 'keyfile': params.__dict__['server.keyfile'], | ||
| 'certfile': params.__dict__['server.certfile'], |
There was a problem hiding this comment.
There is a way to avoid using params.__dict__ here: Add a dest argument in the parser.add_argument call above in order to specify the key name. I suggest the following key names:
parser.add_argument('--server.keyfile', dest='server_keyfile'
help='SSL key for server')
parser.add_argument('--server.certfile', dest='server_certfile'
help='SSL certificate for server')
This way the values can be accessed using the property syntax.
'keyfile': params.server_keyfile,
'certfile': params.server_certfile,
| def load_config(self): | ||
| config = {key: value for key, value in self.options.items() | ||
| if key in self.cfg.settings and value is not None} | ||
| for key, value in config.items(): | ||
| self.cfg.set(key.lower(), value) |
There was a problem hiding this comment.
This is hardly readable. However, it follows the upstream example and I honestly have no better idea on how to translate the options dictionary into the gunicorn cfg format. Hence, I'm okay with it.
There was a problem hiding this comment.
I agree. At least I added a comment pointing out the source.
|
Also, please add |
|
Cool thanks, meanwhile I fixed my own linting errors in the |
Werkzeug itself doesn't recommend being used in production. Using Gunicorn brings in e.g. HTTPS support with low effort.
|
Thanks a lot. I've tested this PR locally with and without HTTPS. Also tested the docker build, everything looks great! |
Werkzeug itself doesn't recommend being used in production.
Using Gunicorn brings in e.g. HTTPS support with low effort.
Resolves #130.