Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web Monolith Discussion #2

Open
dpwrussell opened this issue Jul 21, 2017 · 6 comments
Open

Web Monolith Discussion #2

dpwrussell opened this issue Jul 21, 2017 · 6 comments

Comments

@dpwrussell
Copy link
Member

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
Copy link
Member Author

dpwrussell commented Jul 21, 2017

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
Copy link
Member

manics commented Jul 24, 2017

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
Copy link
Member Author

dpwrussell commented Jul 24, 2017

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
Copy link
Member

manics commented Jul 24, 2017

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

@dpwrussell
Copy link
Member Author

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

  • Monoliths including django and nginx.
  • Configurations where they build a custom nginx image in addition to the application image.

The monolith seems most common perhaps.

@dpwrussell dpwrussell changed the title static resources not found Web Monolith Discussion Jul 24, 2017
@manics
Copy link
Member

manics commented Aug 2, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants