Today I use truecharts with traefik and ingress. This allows my to set up my domain and reverse proxy for both external URLs and internal URLs when on my local network. The experience is amazing. I type in xxx.url.com and regardless of wether it is an public or private app, it will resolve.
Truecharts has stopped all application updates and deprecated their catalog. By july 1st they will come up with a transition plan that will likely require an install of k8s/k3s in a jail/VM. I don’t reallly want to go down that route and prefer staying in the app ecosystem.
the official truenas apps only offer nginx proxy manager (NPM) as a reverse proxy but does not support mapping to port 80/443 because of upstream k8s limitations. Somehow the truecharts implementation of NPM did not have this limitation…
This means that I can still reverse proxy for external url calls (public websites) as my router can redirect to the right port on my truenas box, but my internal URL calls that get resolved as 192.168.1.x no longer resolve as NPM does not run on port 80/443
in short, there is no way to successfully reverse proxy with internal ips, unless you deploy NPM in a jail or VM on a bridge network which is hugely overkill.
When electric eel comes out this will be resolved as we should be able to map any ports, but in the mean time it is choosing between:
1/ no app updates until the Q4 release of electric eel
2/ no longer having local ip support for reverse proxy implementations.
3/ setting up jail/vm just for NPM
Does anyone know of a way of doing this with the native app ecosystem?
I hadn’t heard that TrueCharts had stopped all application updates. But a possibility could be to run the reverse proxy only on your router, and do away with Traefik/NPM entirely.
OPNsense has plugins for both HAProxy and Caddy; pfSense has HAProxy. Between the two, I much prefer Caddy and OPNsense, but the same principles would apply in any of those scenarios:
Undo any local DNS overrides for the services in question, and point them in public DNS to your WAN IP (or CNAME them to whatever DDNS name you’re using)
On your router, set up reverse proxy entries for the services in question pointing to the correct IP/port combination
If you want some of those services to be local-only, implement ACLs for them to allow only local IPs to access them
This does depend on hairpin NAT, which works well for me under OPNsense. But it’s probably the simplest possible solution.
Personally, I’m not planning on changing anything with my TrueCharts apps at least until I see what they’re planning in July.
Incidentally, I don’t think I’d touch NPM; I’d just use Caddy instead. Yeah, you have to write the Caddyfile without a GUI–but it’s so simple to do that I just don’t think NPM is worth setting up.
Check the URL for their catalogue, it has been archived, and I asked on their discord and they confirmed that they stopped updates to focus time on their transition plan.
My router is from my ISP and does not support anything fancy. I do however run pihole that supports local DNS. However this no longer supports HTTPS and certificates.
It is a decent workaround though, but also not great.
Thanks for the Caddy recommendation, however it does not resolve the port issue so while a better reverse proxy, it would only work for my external apps which is like 10% of my apps.
I suppose replacing the ISP-provided router with one that isn’t brain-dead is off the table?
I really don’t think there is, with the other constraints you’ve mentioned. The iX apps can’t use ports below 9000[1] for some reason that doesn’t apply to TrueCharts. So if your decision is to drop TrueCharts, and you can’t use a reasonably-featureful router, I don’t think you have any other options.
But I don’t think a month is too long to wait to see how TrueCharts is going to handle the migration.
though now the iX PiHole app can; it does listen on port 53 for DNS queries ↩︎
Can’t replace the router, unfortunately, ISP is very rigid, can also not turn it into a dumb bridge.
regarding truecharts, yes I can wait, but do I really want to have my app ecosystem running in a jail, with a custom k8s deployment etc? Sounds like extreme overkill because once electric eel is out I can (hopefully) configure port 80/433 and just use traefik as intended with docker compose and labels.
It’s just these next 6 months that are in limbo for good reverse proxy support because IX never came up with a decent solution for this and truecharts came in and solved it instead.
My own biases and preferences may not be the same as yours, so for the sake of transparency, I believe TrueCharts has a better catalog than iX could ever hope to have had with the current ecosystem, and almost certainly much better than whatever ad-hoc system iX is going to create within the next few months for 24.10. I’m very inclined to continue to use their catalog if I can. If they come up with a solution that includes a decent GUI to browse, install, and modify apps; and a decent way to work with storage on the TrueNAS host, I’m very likely to use it. I’m not thrilled about a lack of updates for the next month, but I think I’ll live with it. At that point, I’ll have a decent idea of what they’re proposing as a solution and be able to make a more informed decision.
If you don’t share those beliefs, you may not be as motivated to try to continue with the TC charts. And in that case, someone else might give you advice more in line with your preferences.
It can be done in iptables, IIRC, but I don’t think it’d survive a reboot.
For a really low-tech solution, you could just create bookmarks with the relevant ports, right? e.g., rather than https://sonarr.mydomain.org, bookmark https://sonarr.mydomain.org:9443.
I think for my usecase, once the docker transition is done, using the “custom app” feature with docker compose and all the flexibility that comes with that will resolve everything. I don’t know if the additional complexity of truecharts and whatever solution they come up with will counterbalance the simplicity of that setup. All the limitations of the app system will be gone. Let’s see what features truecharts can bring to the table to counterbalance that.
I don’t really care about the catalogue once I can docker-compose away anyway.
yes I can go back to barbarian times and bookmark ports, but it’s just not sexy
You could put those bookmarks on a dashboard of some sort; that’d be a bit sexier. But definitely not the nicest solution.
That sounds very optimistic, but I guess we’ll see. And really, if that’s what you want, you can set up a sandbox, install Docker and Dockge/Portainer, and you’re set today. But then there’s no reason for you to care about the “native app ecosystem.”
We already have a bunch: point-and-click ingress, SSO, VPN, code-server, and many others. All integrated with all ~800 of their apps. Their value to you is, of course, up to you; some of them are more valuable to me than others.
I use 2 of those: ingress and VPN for 1 container.
ingress I can replace with caddy/traefik and manual labels, not that hard once docker compose is available.
VPN I have to use a custom image for my app with VPN integrated, they exist not complex either.
Will this work with catalog IX apps? maybe not, but i’m ok with custom apps as well.
So for me the value is not huge. I would love for IX to add these things but not holding my breath. Let’s see what truecharts propose, I really like what they have built and exclusively use truecharts today, but yeah I may not use all of their benefits so for me not worth extra layers of complexity that will likely be introduced.
I understand for others (you) this is of course different.
Everyone’s needs are different, and so are everyone’s resources. I use Proxmox quite a bit already, so if the solution is, say, a Talos VM or three with a web-based dashboard, easy enough for me. And that moves the “apps” outside of iX’ purview entirely, which is starting to look pretty good to me. But that may not work as well for you or others. But regardless, I think “wait and see” is likely the best way to go, at least until July.
But if you don’t care about an app catalog and just want straight docker-compose, there’s no reason to wait.
July is TrueCharts’ announced date for beta for their migration solution; I’m expecting by that time their direction will be clear enough for those of us who primarily use their apps to make an informed decision whether to stick with them, stick with their charts on a different platform, or do something else. My only interest at the moment in EE’s new “apps” ecosystem is curiosity, as I currently only use one iX app (Storj) and don’t anticipate moving everything I’m running into docker-compose.
I can’t even use Dragonfish yet, so I don’t know how helpful it will be to me for it to continue.
If you are asking can you use low number ports like 80/443, the answer is yes. You said apps, but I am including “custom apps”. Custom apps (which do run within the app system) can be assigned their own IP, and once they have their own IP, port restrictions are removed. So, you wouldn’t use a chart, you’d use the underlying docker container. That would then be much closer to what you might do on Eel.
This is what just I did, although I found it a bit wonky to get right.
I setup NPM as a custom app and gave it it’s own IP included in a bridge shared by Kubernetes. The wonky parts started when I wanted to redirect to the container, since both the container host name and IP will change any time the container is restarted. The solution I found was by using the internal cluster domain name assigned that look like this for example: jellyfin-ix-chart.ix-jellyfin.svc.cluster.local. Supposedly this will be easier to achieve when the subsystem is moved over to Docker since NPM natively supports a way to adress containers using the Docker network.
I also had to change NPM and certain other apps to prioritise internal Kubernetes DNS resolution, a setting made on an app per app basis.
This setup lets me use a single wildcard Let’s Encrypt certificate for all apps on my TN-box.
Yes, to reference other containers you use the internal dns names. And you need to set the network setting that says to check internal names first too. I did not mention that but that’s how I do it.
Kris didn’t explain it fully in original thread, but here’s my summary of what the Electric Eel plan is:
Current plan is to keep a lot of the Apps UI intact with regard to how we browse for Apps in the catalog. We will be adding a networking section where docker INTERNAL networks can be created and managed, as well as the ability to import docker compose YAML directly. Our goal here is to not over-complicate the implementation, and allow pretty much a 1:1 of native docker / compose functionality to be used out of box. A single INTERNAL network can have one (loadbalancer,Ingress) App with external IP/ports and other Apps sitting behind it. For loadbalancer and ingress… any of them can be used: nginx, traefik, caddy, wireguard, etc… Multiple docker internal networks can operate simultaneously.
