search

ome / omero-web-docker

OMERO.web production docker image
https://hub.docker.com/r/openmicroscopy/omero-web/
BSD 2-Clause "Simplified" License
6 stars 19 forks source link

Web Monolith Discussion #2

Open dpwrussell opened 7 years ago

dpwrussell commented 7 years ago

Docker started with example parameters from README.

None of the static resources are found. E.g.

2017-07-21 16:57:31,889 WARNI [                          django.request] (proc.00065) get_response():170 HTTP 404 <WSGIRequest: GET '/static/webclient/image/icon_toolbar_refresh.png'>
2017-07-21 16:57:31,889 WARNI [                 omeroweb.feedback.views] (proc.00065) handler404():188 Not Found: /static/webclient/image/icon_toolbar_refresh.png
dpwrussell commented 7 years ago

Presumably this is because there should be an nginx container as well? When digging I saw that this is not integrated into this image.

The nginx configuration would be more complicated than usual I think because it would have to be configured to use TCP for the upstream gunicorn.

manics commented 7 years ago

That's right, I followed best practice by not including Nginx in the same container. I've had some success with using whitenoise to serve requests including statics directly from Django http://whitenoise.evans.io/en/stable/

In this example I've added it directly to the playbook, but since these changes are just additions it's trivial to add it to a derived container FROM openmicroscopy/omero-web: https://github.com/openmicroscopy/omero-web-docker/compare/master...manics:whitenoise?expand=1

Enabling whitenoise in this production image could be an option, but could potentially interfere with anyone doing advance config of their OMERO.web docker. Thoughts?

dpwrussell commented 7 years ago

Sure, that is the best practice. However, I'm not sure if we would want to be changing (to whitenoise) the recommended OMERO best practice (nginx) for just the containerized approach, particularly as people may have other reasons to follow the recommended nginx setup (not least being a closer setup match to a non-containerized server).

Assuming the above statement holds, I think it would be necessary to either maintain another omero-web-nginx docker image (exteneded from nginx) or to relax docker best practice and make the default OMERO.web + nginx. Otherwise any users will be faced with trying to build a custom nginx container before they can use web. The static files would have to be copied there for a start which necessitates a download and install of OMERO.web. Inter-container volume sharing will not be sufficient because the docker containers may not be co-located.

I think one goal should be to make it possible to start several containers and without any configuration or extension, have a working OMERO stack.

manics commented 7 years ago

Do you know how other Django apps deal with statics in containers? It sounds like this should be a solved problem.

dpwrussell commented 7 years ago

As far as I can tell, the two approaches I mentioned are what I have seen used.

The monolith seems most common perhaps.

manics commented 7 years ago

I could see us having two images, plain omero-web, and either omero-web-nginx (OMERO.web + nginx) or nginx-omero-web-static.