Add NginxProxyManager App (jc21) about charts

[stavros-k]

I'll close the issue for now, as I don't think NPM is k8s aware (which would be basically required for being accepted) ánd we already support most of the things this does (which took me days of pain this year ;-) )

Yea,. this should be fine! I'm getting more excited now, and more impatient for all these to come!

[Ornias1993]

If you want, you can upvote this suggestion requesting for a hack-free way.
Because IX currently does not want to promise they will add custom catalogs in the future:
https://jira.ixsystems.com/browse/NAS-108842

[stavros-k]

Done!

[Ornias1993]

Looks like it have all the features of my proposed NPM (atleast features i use now! (DNS cert)).

Yeah, that's why I wanted to ask...

One thing i was waiting NPM to add was to be able to change timeout, i never used traefik so i dont know if this will be a problem here.

Interesting, when running HAProxy and nginx on OPNSense, I had the same issues with timeout.
I never had any issues with Traefik. If this does come up, I might alter it in bulk, per app basis or add an advanced section.

With npm i had problem when uploading large files to nextcloud because it had small timeout, so i had to manually edit the configs.

Yeah, same thing here on HAProxy/nginx and OPNsense, no issues with traefik however. (both on docker-compose and k8s)

authURL is a great addition, i would be able to forward some apps without login forms to internet and use another app like organizr for auth.

Yeah, I use it A LOT.
I also debated if I also wanted to give the option of adding Basic-Auth, but it would require significant configuration and/or the user adding the password+username in an already hashed format.
I think just nudging users towards organizr or authelia really isn't bad: Authelia if you want control, organizr if you want smooth UI-based user creation.

I'll close the issue for now, as I don't think NPM is k8s aware (which would be basically required for being accepted) ánd we already support most of the things this does (which took me days of pain this year ;-) )

[Ornias1993]

@inmanturbo Ofcoarse things can be deployed. I never said it couldn't be done, it's a docker container after all.
Thing is: It isn't k8s aware and doesn't comply with the K8S standards for ingress.

I'm not against other forms of Ingress (although i'm not personally going to implement or maintain them).
But at least they need to comply to k8s standards somewhat, which this doesn't.

As you can read above, i've already worked on self-service SSL termination with standardised K8S ingress (after feedback to actually use standardised ingress for this very reason) and this is working quite smoothly. I think it might be best to wait till I finished implementing ingress, before people start asking for other ways to implement it.

Adding another form of ingress and certificate management that (in some cases) conflicts with such system (at least the certificate management does) and is also quite confusing to end users.

That being said:
I'm not against it and it isn't a bad idea at all. If a PR comes in from someone that wants to support it themselves (because I'm not), it will get a fair review!
But it's just not fit for the To-Do list (at the moment) and thus the issue is closed.

[Ornias1993]

Super weird, I didn't get a notification about this...

Anyway:
I do not think this is k8s-ingress aware.
We already include a super-easy way to do the same for our kubernetes apps (setup certificate, proxy and harden the TLS stack with between 2 and 4 questions).
Our Ingress+certificate generator is also (in theory, somewhat) compatible with other forms of ingress.

Don't take me wrong, its a very nice looking app.
But for now i'll list it under "Curate App Viability", awaiting some info regarding how this works with K8S and Ingress.

[stavros-k]

Oh didn't know that! Is it on the GUI yet? Or it will added soon? Haven't played with TrueNAS yet, waiting RC to do some testing before migrating from Unraid!

[Ornias1993]

Well, There's the problem.
I could have a UI version to test ready tomorrow for quite a few containers... But...
The UI for Apps that is currently available on SCALE is a cheat made in two weeks (I gave IX quite some FLAK about it on slack for this). It hardcodes the complete UI deep in the actually SCALE code.
This means the current UI under "install" is not actually generated based on the App's that are listed, but picked out of 4 hardcoded options made by IX.

[stavros-k]

Well, There's the problem.

I see, that's why i didn't see it there :D haha

Thanks for your work! I'll wait for the updated UI to do some testing!!

[Ornias1993]

Well, thats not the reason why you didn't see it...
It doesn't magically find other app catalogs (besides those from IX) either.

I can make it visable with a small hack, but because of above issues it useless even if I do.

[stavros-k]

No need for hacks! Either small or big, Scale is under heavy development right now, i'll wait until is ready!

[Ornias1993]

Awesome!
Now back to your issues...

The current design I have for reverse proxies goes as follows:

1. The users sets up Traefik and certmanager (user will never see cert-manager, its running in the background to store certificates)
   Currently this asks the following questions (besides default questions for every container):

   email: "" (for Certificate generation)
   provider: "" (for Certificate generation, example: cloudflare)
   apikey: "" (API key to generate a DNS01 wildcard)
   wildcardDomain: "" (optional: Enter an extra domain to generate a wildcard certificate)

2. For every App (including the traefik frontend), it also asks the following questions when you want to 'enable ingress':

   host: "your.hostname.com" (the hostname for the application)
   selfsigned: false (if you want a self-signed certificate, this disables generation of certificates)
   wildcard: false (if you want to use the optional wildcard certificate from traefik?)
   existingCert: "" (if you want to use an existing (custom) certmanager certificate)
   authForwardUrl: "" (a traefik forward auth url, if you want it to authenticate to another authentication server, such as Authelia or Organizr (optional)

I think said base design is already quite streamlined.

[stavros-k]

Awesome!
Now back to your issues...

The current design I have for reverse proxies goes as follows:

1. The users sets up Traefik and certmanager (user will never see cert-manager, its running in the background to store certificates)
   Currently this asks the following questions (besides default questions for every container):

   email: "" (for Certificate generation)
   provider: "" (for Certificate generation, example: cloudflare)
   apikey: "" (API key to generate a DNS01 wildcard)
   wildcardDomain: "" (optional: Enter an extra domain to generate a wildcard certificate)

1. For every App (including the traefik frontend), it also asks the following questions when you want to 'enable ingress':

   host: "your.hostname.com" (the hostname for the application)
   selfsigned: false (if you want a self-signed certificate, this disables generation of certificates)
   wildcard: false (if you want to use the optional wildcard certificate from traefik?)
   existingCert: "" (if you want to use an existing (custom) certmanager certificate)
   authForwardUrl: "" (a traefik forward auth url, if you want it to authenticate to another authentication server, such as Authelia or Organizr (optional)

I think said base design is already quite streamlined.

Looks like it have all the features of my proposed NPM (atleast features i use now! (DNS cert)).
One thing i was waiting NPM to add was to be able to change timeout, i never used traefik so i dont know if this will be a problem here.

With npm i had problem when uploading large files to nextcloud because it had small timeout, so i had to manually edit the configs.

authURL is a great addition, i would be able to forward some apps without login forms to internet and use another app like organizr for auth.

[inmanturbo]

This can be easily deployed in k8s in concert with metallb as an L7 load balancer, something I do frequently as a simple self-service means of ssl termination. It is best done using session affinity if you are deploying more than one copy. You can easily point hosts at backend services running on the same cluster or any network it can access. Under the hood it is using Open Resty.

[inmanturbo]

gotcha. just thought I'd mention it.

[Ornias1993]

@inmanturbo
It's fine... you're right I could've explained my reasoning a WHOLE lot better! 👍

[truecharts-admin]

This issue is locked to prevent necro-posting on closed issues. Please create a new issue or contact staff on discord of the problem persists