Add web server to Docker container (eg. nginx).

[esitarski]

The current Docker container includes the Postgres database, however, it still uses RaceDB's internal Python web server (waitress).
A far better solution is to extend the container to use a proper web server (eg. nginx).
This requires gunicorn to bridge the web server to Django so that Django is called for the dynamic content.
And, the web server must be configured to access RaceDB's static files (requiring collectstatic calls in startup).
A good explanation is here.

[mbuckaway]

The current docket container used Postgres. Mark Buckaway

…

On Jun 29, 2020, at 10:46 AM, Edward Sitarski ***@***.***> wrote:  The current Docker container includes the MySql database, however, it still uses RaceDB's internal Python web server (waitress). A far better solution is to extend the container to use a proper web server (eg. nginx). This requires gunicorn to bridge the web server to Django so that Django is called for the dynamic content. And, the web server must be configured to access RaceDB's static files (requiring collectstatic calls in startup). A good explanation is here. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[esitarski]

Corrected original comment - current container uses Postgres, not MySql.

[mbuckaway]

Sounds like this adds an extra layer of complication with little benefit. Unless RaceDB becomes an online registration platform served in the cloud, rather than "just" something run at the race site, I don't see the point. This would also mean either there would be two code streams (one for docker and one for traditional install) or the old install method would have to be depreciated.

As far as features is concerned, there is so much code in the Cross Manager ecosystem than needs clean up, this would be a very low priority item.

[rkantos]

How about there could be some reverse proxy default config for running RaceDB via Nginx? This way people could at least easily add their SSL/TLS settings for example. Also caching config of Nginx & browser would probably make most people happy, unless you're running RaceDB for a thousands of simultaneous connections. At that point, feel free to fork and make yourself happy with your own code? :)

[esitarski]

There is a growing direction to install RaceDB on the cloud as a "results aggregator" (that is, RaceDB/hub), so accessing RaceDB from the open internet is a growing use case. The RaceDB Cloud interoperates with the Local implementation. Uploads/downloads synchronize rider, registration and results data between the Local and Cloud instances. This implies a need for a first-class web server. The Docker container uses Postgres as the database, which is super-fast, but the internal python-based web service (waitress) is slow and doesn't show all that speed in the app. Finally, and perhaps the most important reason is that waitress is at risk of being discontinued as virtually nobody uses it <https://w3techs.com/technologies/comparison/ws-nginx,ws-waitress>. It appears that containers have addressed deployments so well that there is little point in using an internal python-native web server - why not go with industrial-strength?

…

On Tue, Jun 30, 2020 at 10:20 AM rkantos ***@***.***> wrote: How about there could be some reverse proxy default config for running RaceDB via Nginx? This way people could at least easily add their SSL/TLS settings for example. Also caching config of Nginx & browser would probably make most people happy, unless you're running RaceDB for a thousands of simultaneous connections. At that point, feel free to fork and make yourself happy with your own code? :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGXKKGM7UZENAOYWPI67TRZHYETANCNFSM4OLJHM4A> .

-- Edward Sitarski

[mbuckaway]

Sound like a good plan. I personally would like to see the "old install" retired for good. However, there are, it think more pressing issues with CrossMgr ecosystem, such as:

• move the github account to an organization
• move the website to github, and with it any releases
• retire all the google web/drive crap
• break up CrossMgr repo into separate programs based on common library (ie. not have fives apps in one repo)
• move all the other apps into github releases supporting all platforms
• clear up RaceDB container, etc.
• create CrossMgr container for "cloud deployment" (current outstanding feature request).
• etc.

The current ecosystem is a miss-mash of stuff that, IMO, is hard to maintain.

[esitarski]

Agreed. Lots of work there. Another point regarding a container-based web server is support for encryption (https). Waitress does not support it. It would be great if everything "just worked" from the box.

…

On Tue, Jun 30, 2020 at 12:57 PM Mark Buckaway ***@***.***> wrote: Sound like a good plan. I personally would like to see the "old install" retired for good. However, there are, it think more pressing issues with CrossMgr ecosystem, such as: - move the github account to an organization - move the website to github, and with it any releases - retire all the google web/drive crap - break up CrossMgr repo into separate programs based on common library (ie. not have fives apps in one repo) - move all the other apps into github releases supporting all platforms - clear up RaceDB container, etc. - create CrossMgr container for "cloud deployment" (current outstanding feature request). - etc. The current ecosystem is a miss-mash of stuff that, IMO, is hard to maintain. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGXKN7NPBEVCLOC7TNWPTRZIKOBANCNFSM4OLJHM4A> .

-- Edward Sitarski

[mbuckaway]

Well, chop chop. Hit the Convert to Org button.

Yes, HTTPS support should be done.

[mbuckaway]

Old issue. Closing.