November 17, 201411 yr Per request via PM, here an NGINX Proxy docker. I run an apache reverse proxy, so please test and let me know how it runs, once its working I will add to my repo. I forked dockerfile / nginx and adapted it to our base image. https://registry.hub.docker.com/u/smdion/docker-nginx/ Available on my beta-template-repo: https://github.com/smdion/docker-containers/tree/beta-templates docker run -d -p 80:80 -p 443:443 -v /path/to/nginx/sites-enabled:/etc/nginx/sites-enabled -v path/to/nginx/certs:/etc/nginx/certs -v path/to/nginx/logs:/var/log/nginx --name nginx smdion/docker-nginx
November 17, 201411 yr Author I have it working with this setup. I run an apache proxy (hence why I changed the ports), anyone want to try a config or 2?
November 18, 201411 yr I have been thinking about this for some time and mentioned it in the thread discussing why IMHO the unRAID web GUI should not be on port 80 or 443 and these should be kept free for user facing things. In this thread lots of clever ideas were thrown about how to do redirect etc Where i see the nginx reverse proxy coming into play is by presenting a single web hop page for arbitrary docker web applications. There are things kicking about like marachino but they are very specific. For example why should I have to remember the port for the polipo web gui or ask a marachino dev to support ubookquity... wouldn't it be better to just browse the unraid ip and from there be presented with a jump page. I know the docker addon lists the ports etc but this is for admins only. it is of zero use to non admins. So ramble aside I think what we should do here is initially present nginx on port 81 with a default setup that has a framework for reverse proxying anything anyone wants to add. By default everyone has emHTTP so that the one to use as an example. There is also a load of clever stuff we can add , extra security and a single common self signed TLS cert etc but I think it is a case of build it and they will come. Nice work
November 18, 201411 yr Author I have been thinking about this for some time and mentioned it in the thread discussing why IMHO the unRAID web GUI should not be on port 80 or 443 and these should be kept free for user facing things. In this thread lots of clever ideas were thrown about how to do redirect etc Where i see the nginx reverse proxy coming into play is by presenting a single web hop page for arbitrary docker web applications. There are things kicking about like marachino but they are very specific. For example why should I have to remember the port for the polipo web gui or ask a marachino dev to support ubookquity... wouldn't it be better to just browse the unraid ip and from there be presented with a jump page. I know the docker addon lists the ports etc but this is for admins only. it is of zero use to non admins. So ramble aside I think what we should do here is initially present nginx on port 81 with a default setup that has a framework for reverse proxying anything anyone wants to add. By default everyone has emHTTP so that the one to use as an example. There is also a load of clever stuff we can add , extra security and a single common self signed TLS cert etc but I think it is a case of build it and they will come. Nice work I have kinda already done this with Apache Reverse proxy, but mine is a redirect base on the "/address". A jump page may be neat as well (or both). The .conf looked a little easier to setup me for me than with nginx. I have changed the WebGUI of unRAID to 8008 and have Apache running on 80 and 443. I use DDClient to update DynDNS with my domain. This was I can go to www.mydomain.com/nzbdrone or www.mydomain.com/nzbget and access everything. I have a free SSL cert from www.smartssl.com. My config for apache reverse - http://pastebin.com/raw.php?i=TJkcxzvh Is nginx really that superior over apache?
November 19, 201411 yr nginx is not better as such and its is certainly not as feature packed as Apache but its much lighter and faster at what it does. I like most came to it from a need to reduce apache bloat so moved to lighttpd and then got frustrated with that and settled on nginx. For this application it probably doesn't make much difference although lighter is always better. For that reason I would say nginx is a better long term fit. The config will seem familiar to you location /nzbget { client_max_body_size 8m; proxy_pass http://127.0.0.1:6789; } I prefer to bind all the daemons to localhost only and then control access via nginx reverse proxy as above. The tricky part is whilst a jump page and the config are not hard I dont know how to make it completely point and click n00b friendly without just adding every possible daemon to the jump page.
November 19, 201411 yr Author nginx is not better as such and its is certainly not as feature packed as Apache but its much lighter and faster at what it does. I like most came to it from a need to reduce apache bloat so moved to lighttpd and then got frustrated with that and settled on nginx. For this application it probably doesn't make much difference although lighter is always better. For that reason I would say nginx is a better long term fit. The config will seem familiar to you location /nzbget { client_max_body_size 8m; proxy_pass http://127.0.0.1:6789; } I prefer to bind all the daemons to localhost only and then control access via nginx reverse proxy as above. The tricky part is whilst a jump page and the config are not hard I dont know how to make it completely point and click n00b friendly without just adding every possible daemon to the jump page. I wonder if we could take from the XML files to build a jump page
November 19, 201411 yr I was thinking the same thing but it doesnt feel that elegant to me as there would be lots of non HTTP(s) ports in there as well. Perhaps we just hack something together as a working proof of concept and see if it inspires a longer term more robust solution.
November 19, 201411 yr Author I was thinking the same thing but it doesnt feel that elegant to me as there would be lots of non HTTP(s) ports in there as well. Perhaps we just hack something together as a working proof of concept and see if it inspires a longer term more robust solution. Maybe add a flag in variable? A 'turn on/turn off' for the web landing page? Thats a 'hackish' answer, but may work.
November 19, 201411 yr I was thinking about it and really the only way of not breaking the fundamental docker mantra of "run as many times as you like" is to go back to the first idea. So we would mount RO the path to the dockerman xml and on container start do something like generate a local config file per dockerman container to allow users to do things like hide/disable add comments etc. Done this way if someone want to run 2 of these it would not break anything. On a seconf run any new containers could be detected and new configs generated. Its not particularly elegant but it would be reliable.
November 24, 201411 yr Any way to expose the nginix.conf file itself? I think that editing that file is necessary to set up shared memory spaces which are needed for things like rate limiting and connection limiting.
November 24, 201411 yr Author Any way to expose the nginix.conf file itself? I think that editing that file is necessary to set up shared memory spaces which are needed for things like rate limiting and connection limiting. Got it working. Please update and add in the location where you want the nginx.conf to be created in the /nginxconf volume
March 6, 201511 yr please provide step by step as I am really struggling to get this working I was assuming that after installing this I would have some base files to work from, but I don't even have a blank sites-enabled file to start filling in? if I need to manually create files then fine but please let me know what and where if it should have downloaded these files then please provide an idiots guide as I am obviously one
March 18, 201511 yr still having real trouble here cannot even just get a simple port 80 index.html file to display here is my sites-enabled/default file server { listen 80; root /mnt/cache/docker/appdata/nginx/www; index index.php index.html index.htm; server_name mynoipserveraddress; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { } location ~ /\.ht { deny all; } } can anyone help me, its driving me mad as I know its something stupid I am missing....
March 20, 201511 yr Could it be worth trying the Apache reverse proxy, I've used that successfully. Unless you are desperate to use nginx..
March 21, 201511 yr Hi, I have tried both,if someone can provide screenshots of the docker page, the web server config file, and the drive folder structure that would be great thanks
March 21, 201511 yr Hi, I have tried both,if someone can provide screenshots of the docker page, the web server config file, and the drive folder structure that would be great thanks Working this weekend but as soon as I get a moment I will mate.
March 22, 201511 yr Hi, I have tried both,if someone can provide screenshots of the docker page, the web server config file, and the drive folder structure that would be great thanks Have a look here and see if that helps at all.
March 23, 201511 yr cannot even just get a simple port 80 index.html file to display you can't use port 80.. it is taken by unraid to display it's interface use port 90 or 81 or 8080 or whatever you fancy.. just not 80, effa to be complete... you leave the container port on 80, but the host port is something else.. when calling the page you must use the host port.. as in 127.0.0.1:90
Archived
This topic is now archived and is closed to further replies.