Requesting docker-compose example

[inman.turbo]

I'm curious what would have made such a hypothetical person think this.

Lol

 

[ornias]

Lol

You can "Lol" all you want, but never did iX actually say it would support docker-compose. ;-)

 

[morganL]

It does raise an interesting question though...`I can already set up a VM on TN CORE to do this so... why invest any time on SCALE?'

That's OK with us that someone who only needs docker and TrueNAS uses CORE. However, with time, we would expect SCALE KVM to be more robust and for there tom be better scale-out capabilities.

 

[jct]

Slight note: plain 'ol helm chart installations also run perfectly fine ;-)

Do they? That's great news! I'd gotten the impression that this door was intentionally closed with the API endpoint.

Basically: Instead of `Helm install`, one requests SCALE to execute Helm Install for them. Thats really all there is to it.

Ah. OK. For my case that's doable for in a `.gitlab-ci.yml` but I'll note that it still presents as unnecessarily off-putting. A bit of a code smell. Maybe one that could be patched over with top notch documentation. What would you say is preventing a more native interaction? Or put another way: what do we gain by detouring around one?

Speaking for myself, I'm still having trouble grasping Helm. (Once you add deep remote dependencies and arbitrary templating, aren't you giving up on declarative infrastructure?) But I do know I need to get there. That's on me.

At some point I'll get there. Despite all the conflicting advice and misdirection at each turn. I'm encouraged to hear that once I do, I won't be required to learn yet another abstraction/framework on top of that just to create a weird new wrapper for some reason. I might be allowed to walk before I run — just for some reason not to roll or crawl first even to reach that stage. At least not with my own multi-container projects.

Anyway:
Like I said in another thread: If iX all of a sudden starts to offer alternative solutions to their Apps system, I wouldn't even be interested in maintaining TrueCharts. It's basically LOT of hours which I spend on it just to make SCALE more accessable for average users.
Allowing other solutions means I spend said time for a significantly smaller audience, which isn't worth it for me.

I feel you, believe me. My people haven't even accepted yet why I'm goading them to embrace basic revision management and rollback, just to cut back on infighting if not to unlock hidden creativity.

But with my admiration and gratitude: wouldn't it be better if the platform didn't need a benevolent gatekeeper agreeing to translate the broader ecosystem into some inscrutable multilayered bespoke framework for everyone? Wouldn't that be a priceless force multiplier, even for your own continued participation?

People tend to take things for granted, which is awesome ofcoarse. But i've no interest at all to write things that need to compete with docker-compose, portainer or something else. If iX wants to go support it, they can ofcoarse, but I won't be doing any voluntering in the future for their systems if they go that route.

To be clear:
I do not see this happening anytime soon, but just want to make clear there are more consequences than people tend to take into account.

You're doing everything you can, and I wouldn't have you change a thing on my behalf. Also IMHO: iX has picked the right strategy and executed steadily well toward it. They still have some release cycles ahead with which to explain their vision of hyperconvergence to us in a way we might recognize.

In the meantime: I'm flailing to figure out what I still need to learn in order to make any of this useful to me. Ideally to then reach back and contribute, myself.

But I haven't yet found a baseline upon which I can iterate, test, and build from there. I need a better starting point.

Given your helpful nudge, I'll go hunt for a clean, disentangled Zen of Helm manuscript. Cheers!

 

[ornias]

Do they? That's great news! I'd gotten the impression that this door was intentionally closed with the API endpoint.

Yes, native helm commands work out-of-the-box. However: I would suggest not installing anything that interferes with the default containers and staying away from any namespace prefixed "ix-*"

Ah. OK. For my case that's doable for in a `.gitlab-ci.yml` but I'll note that it still presents as unnecessarily off-putting. A bit of a code smell. Maybe one that could be patched over with top notch documentation. What would you say is preventing a more native interaction? Or put another way: what do we gain by detouring around one?

Okey, but for those cases you have native Helm access already.
Want to play with Helm Charts -> use Helm directly
Want SCALE to manage your storage and versioning? -> Write own apps

We gain automatic snapshotting, rollback and a GUI.
If you don't want that, just use native helm and be done with it.

Speaking for myself, I'm still having trouble grasping Helm. (Once you add deep remote dependencies and arbitrary templating, aren't you giving up on declarative infrastructure?) But I do know I need to get there. That's on me.

Thats what SCALE Apps are for: People that have trouble grasping helm and want their hands held.

About declarative infra: No it's not giving up on that, you can change all settings (if exposed in values.yaml) for all dependency and their dependencies as well)

But with my admiration and gratitude: wouldn't it be better if the platform didn't need a benevolent gatekeeper agreeing to translate the broader ecosystem into some inscrutable multilayered bespoke framework for everyone? Wouldn't that be a priceless force multiplier, even for your own continued participation?

Helm is an industry standard framework and the only thing really bespoke is the GUI.
Okey: certification injection is also somewhat(!) bespoke and rollback is only available if you use iX's storage class.
Anyway: Only the options not offered by Helm are bespoke. And even so: they are still fully Helm-compatible.

People keep acting like Apps are something super special. They are NOT.
They are JUST Helm charts for about 98% or so.

You're doing everything you can, and I wouldn't have you change a thing on my behalf. Also IMHO: iX has picked the right strategy and executed steadily well toward it. They still have some release cycles ahead with which to explain their vision of hyperconvergence to us in a way we might recognize.

True Hyperconvergience will not even make the initial SCALE release (as it has no hyperconverged clustering of compute yet)

In the meantime: I'm flailing to figure out what I still need to learn in order to make any of this useful to me. Ideally to then reach back and contribute, myself.
But I haven't yet found a baseline upon which I can iterate, test, and build from there. I need a better starting point.
Given your helpful nudge, I'll go hunt for a clean, disentangled Zen of Helm manuscript. Cheers!

For using SCALE: Nothing, it's all in the GUI or in our TrueCharts quick-start guides which are releasing daily for comming week.

For contributing to TrueCharts:
- To create simple Apps, it's mostly copy pasta without much "real" helm knowhow required. As most templating is abstracted away in our common chart
- To work on the TrueCharts common chart: months and months of Helm study. I suggest staying away.

 

[inman.turbo]

We gain automatic snapshotting, rollback and a GUI.
If you don't want that, just use native helm and be done with it.

This. Right here. Why isn't it common knowledge? I had no idea this was possible. I guess I should have just tried it. We already have a csi we use for free/true nas.

 

[ornias]

This. Right here. Why isn't it common knowledge? I had no idea this was possible. I guess I should have just tried it. We already have a csi we use for free/true nas.

I think I said so already 6 times the last 2 days and created resources+examples about how one could install things like Flux or ArgoCD. I don't think it's that unfindable ;-)

It's also what @morganL is refering to when talking about Kompose to migrate from docker-compose to Helm, because even having a Helmchart doesn't magically turn it into an App

Should be more clear in the manual though, which i've already reported to iX.

 

[jct]

Yes, native helm commands work out-of-the-box. However: I would suggest not installing anything that interferes with the default containers and staying away from any namespace prefixed "ix-*"

Outstanding. Thank you!

If this manages to bubble up in the documentation sooner than later, I'm sure it'll spare everyone more infuriating rounds of whats-the-point confusion.

We gain automatic snapshotting, rollback and a GUI.
If you don't want that, just use native helm and be done with it.

This — I'm sorry; I missed it the first time you said that to me. GUI aside for now, let me check my understanding.

It sounds as if I'm about to learn that "helm upgrade" and "helm rollback" don't interact with volume snapshots at all. If true, wouldn't the best place to address that be through a Helm plugin?

And speculatively: at some point you expect to see a here-be-dragons checkbox reopening the Kubernetes API endpoint to the native Helm client — potentially with authenticated roles and restrictions as future guard rails to make that supportable? If not, how would you characterize "using native helm" more precisely?

Thats what SCALE Apps are for: People that have trouble grasping helm and want their hands held.

Well... for the greater subset of those. People who want to pull preconfigured COTS apps, whether for the training wheels or for no-hassle support. And even those two audiences don't have as much in common as it'd be convenient to assume.

In my case I'm reserving judgment on whether that remarkable wall of icons I've never heard of, with nary a vowel between them, contains anything of value to me. I'm sure there's some overlooked gem somewhere in there, but until I can find the synopses of any two entries in one place less than three clicks away from each other... I'll continue to bite my tongue and focus on my task at hand.

My task at hand is to provide TrueNAS storage to a homelab-sized cluster for small workgroups dabbling in shallow depth DevOps. Including my own wacky custom home automation. Nothing generally available, but all living/breathing local code with a few integrations to some recognizable brands.

So the reason you're my hero here isn't your work product per se but the insight and methodologies you've brought to the challenge. I need your help to "see the Matrix" — not to crouch here and beg for it to be packaged to go.

About declarative infra: No it's not giving up on that, you can change all settings (if exposed in values.yaml) for all dependency and their dependencies as well)

Oof. Agree to disagree. For a generation which grew up on Rails and npm, anchoring every new project in fast-breaking codegen spellcasting and deep supply chain exposure: arguably they're less about writing code, and more about baking it.

Pro tip: once a community lumps on precompiler looping and conditionals, their supposedly declarative descriptor language has jumped the shark. More charitably: it becomes something other. With gains, yes, but also sacrifices.

Helm is an industry standard framework and the only thing really bespoke is the GUI.

People keep acting like Apps are something super special. They are NOT.
They are JUST Helm charts for about 98% or so.

Right. Yes! That's what brought me here. Then somehow I picked up on a tone and tenor suggesting that this will be the only form of access going forward.

Me, I need my CI/CD scripts to dynamically add and remove custom projects for testing, staging/review and production. Ideally without complication from unnecessary middleware.

Okey: certification injection is also somewhat(!) bespoke and rollback is only available if you use iX's storage class.
Anyway: Only the options not offered by Helm are bespoke. And even so: they are still fully Helm-compatible.

For contributing to TrueCharts:
- To create simple Apps, it's mostly copy pasta without much "real" helm knowhow required. As most templating is abstracted away in our common chart
- To work on the TrueCharts common chart: months and months of Helm study. I suggest staying away.

Right. It's that framework which most urgently warns us that we're stumbling into xkcd 927. And I'm OK with that, as long as there's a way in for custom development that doesn't require command of the full Matrix from day one.

100% sincerity: thank you for helping to puzzle this out with me. I know I'm the better for it, and I suspect that the 2021-08 beta docs and discussions will benefit some as well.

 

[ornias]

It sounds as if I'm about to learn that "helm upgrade" and "helm rollback" don't interact with volume snapshots at all. If true, wouldn't the best place to address that be through a Helm plugin?

Afaik there are a lot of caveats in that process iX has fixed for you. That being said: When using helm outside of the SCALE API, you need to provide your own storage plugins and such.

And speculatively: at some point you expect to see a here-be-dragons checkbox reopening the Kubernetes API endpoint to the native Helm client — potentially with authenticated roles and restrictions as future guard rails to make that supportable? If not, how would you characterize "using native helm" more precisely?

Native Helm aka `helm install`, is already 100% enabled.

In my case I'm reserving judgment on whether that remarkable wall of icons I've never heard of, with nary a vowel between them, contains anything of value to me. I'm sure there's some overlooked gem somewhere in there, but until I can find the synopses of any two entries in one place less than three clicks away from each other... I'll continue to bite my tongue and focus on my task at hand.

There is a search box to search for your favorite applications and we do take suggestions/requests as well. We're not there to help you discorver applications, we're there to supply them ;-)

My task at hand is to provide TrueNAS storage to a homelab-sized cluster for small workgroups dabbling in shallow depth DevOps. Including my own wacky custom home automation. Nothing generally available, but all living/breathing local code with a few integrations to some recognizable brands.

Yeah, Apps aren't very well suited for living/breathing code.
Though it can be done for sure, for example: By creating an empty app containing a pre-configured helm-chart. But in those cases native Helm might be a lot more efficient (or Flux/ArgoCD)

So the reason you're my hero here isn't your work product per se but the insight and methodologies you've brought to the challenge. I need your help to "see the Matrix" — not to crouch here and beg for it to be packaged to go.

There's no shame in asking for thing to be packaged!
But yes, the challanges in building TrueCharts is primarily understanding "the bigger picture" and how certain things affect eachother, while putting on-and-off different "glasses" to understand what different usergroups might want to do.

That's also how I try to pick the general direction of TrueCharts: True to gain insight in what different users might want, even going as far as building demo setups. Based on that, one could asses weither a certain audience fits within a certain scope :)

Oof. Agree to disagree. For a generation which grew up on Rails and npm, anchoring every new project in fast-breaking codegen spellcasting and deep supply chain exposure: arguably they're less about writing code, and more about baking it.

Pro tip: once a community lumps on precompiler looping and conditionals, their supposedly declarative descriptor language has jumped the shark. More charitably: it becomes something other. With gains, yes, but also sacrifices.

I actually agree for a bit, for as far as this applies to App repositories. A few days ago we encountered weird permission behavior in a postgresql dependency, which for 80% contained code we would never use.

So I've kinda decided to move away from external helm dependencies and keep things inhouse as much as reasonable. It would hopefully limit having to bugtrace 1000 dependency changes...

Right. Yes! That's what brought me here. Then somehow I picked up on a tone and tenor suggesting that this will be the only form of access going forward.

It's sad and funny at the same time to see how a tone from some members seems to give people the assumption that something should be wrong, where in fact there isn't really something significantly wrong but they just donnot agree with certain design choices. Which is fine ofc, but it creates a quite negative narritive.

Me, I need my CI/CD scripts to dynamically add and remove custom projects for testing, staging/review and production. Ideally without complication from unnecessary middleware.

Yeah things like ArgoCD or Flux and such are better suited for your workload indeed, which is completely fine :)

Right. It's that framework which most urgently warns us that we're stumbling into xkcd 927. And I'm OK with that, as long as there's a way in for custom development that doesn't require command of the full Matrix from day one.

Well, actually iX just injects some extra values into native Helm... so technically they comply to the Helm standard, hence xkcd 927 doesn't apply ;-)

100% sincerity: thank you for helping to puzzle this out with me. I know I'm the better for it, and I suspect that the 2021-08 beta docs and discussions will benefit some as well.

As the docs are altered directly, don't expect much different docs from iX for 21.08 BETA ;-)

 

[jct]

Afaik there are a lot of caveats in that process iX has fixed for you. That being said: When using helm outside of the SCALE API, you need to provide your own storage plugins and such.

I look forward to understanding why a default storage provider couldn't be preconfigured, whether on volumes or datasets.

Native Helm aka `helm install`, is already 100% enabled.

But only via localhost, correct?

Yeah, Apps aren't very well suited for living/breathing code.
Though it can be done for sure, for example: By creating an empty app containing a pre-configured helm-chart. But in those cases native Helm might be a lot more efficient (or Flux/ArgoCD)

If only because there'd be trouble with multiple instances, e.g. a review deployment being vetted to replace production.

I'm working through the process of adding democratic-csi to my HA K3OS cluster. Having GitLab perform a "helmfile sync" with every git checkin to manage necessary infrastructure. If I knew where the bodies were buried, I see no reason why I couldn't tailor a specific SCALE-savvy Cluster Management Project Template for people to use mostly as-is, or to build on. Maybe I should jump on JIRA and/or Discord.

So far, GitLab has been a dream to manage in Debian VMs through many cycles. No Nextcloud-style shenanigans. But after I began settling in, they put a lot more muscle behind cloud-native chart based deployments.

I personally intend to stay with the Omnibus package on Debian until SCALE reaches cluster compute stage. (I do use it to manage my cluster, rather than the other way around.)

But eventually I see GitLab as a compelling example of a major prepackaged App(liance).

One that could even drive some iX hardware sales? On-prem dev lab in a box...

 

[Yorick]

It does raise an interesting question though...`I can already set up a VM on TN CORE to do this so... why invest any time on SCALE?'

One possible reason could be because bhyve has quirks, one of those quirks being to sometimes refuse to start a VM up again when the VM gets rebooted: And ix just recently, and wisely, closed that Core ticket as wontfix, because they don’t have the bandwidth to fix upstream bhyve.

I’ve been pretty happy with Core, but I’m looking forward to see what Scale has to offer. A better-supported (because more widely used) hypervisor will be welcome.

 

[Stux]

It is a fair question. Especially if the OP was only considering SCALE because they thought they would have a simple 1:1 api for running docker-compose scripts.

and I was considering scale so that I'd be able to use docker-compose apps without having to NFS share a dataset into a VM.

I'd just like to be able to ssh into the NAS and do "docker-compose up -d" in the right directory... Is this impossible with SCALE?

 

[Basil Hendroff]

@Stux The thread VHS or BETA? has more information and may be of interest.

 

[Ixian]

and I was considering scale so that I'd be able to use docker-compose apps without having to NFS share a dataset into a VM.

I'd just like to be able to ssh into the NAS and do "docker-compose up -d" in the right directory... Is this impossible with SCALE?

The short answer is yes (that you can do it, not that it's impossible :) ). This is how I do it:

1) Don't set an pool for Apps, or un-set the pool if you have set one (keeping in mind of course that this means you won't be using Apps at all; you'll be ignoring that section of the GUI). This disables the Kubernetes service(s).

2) Create a new dataset you want to use for a separate docker pool - I created one called "docker" on my mirrored ssds. If you want to use bind mounts for persistent container storage it's probably a good idea to set up another dataset for those too (I created one called "appdata"). Note that you should set up your own periodic snapshot task(s) for these per normal in the GUI (under Data Protection) so you can do rollbacks, etc.

3) Create a docker user that's a member of the (built in) docker group. Basically, follow the same best practices here you would for any docker environment.

4) (Optional) I add a second ip to my TrueNAS SCALE deployment and bind docker (more specifically, docker networks) to it; that way you don't run in to port conflicts with the main host. Google
driver_opts: com.docker.network.bridge.host_binding_ipv4:

For more pointers (it's dependent on what network type you use and how).

5) This next part may not be necessary, long term, and could be viewed by some as a hacky workaround, but it works - basically, you need script that replaces the default daemon.json for Docker with your own and restarts the docker service on reboot. This is because (currently) that file gets over-written on system updates and reverts to the default which essentially disables networking for the docker stack (because with K8s it isn't used).

This one: https://gist.github.com/Jip-Hop/af3b7a770dd483b07ac093c3b205323f works fine and is self-explanatory. Save it in a directory outside your docker pool alongside your own daemon.json file and set it to run in the TrueNAS GUI as a pre-init script (System Settings>Advanced>Init/Shutdown Scripts).

Note if you want to do Nvidia GPU passthrough that same daemon.json file is what you would edit to add the nvidia runtime (per standard instructions - just follow any decent guide on getting GPU passthrough working with Docker, it's simple).

And that's it, basically. Put your docker-compose file in your docker pool root as normal, configure your environment/paths/etc. as normal, and off you go. It works great. I have 26 containers fronted by Traefik running right now.

I'd really love it if, among all the debate and drama, we could just get a simple option to do this without workaround. It's *still* in the dev notes:

• SCALE allows Kubernetes to be disabled. The user will then have access to the native container services within Debian. This will include Docker, LXC (Q1 2021) or any other Kubernetes distribution. There will be a Container Storage Interface (CSI) that can couple the container services with the SCALE storage capabilities. Users can script these capabilities and then use 3rd-party tools like Portainer to manage them. This approach can be used in SCALE 20.10 and later.

/scale/

I don't know if that has changed behind the scenes or if it is still the plan but I think a lot of users would be happy if we could, without using daemon.json/etc. workaround, disable Kubernetes as stated and use our own docker setup/daemon. I don't expect Ix to support it and frankly they don't need to because there are a million resources to help with docker, compose, and swarm.

If anyone wants more help with this, feel free to PM me. If anyone has constructive advice on how to do it better, happy for the help.

 

[Basil Hendroff]

I don't expect Ix to support it and frankly they don't need to because there are a million resources to help with docker, compose, and swarm.

I've seen several posts in relevant threads that are along the lines of 'just because you can do it, doesn't mean it's supported'. This is really quite discouraging and unhelpful. Where there's deeper integration with the filesystem e.g. volume bind mounts, I'd feel a lot more comfortable if I knew iX at the very least supported Docker-Compose natively.

 

[Ixian]

I've seen several posts in relevant threads that are along the lines of 'just because you can do it, doesn't mean it's supported'. This is really quite discouraging and unhelpful. Where there's deeper integration with the filesystem e.g. volume bind mounts, I'd feel a lot more comfortable if I knew iX at the very least supported Docker-Compose natively.

Yes, there's a certain amount of FUD going about (may not be intentional) regarding this. By "support" I meant, of course, that I don't expect customers with paid support be able to demand Ix fix why they can't get <x> container working with compose, and so on.

 

[ornias]

The short answer is yes (that you can do it, not that it's impossible :) ). This is how I do it:

1) Don't set an pool for Apps, or un-set the pool if you have set one (keeping in mind of course that this means you won't be using Apps at all; you'll be ignoring that section of the GUI). This disables the Kubernetes service(s).

2) Create a new dataset you want to use for a separate docker pool - I created one called "docker" on my mirrored ssds. If you want to use bind mounts for persistent container storage it's probably a good idea to set up another dataset for those too (I created one called "appdata"). Note that you should set up your own periodic snapshot task(s) for these per normal in the GUI (under Data Protection) so you can do rollbacks, etc.

3) Create a docker user that's a member of the (built in) docker group. Basically, follow the same best practices here you would for any docker environment.

4) (Optional) I add a second ip to my TrueNAS SCALE deployment and bind docker (more specifically, docker networks) to it; that way you don't run in to port conflicts with the main host. Google
driver_opts: com.docker.network.bridge.host_binding_ipv4:

For more pointers (it's dependent on what network type you use and how).

Simple version with less hacks:

1) Set apps pool.
2) Create script that replaces the default daemon.json for Docker with your own and restarts the docker service on reboot. This is because (currently) that file gets over-written on system updates and reverts to the default which essentially disables networking for the docker stack (because with K8s it isn't used).

I'd really love it if, among all the debate and drama, we could just get a simple option to do this without workaround. It's *still* in the dev notes:

/scale/

Yeah this is REALLY stupid. I've tagged their executives about 50 times last year to change these references to reflect their actual goals as they state here and privately and they just /care about it.

I've the feeling some docs team member misinterprented something someone else explained and no one cares to correct it.

I don't know if that has changed behind the scenes or if it is still the plan but I think a lot of users would be happy if we could, without using daemon.json/etc. workaround, disable Kubernetes as stated and use our own docker setup/daemon. I don't expect Ix to support it and frankly they don't need to because there are a million resources to help with docker, compose, and swarm.

I've talked with that option a few times during SCALE development.
The problem is: Users don't actually understand what "not supported" means and still file for support, blame the product or the company if it doesn't work as they expect. Even if they say they understand, in practice they don't.
Adding the fact that users requesting such features are either free users or an insignificant income source, I completely understand that iX is hestitant doing this.

I've seen several posts in relevant threads that are along the lines of 'just because you can do it, doesn't mean it's supported'. This is really quite discouraging and unhelpful.

That would be me.
I'm not saying that it cannot be done and shouldn't be done. But, like I explained multiple times already, there are a LOT of cases where new users get this as an advice without the added caveat of it not being supported.
People need that information tidbit to make an INFORMED decision.

Yes, there's a certain amount of FUD going about (may not be intentional) regarding this.

Yes, there's a certain amount of FUD going about regarding this. There should be when hacking things into an appliance OS.

It blows my mind how home-users have a tendancy to get up on a high-horse and shout FUD FUD FUD, to everyone who tries to inform OP's about possible downsides of a choice he or she is about to make.

Where there's deeper integration with the filesystem e.g. volume bind mounts, I'd feel a lot more comfortable if I knew iX at the very least supported Docker-Compose natively.

I agree with this.

iX is obviously not willing to nuke their Apps ecosystem. Which will be the direct result of supporting docker-compose as well. How do I know? Because the same thing mostly killed their plugin system already.

 

[Ixian]

Simple version with less hacks:

1) Set apps pool.
2) Create script that replaces the default daemon.json for Docker with your own and restarts the docker service on reboot. This is because (currently) that file gets over-written on system updates and reverts to the default which essentially disables networking for the docker stack (because with K8s it isn't used).

I don't know that setting up different pool is considered "hacky" - mainly I just wanted to avoid the default ix-applications pool so nothing got over-written. It also seems to be an easy way to disable all kubernetes related services since they won't start without a default pool. Am I looking at this wrong?

 

[ornias]

I don't know that setting up different pool is considered "hacky" - mainly I just wanted to avoid the default ix-applications pool so nothing got over-written. It also seems to be an easy way to disable all kubernetes related services since they won't start without a default pool. Am I looking at this wrong?

The ix-applications pool is actually not that special. It's a docker container store, k3s config store and it stores PVC data (if used).
However: by setting the pool, you basically got somewhat close to a "technically supported" docker-compose deployment. Because iX maintains the docker setup for you.

There aren't many k8s related services luckily. There is k3s, which is basically doing nothing, the inflight datastore (which is mostly empty) and a CSI that has nothing to do. Thats a few containers at best that are sitting idle waiting for any activity.

It has more overhead for sure, but i've been running/testing this for about 10 months now and it works briliantly even cross updates. So I can somewhat guarantee it works

TLDR:
The more you change, the more can break imho.
But in this case that really is more of a "tastes can differ" thing... :)

 

[jct]

Simple version with less hacks:

This has the added benefit of being an on-ramp. We could all point to a FAQ or a blog post or a pinned thread showing how to bring over your Docker Compose apps for now, while you're learning how to migrate them one-by-one into Helm charts.

A Docker deployment will be limited in key ways, and could require additional ongoing hacks and troubleshooting. But it'll get certain users quickly up and running suitably well while the platform, the ecosystem, and their own skillsets catch up to expectations.

See also: companion articles on how to set up any VM or nearby host or cluster to leverage TrueNAS (any version) for its storage in a fully supported way.

I suspect that users are prepared to hear that. And that experts would be relieved to have that matter of diplomacy on hand in one place whenever a link is needed. But it won't have nearly the impact if it doesn't come straight from iX.