Fair enough. I do use some TC apps because they offer some options that TN ones don’t, so it will be interesting to see what you come up with.
Nope, not you.
1 Like
hey thanks for the feedback, appreciated.
I understand your point, and I don’t necessarily disagree (e.g.: a Talos VM for apps probably is a superior approach, etc…), but still I believe that SCALE as a product would benefit from doubling down on Helm. You would be taking the high road, but I am positive you’ll see benefits long-term.
As long as your use case is well served by what you find on the internet we can agree. But imagine you now want to add gluetun for VPN to one of your docker compose, you go to the repo and (as the author himself says), if you are lazy, you copy paste this snippet. Now, you need to do this for every app, so you now go back to the repo or you copy paste this snippet from an existing app, etc… Imagine the snippet change, for any reason: versions are now different between apps, some are lacking a new ENVVAR. This leads to fragmentation and anyone who ever put up with this stuff probably understands why Helm charts are a useful abstraction.
Imagine now you start copying .yaml snippets including permissions and capabilities granted to the container, this can quickly become a serious security issue.
What about backups? Sure that repo tells you you need to do this and that for a specific app, and this may be different from what you are supposed to do for another app. Now you have several, disjointed backup methods that need to be maintained separately if you want to seriously rely on them.
Also, when you want to use ingress sure, many will give you useful snippets for nginx or traefik, but not all apps will offer this, surely not for all reverse proxies in existence.
In general, after some time, you will be looking at probably wildly disjointed .yaml deployments, with many hacks for specific apps, that only live inside those files. Sure, you can use version control and be diligent, anything can be done successfully with an adequate effort. Also, IX-System will be probably have a very hard time offering meaningful support to people running these setups.
Here we are not talking about highly custom multi-node production deployments, but mainly apps that can be installed from repositories with a few clicks. So whatever you do, a standardization effort will always emerge in these cases, because it’s the efficient thing to do: instead of each user reinventing the wheel every time for every app, all of these things could be streamlined, unified, automated and properly documented. Yes sure, it’s opinionated, but again, the snippet on the repo is opinionated as well.
This is the promise of the Helm approach, and these are tangible benefits that users of TrueNAS Apps or TrueCharts apps already enjoy today.
1 Like
Your points are a lot more clear to me now, but I still don’t believe all the doomsaying because again, Docker has been around for a long time now, and this just isn’t how that all shook out.
TC probably fits a lot of those needs, but I’m concerned with how proprietary it all is. As long as we’re doomsaying, TC could very, VERY easily tomorrow go “If you want to open your app PVCs, you have to give us 10 dollars a month” and blammo, your appdata is effectively cryptolockered.
1 Like
So where’s the library of docker-compose files with “check-the-box” integration of ingress, VPN, SSO, code-server, Homepage, etc.? You know the answer is that it doesn’t exist. Can those be “bolted on” to a developer-provided docker-compose file? I’m sure at least most of them can. But then we’re in the situation Pinoli describes, meaning that is precisely “how that all shook out.”
Are iX going to develop such a library? I don’t think I’m going to hold my breath waiting.
What is proprietary about TC?
1 Like
Having used Freenas since 9.x, barring the announcement of linux-based Scale, NOTHING gives me greater joy than this. I hate kubernetes with a passion, do not understand any of the positives people try to explain to me it has, feel it’s clunkier, slower and infinitely more complicated and unintuitive to set up. On the other hand I’m extremely comfortable using docker compose, basically I couldn’t run “hello world” via helm chart if my life depended on it.
Don’t get me started on TC, if anything breaks you’re SOL unless you wanna go on Discord, changelogs are non-existent and I only use their apps because back then there were (and for some still aren’t) TN alternatives.
Cannot wait for the day I can reclaim the 5% to 10% cpu k3s uses even when idle and not a single chart installed and start running my apps via Dockge.
Thanks iX!
6 Likes
I have been managing my 40-ish docker compose stacks spread over 3-4 machines without any issues for years and backups are a breeze either via borg or just shutting down the stack and tar-ing it up. On the other hand backing up TC app is a major pita requiring external script, takes forever to set up and restore is 50-50 if it will work (in my experience) and will only work on the same machine and then the backup is not portable just a zfs snapshot.
To each their own I guess, maybe I do not use the data at such level that I’d see the advantage of the things you mention, but all of those I prefer to do manually in docker (vpn, reverse proxy etc).
No support from TC isn’t exactly better than possibly no support from iX (and no, chatting on discord ain’t support, issue on github is)
2 Likes
TC probably fits a lot of those needs, but I’m concerned with how proprietary it all is. As long as we’re doomsaying, TC could very, VERY easily tomorrow go “If you want to open your app PVCs, you have to give us 10 dollars a month” and blammo, your appdata is effectively cryptolockered.
This is complete and utter bollocks.
- Our complete common-library (the basis of our charts) has its complete source code available
- All Apps have their complete charts available as well.
- Helm-Charts are, in their essence, always source-available and plaintext
- The few containers we do build ourselves, also fully have their source available
- PVCs are an industry standard and are backed by OpenEBS, one of the biggest storage creators/designers worldwide
For full transparancy:
We do have 1(!) closed source tool that we use for our CI, of which the input and output are fully transparent available.
1 Like
Don’t get me started on TC, if anything breaks you’re SOL unless you wanna go on Discord,
We’re hard at work fixing that by spinning up our own infra and forum. But got distracted by the breaking changes of DragonFish and now Electric-Eel
changelogs are non-existent
We have had changelogs online for a long time, currently they indeed have been down for a while, due to technical scaling issues.
Luckily we’ve just rewrithen our changelog generation tooling from scratch so they should be online within a few weeks again 
2 Likes
That’s good to hear, sounds like a lot of movement in good direction! It’s always kind of disheartening when I update a TC app and then sit there while it’s deploying thinking “were there any breaking changes? what changed? who knows?” crossing my fingers it’ll go from yellow to green and I won’t have to rollback.
1 Like
I don’t like Discord in the least, but I’ve found very helpful support for TrueCharts-related issues there, even outside what’s officially supported.
1 Like
absolutely, here I am not disputing personal choices, I mentioned that anything can be done, in any way, if you know what you are doing.
and I am sure you are reaping the benefits of all the time you invested in your setup, that’s fantastic.
but here I am strictly speaking about IX-System decision from a technological and business perspective, not about how much this can annoy me (it really doesn’t).
At stakes here is the future Docker apps catalog and the UI integration: the added value (and IX development effort) is in those things, otherwise we would simply run Debian with Podman right? Even less overhead!
And I believe these challenges can be better served by Helm + k3s/k8s, now and in the future, for all the reason outlined in my previous comments.
As @dan brilliantly summed up:
this is the crux of the issue, together with ample room for future feature development (bells and whistles), better support environment to improve customer satisfaction, better integration with UI to manage your apps in even more detail (expanded batch actions, activity monitors, network controls, etc…) and possibly better documentation.
1 Like
Just to be clear: be sure to hard-refresh the page… there is a known issue where the status just doesnt update without a hard-refresh of the page, leading everyone to freak-out once-in-a-while thinking they are bricked 
1 Like
We try to have a pretty limited scope of support and over-deliver where we reasonably can. Instead of under-delivering where we should
2 Likes
Aye I know that lately I have to ctrl+f5 on a lot of apps not only TN, but I digress.
I was more thinking about all of the 2-3 times (meaning it’s minuscule but still annoying when it happened) it happened in years of using TC apps when an chart updated and was broken without any trackable issue and then got randomly fixed 2 releases later without any changelog made me so much more apprehensive for future updates.
This and the post by @dan are a great summary of why we think Helm is great:
It is a lot of work to maintain, but it also allows for development of cool new features…
Like our latest inclusion of VolSync based S3 backups, which would’ve have been possible without the full power of templating and all the cool tools that the kubernetes ecosystem has to offer!
We fully agree with giving users the option to use docker(-Compose) instead of custom App. But this heavy-handed solution of changing the whole backend, stiffles innovation and makes the apps system fully proprietary.
Whereas before it has been an open platform based on open standards.
3 Likes
right… let’s just throw away k3s because it didn’t have any value over plain docker (unless you used the plethora of handy options…) just for the “benefit” of encouraging people to blindly copy-paste crap into their system and wonder why something doesn’t work. yes it was “more” work to translate the values into something meaningful for a custom-app or chart, but understanding what you are actually setting up isn’t without value.
if ix-systems are going to put in lots of development resources it should’ve been towards integrating jails instead of constantly recommending it while keeping it outside of the system, making it “unsupportable”… hell LXC would’ve been a nice inclusion…
I used to say that truecharts and their PR problem were far beyond overblown… (like for example, their aversion to the reality that host path should be supported), their charts were at least reliable (more so then the ix-charts I tried to use anyways). but replacing the existing k3s with docker is just lunacy. you are shooting everyone in the foot in some way if they used anything but a completely trivial apps setup.
5 Likes
Am I correct in assuming the nightly version of SCALE 25 has this new “docker” instead of the old k3s?
Using Docker / Compose in a way that lets it be fully usable end to end is somehow proprietary? Not using open standards? Not sure what universe those comments comes from, but if anything it opens up open-standard doors compared to previous and to a wider audience.
But either way, I think this thread has really moved beyond the original discussion and diverged too much Lets try to stay on topic or open new threads if somebody wants to make the case the docker / compose are somehow closed and proprietary.
6 Likes