Some of you may arrive at the conclusion eventually, some of you may be dealing with it now, and some of you may never need it. But Techno Tim (a pretty slick YouTuber) just released a nice workflow, marrying any Docker image with Truenas, leveraging the power of datasets and hand-coding custom app configurations to run anything you want. With his workflow you get to spin up custom docker apps that work in a friendly way with truenas storage and networking, show up about 95% right in the Apps tab, and are easier to maintain than dockge.
Long story short, check out his video. He makes difficult stuff easy to create and maintain. An install of visual code server is included for maintaining future configs without ssh or fighting with the web shell. But the magic is how it’s all done start to finish. One tweak to make note of is that the Truenas Scale way is uid gid (apps:apps) and that’s 568:568 wherever he references permissions.
My 2 cents: i totally agree that the GUI docker experience with TN Is poor (tested at beginning of EEL, going back to Portainer after 2 days); i have also to admit that i didn’t know that Is possible to reference to a YAML file just using include **file path*, skipping totally to use the form (that also manipulate your content, and at least at beginning causing sometimes errors).
So the main gain Is to see/manage all your apps in TN GUI avoiding much possible the use of the custom app builder, in benefit of vs code… But i don’t see anything more than that. I don’t think that people using dockge and Portainer will switch to this solution anyway if not interested to see theyr app on TN, because they provide other tool to manage containers that this solution not cover.
It’s not just poor IMO; it’s straight-up bad. Poor is when there were not enough resources/efforts to bring the UX to a certain level. Truenas, for one, removes commentaries from “compose files”. So, the devs made active efforts (implementing “truncate” on the input) to make the UX worse.
Well probably i took It easy because was just released, couldn’t ask too much, but if the situation Is still the same hard to not agree
Comment removal was (Is?) annoyng, but the fact that i put a valid YAML - the GUI raise an exception and prevent to deploy after have made his magic was unneceptable to me
I suppose I should watch the video, but I’m wondering how this would be the case–other than that stacks I deploy via Dockge don’t show up in the UI. There’s nothing to do with networking (I don’t have any use for individual app IPs though), host paths are trivial, and everything’s stored on disk in plain text that I can trivially back up to a Forgejo repo and move somewhere else if/when I need to.
Probably stole my idea I posted long ago on using include.
For me, the fact that updates or really anything shows up in the Truenas UI when using dockge makes it a no go, that’s why I went the way I did no matter what it took. That’s a huge limitation to me. Dockge also doesn’t support compose files in subfolders, and, more importantly, docker secrets. It’s another piece to manage.
Of course the scale method had limitations. By using include though, you solve backup issues (not in .ix-apps), allows env files on Truenas which didn’t really work so well before, updates even with rebuilds via Dockerfile when you have truly custom apps, organizes them as you see fit, allows development elsewhere (not on Truenas) to test, and then deploy to Truenas as is, and it’s one less thing to learn and manage (no dockge).
OTOH - you edit those files on truenas unless you simply make a share for them so your client can do so.
So we can assume that the game changer here Is have app available in truenas UI or not, right?
But relatively to this, to understand if i’m missing something obvious… What Is the pro of that?
As far i remember, there Is nothing more than start/stop/update container, poor stats, if you want a custom icon you still need to manually set It on the metadata file, the update Is still manual (ok, with notification)… What i’m missing?
It’s just a way to manage non-native apps while still tracking stats in the apps list and getting notified of updates. He goes through the pros and cons of different methods. Also it’s easy especially after codeserver is up.
Edit: sure enough one of the apps I deployed this way had an update today. Showed in the ui but couldn’t tell me anything about versions so I blindly deployed that. It worked. Still doesn’t tell me which version it is but truenas is caring for it.
The pro for me is what I explained in my last post, there is no pro to dockge for me, you of course may have a different view, nothing wrong with that, options. What is the pro for dockge? An extra app, so, better be super useful. People point out many things but they are all meh for me. I’ve used docker a long time and native docker is what I do.
What have we seen in the last few years. People were running truecharts (was that the name?), then it was going away. So, they said gee look at fancy new nspawn, let’s convert to that! When they could have just done custom apps and docker images under kubernetes. So, then truenas went to docker, so, instead of docker, they said let’s convert from nspawn to dockge. Now, I see all sort of posts from people who plan to move from dockge to native once truenas makes a few changes perhaps in the next version, so, a third conversion. Or, some say they want to use the new fancy instances, might even be a 4th conversion. Why all the messing around is my question! I started with docker and still have docker. Without the (in my view) needless addition of dockge and various conversions and time spent.
That’s my view. I see stuff I need in the UI, updates, network stats, memory stats. Don’t care about anything else. I want to use the tool I have. Ymmv. This really isn’t to convert anyone to truenas from dockge. It’s for those that don’t want another tool and possibly conversion. It removes most of the limitations of the current truenas.
Yeah, I don’t do that at all! I typically tag them not with latest, maybe with the same version, etc. I will not blindly update mariadb for example to whatever the next major version is, that needs to be an intentional controlled update. For example, homeassistant doesn’t like newer versions.
My question was really “genuine” to understand other point of view, sometimes i tend to continue doing things in one way only because i’m used to it, and this discussion sparked my interest again on that topic.
I use Portainer (not Dockge) from the migrations of Core jails, and the only thing i didn’t like from beginning was the native backup solution that not preserve stack name on It: imagine mess up with a YAML, for avoid a total restore you have to open each file to find the one you need… So i have built my own one click solution that retrieve stacks via API - save to disk - store where i want - and i’m happy again
Probably not the most fitting example (solved a “self” problem xD ) but having this layer of API Is something most will find useless, for me Is a nice have (still to explore to understand how can improve my experience).
If we move to
without be rude vs ix, i just wanna say that they made things hard for many users with theyr decision
Yes they (formerly ix) did, but, users made it hard on themselves too by messing around and just having to go to the latest “it” thing too, then posting endlessly about how do I install or configure the extra tools like npawn, dockge, maybe portainer, now the new instances, etc. But yeah, do what works for you.
I develop my yaml more like one might do at work. So, on a client machine, I play with it until it works. Then I deploy it. So, it works of course. I can’t really mess it up. Well, there’s probably always a way. So, better or easier error messages, irrelevant for me as there are not any. I would never develop stuff on Truenas myself.
Yes, the technique noted in this thread makes it pretty easy to recover from a failure and all compose files are backed up. Literally a couple minutes for 24 apps if I lost the app pool.
If you like portainer, use it. Sounds like you are not one of those folks always chasing the latest and greatest! And you use the api, that’s great. I use it too for various things. Makes things a lot nicer as you say.
I gave up on allowing TN to handle docker years ago before the “app” store. I have been running docker in a Linux VM within TN. It’s been flawless, and I never have to worry about anything on the TN side aside from it being able to run a VM.
Did that in Core for years and really only moved to scale because apps looked more promising. Extending truenas has always been tricky with the plugins then kubernetes now docker.
Don’t get me wrong. I have a test box and can do reckless things I don’t understand on it. Not blindly updating in production, I don’t need the drama.
So, better or easier error messages, irrelevant for me as there are not any. I would never develop stuff on Truenas myself.