Open TheBlueKingLP opened 5 years ago
I can see adding support for static sites. This would be a nice feature. Setting fast-cgi parameters may even be a nice enhancement.
But executing php, ruby, node, etc should not be in the scope of this project. It should be done in its own docker container. Just add it to your docker-compose file. Or consider using Caddy @TheBlueKingLP with a php backend container.
Yep :) I agree that if I open the floodgates with PHP support, I'd have to do it for others as well. Not to mention that PHP with Nginx requires yet another process to be running in the background and I'm not sure about other cgi handlers but I'd guess they might need them too. This doesn't make the proxy a lightweight solution.
I can see value in adding basic html support though. Seems overkill to spin up another docker container just to spit out plain text html files. Adding this feature costs nothing.
In future it might be possible to build spin-off docker images that extend the base functionality, so you might have latest
, latest-php
, latest-ruby
etc and leave the choice up to the end user rather than trying to accommodate everyone. But don't hold your breath on that.
Yes please, static site, mapped in container path.
It would be great! This is the thing I'm missing the most. I started up this image and I quickly realized "wait a minute, I don't have that many proxies". I have a wordpress website, a simple domain that makes a folder browseable, and some subdomains that are proxies but yeah... I'm conflicted now because the bulk of my configuration wouldn't be managed by the UI :(
So please, consider adding this website host feature, optionally with the spin-off docker images you mentioned! Let me know if you require assistance!
At first I wanted static sites to be supported but I get why they're not, it would mean your nginx container would need to have a bunch of volumes attached to it for each static site, or just 1 volume for all of them, and that defeats the modular purpose of docker.
What I'm doing is running this, proxying to a certain ip, which then runs another deployment of an nginx container with 1 static site in it, so each static site gets its own nginx process and ip, effectively turning static sites into ip address sites.
Now then yeah you have to manage that config through text but managing one site's config through files is alright compared to managing numerous load-balanced proxies on your nginx-proxy-manager instance.
Just my thoughts
I've been doing this following for quite some time in my 404 hosts to enable some simple static hosting
root /var/www/html;
location / {
index index.html index.htm;
}
Note: This will likely break your preset settings such as "Force SSL" settings for this host. (although certificates will work fine)
My docker compose is slightly different, I've added PHP FPM in a seperate container, and I'm exposing the host's /var/www directory to both the app and php container (the directory could be anything, but this is what I chose to use)
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
ports:
# Public HTTP Port:
- '80:80'
# Public HTTPS Port:
- '443:443'
# Admin Web Port:
- '81:81'
environment:
# These are the settings to access your db
DB_MYSQL_HOST: "db"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "npm"
DB_MYSQL_NAME: "npm"
# If you would rather use Sqlite uncomment this
# and remove all DB_MYSQL_* lines above
# DB_SQLITE_FILE: "/data/database.sqlite"
# Uncomment this if IPv6 is not enabled on your host
# DISABLE_IPV6: 'true'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/www:/var/www
depends_on:
- db
links:
- php
php:
image: php:8-fpm
restart: always
volumes:
- /var/www:/var/www
db:
image: 'jc21/mariadb-aria:latest'
restart: always
environment:
MYSQL_ROOT_PASSWORD: 'npm'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'npm'
volumes:
- ./data/mysql:/var/lib/mysql
Finally, for those hosts that you would like to enable PHP on, you should use something like the following in the advanced tab
root /var/www/html;
location / {
index index.php index.html index.htm;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass php:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
}
I quite like that I can mix and match PHP and non-PHP sites quite easily on the same host. There may be a more elegant solution but this is what I've been using for quite some time, so thought I'd share it.
@jc21, without php support? will it be okay to add the static html files. (may be generated by fronted framework)
can we add another scheme here as path. (i know that scheme is not an appropriate term but,)
then update the path provided there and update the template file ??
I agree with @ssrahul96 and think that a file scheme with only a required path box would be ideal. I would also like to suggest adding this to the custom locations as well (though in its template it would be alias instead of root). I would also suggest that no default location / or such be added, I believe file should be considered and "advanced" scheme and require any additional setup be done in the appropriate advanced configuration box. This would handle most of the requests for static/cgi_pass issues without requiring a ton of custom code for npm, though it would not be as "easy" as a normal setup, this use is the exception not the rule.
I've been thinking about adding a file host, with an optional FPM style handler. I'd default to /var/www (Hello world!) and allow a user to change the location. Haven't thought it through too much, but would be interested in seeing others input before committing to a PR.
I have been giving this a think for the past few days, and I think the following would work: Adding a static file host type, with support for a (container/env local) path, that defaults to /var/www/1st domain but can be overridden with a path box, and an additional default for a default page of index.html, which can also be overridden with a defaults box, would do the trick. Also present should be the SSL/locations/and advanced tabs. However, in the locations (for both this host and a proxy host, could an additional "scheme" be added that would support static file locations as well (with similar options as above for the static host.)
As for FPM, there are some "basic" options you could provide, but I think that most of the time people would need to copy/paste a setup that is specific to the app they are forwarding, so I still feel this should be left as an "advanced" procedure.
Would you agree that this is a good starting point, and something you could make a PR for?
We need another host type. File host. it could take a simple path that needs to be accessible for a start.
Has there been any work on this? Is there any where I could lend my efforts to help get this feature added?
Having this would make this a full nginx manager. I understand that having fast cgi backends would significantly increase maintenance effort. The easiest way to do it would be to declare simple static sites plus the ability to declare fastcgi backends. And let the fastcgi service to be configured by the user as a separate backend that is not managed by npm.
The other issue would be that we would need custom directives per domain/backend. It's very common to require special config to support pretty URLs, secure sensitive data, define compression, and so on.
I am currently using Caddy for this reason, but I would love to have alternatives, especially with the speed and gravity of nginx.
Issue is now considered stale. If you want to keep it open, please comment :+1:
Default WWW/root folder/directory for docker container managed by Nginx Proxy Manager is /usr/share/nginx/html
. Take a look here at StackOverflow
I would like to see website host in this docker It should be like the proxy host, but instead of asking you for the Scheme,Forward Hostname / IP and Forward Port, it should ask for a path for the website contents. It should also support php7 for hosting php files.