-
Notifications
You must be signed in to change notification settings - Fork 497
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
Added NGINX_ENABLED
env variable allowing to disable internal nginx…
#148
Conversation
Using unicorn to handle static web requests is not a great idea. Unicorn is a ruby process and takes a lot of system resources, as result we end up limiting the number of unicorn processes. If unicorn is left to handle requests to static asstes, it can make redmine unresponsive when users are downloading large files from your redmine server as unicorn will be busy handling the download request instead of doing something useful. At the same time, user will have to increase the unicorn timeout to make sure the download by a slow client is not prematurely closed before the download is completed. I have seen this issue in action and how it affects the responsiveness of a ruby app when a client is downloading a large file and/or the download speed of the client is very slow. It is therefore advisable that static file requests are handled by a web server, instead of asking unicorn to do this heavy lifting. |
thank you for your thoughtful response. in some cases (like ours) host is already running nginx for other needs, so running a dedicated nginx instance just for redmine is unnecessary and I ended up proxying to redmine using "external" installation of nginx. one can configure that external web/proxy server to serve location of static files (since it's stored on the host) using rewrite or alias mechanisms. same thoughts apply to the cron server that is started inside redmine container. I'd love to be able to optionally disable it and moving this functionality to the external cron server (execute commands inside container via docker exec, for instance). in general, the idea is to be able to run a "naked" redmine container with all the supportive services (like db, cron, nginx) running outside (or within other, separate containers). speaking of - this is how docker team suggest containers to be built: a single-service ones. if you agree that this is a valuable optional feature to be included, I can work to polish my patch (tweak doc?) and further extend this approach onto cron server as described above. thanks. |
@vladm it is true that docker suggests having only one service per container. But this is difficult to get working in applications that require external services like cron without having a complicated setup guide. I know it is possible to run cron on the host and perform tasks in the container using docker exec, it however does affect the portability of the container. i.e. you will not be able to move the container to another host without also moving all the extra setup that you may have performed on the host. However if you think this is something you need, then I have no issues, you can add a config option to disable CRON, just make sure that the effects of doing this are well documented in the README, so that users know what they are signing up for. With regard to disabling NGINX, again if you think this is the right solution for you, then I will be happy to merge this PR. But you will need to document it well in the README as in the case of disabling CRON and also support users who decide take the same path. Lastly, I dont know if you have used this PR in production. But i would suggest you run your changes in production on a decent size installation and see how it behaves before committing to this change. I have seen the effects of disabling nginx in production. As a matter of fact, nginx was once removed from this image for a brief period and I quickly reverted the changes when things started falling apart. As far as the PR goes, if you want to disable NGINX then all you need to do is disable its startup in the Also, the If you are commited to this PR, then let me know, I will comment inline on your PR to get it right. |
we do run this in production, however I think you are missing the point of why I'm disabling nginx / cron. It's not to expose unicorn directly to the world, but to utilize nginx that we already run on the host for other needs. I don't want to run another nginx within redmine container nor I want to do double-proxying... So, instead of going: user => host nginx => [ nginx within container => unicorn within container ] we are able to do this: I'll update the README with a more detailed explanation for disabling nginx within container and rework it with your suggestions. I can't 100% agree with the notion that "removing nginx & cron leads to less portability" - I think a different approach should be used: separating those extra services, like nginx, cron, etc into individual containers and utilizing docker-compose to provide user with a fully deployed app, consisting of multiple services. This should also allow for more flexibility for deployment like ours - letting us run cron + nginx + db outside of "redmine" container. |
hi , i have add here is info
and my docker-compose.yml
|
Update README.md for link of #148
Allows disabling internal nginx server in favor to using with an external proxy server.