Hacker News new | past | comments | ask | show | jobs | submit login
TrueNAS will be moving to Docker Compose (away from K3s) (truenas.com)
33 points by thunderbong 3 months ago | hide | past | favorite | 9 comments



I'm glad. I installed about 20+ apps via k3s and they slowly but surely started to degrade. So I had to learn kubectl commands, it was a disaster. Then I migrated 60% of the apps to compose versions on a vanilla ubuntu 22.04 runing as a VM and everything is great. I have full control again. So I look forward to this change so I can remove again the VM and run everything alongside TrueNAS. For my use case is a great decition.


I understand everybody very reasonable complaints, in my case I have yet to move to scale (i'm on core) and I have good knowledge of compose, so this makes me very happy


This makes me glad I decided against using TrueNAS as an application host, and instead use it in a VM only for zfs and shares.


Changing everything again??? I wonder what paying customers think about this.

Im still on legacy freenas using jails...


I wonder what TrueCharts will do then.


Well. This sounds like it will be exciting to upgrade to.


Oh for fucks sake…

Let’s reengineer the entire system… AGAIN…

Instead of blessing an existing tool that would have instantly solved the problem their customers had, without requiring internal development… https://kompose.io … tada… it’s a tool the kubernetes community maintains to convert from docker compose files to kubernetes yaml

The team behind TrueNAS (iX Systems) has been steadily eroding the respect I have for them on a year on year basis for half a decade… which is really annoying because they make and maintain the easiest to use ZFS based NAS platforms.

It’s genuinely frustrating that like “how long before they kill it” being my reaction to anything new from Google, my reaction to iX Systems announcing something like this has become an automatic “yeah and what are you changing next?”

Also… what the fuck is anyone doing using Docker Compose in this day and age… I see two scenarios “enterprise retraining costs” and “home users who think kubernetes is just so much more complicated than compose files and they don’t want to learn a new tool when they’re just slapping a database container next to their docker container for this years automated piracy or media management tool of choice”… and in both scenarios management should have asked the crucial question “do we actually need to do anything to support them?” You ask this so you can decide if changes are justified, and by asking this… this is the question that lets you discover ways to leverage third parties to support use cases and save yourself a lot of stupid effort.

My day was off to such a good start… damn it… now I know this fucking update is in my future… maybe this will be the final push and I just fucking buy a Qnap because I’m sick of what feels like every second major release of TrueNAS significantly overhauling things in a way that seamlessly works with my data on disk, sometimes wont break 80% of the software running on the box to interact with that data, and just about always breaks 20% of that software… and having that 20% of software that breaks every time, be the most fucking annoying stuff to fix.


Your frustrations of disrupting users is completely understanding, but couching it in “what’s wrong with people who use ____” ain’t it.


Docker compose files have been treated like legacy technical debt in a lot of places and the availability of tools to easily convert them, has lead to the current situation where basically I only see new docker compose files used by themselves in hobby and amateur projects with any reasonably organised project making the jump to at least publishing both the compose AND the helm chart or kompose template driven kubernetes configuration files… the hobbyist use i have not qualms with, use what you want to use for your own stuff, but a large portion of the use of docker compose in this particular NAS as host ecosystem is using shared application deployment configurations to make it easy to start up things like Plex or qtorrent or NextCloud. These are organised efforts where people post files to indexes to make them easier for others to find, and the greater rigour of a kubernetes config is actually a good thing in this environment… but it’s more work and a lot of the time I have seen the kind of complaints the users make and the bar to entry is very low for these things… I remember when the only way used to be templated FreeBSD jails… and now they are telling the company a kubernetes config is too hard… I don’t care what they want to use in their own home lab, I care about how hard it is to fix when their poorly written docker compose file breaks… how hard it is to maintain my system security now that we’ve thrown out the more comprehensively documented security architecture of kubernetes for the docker compose world with a much less rigorous security story…

This is a step back and the users are in this case wrong to have wanted it. I’m expressing the same sentiment you might have if you found someone was lighting their house with whale oil powered lanterns for the last year… it’s not that it doesn’t light the house… it’s just a very damn strange way to light a house in the 21st century.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: