I’ll be periodically posting updates on where the Apps frameworks is at in our upcoming Electric Eel Nightly Images (24.10). As of right now, we’ve begun the work to replace the k3s backend with Docker / Compose. The first major commit in that effort has landed:
As a result, we expect nightly images / Apps will be broken for a short while as we finish all the related work and cleanup other dependent repositories. Users running nightly images may wish to hold off another few weeks until we sound the “All Clear” that it is safe to update again.
Additionally we’ve started on our new Compose “Apps” repository, which is where all the pre-built Applications will live long term. (Our equivalent of the Helm Charts repository). This will be getting some rapid updates over the course of June, and we’ve added a tracker to the Readme so you can monitor as new apps get merged.
I don’t see Docker Compose as a step forward from k8s.
WTF
Perhaps you should have have added a config checkbox to select between k3s and docker compose Apps backends, and watched which of the two survived. Its not hard to predict the outcome. Anyway, the only problem with k3s based Apps in Truenas was in the way it was exposed for configuration. It’s like Truenas SCALE was never really invested in the concept of using k8s natively.
Thank you for the updates on this huge undertaking Kris.
I run all my non-multi-container apps as custom apps to avoid being reliant on someone else updating a Helm Chart for compatibility (I thankfully didn’t get to the point where I had my own helm chart repo…) I’ve seen (and you are now documenting) how several of the built in apps will migrate to “static” pre-provided repo of compose files, and helpfully noted the transition for these should be smooth on upgrade.
Any thoughts on how custom apps will migrate? I basically had to take my self-maintained docker compose files and hand work them into custom apps, so I don’t mind rebuilding them I guess since I used host path storage for everything.
Also, sort of random note, I’d love an easily cloneable “Example/Blank” github library that I could add my customized compose-based apps to. I was headed down that path with Helm charts but there wasn’t a good clean starting point with just a single app example. This new format looks much simpler, maybe accommodates that more easily? Perhaps the GUI will mean I don’t care/ need that though and you won’t support external libraries?
Either way, appreciate the updates as the process moves forward, I think for the scope and userbase you’ve seen embrace scale this makes a ton of sense, and I look forward to the increased demand for a jailmaker UI from Kubernetes users.
If you used the “Custom App” button in the UI to deploy something manually, those should all migrate over to a Compose backend at upgrade time. Worst case if something doesn’t come over cleanly, you will be able to re-add it and use the same host paths as you mentioned
You’ll have some different options for this. If you want to monitor the development of the new apps, you can do so here. We’ve already got a pull request open for portainer and dockge which will give you additional flexibility if you want to mange your containers via those interfaces as well. We’ll be seeing those merge in over the next month or so. Some remaining bits to land in the middleware / base system first
As mentioned in the original announcement thread ( The Future of Electric Eel and Apps ) all of the TrueNAS Apps catalog (and apps launched through the Custom App button) will migrate to the new Docker Compose back end without requiring users to take any manual actions.
If apps that iX or the community will provide aren’t visible on that /apps/ repo, what’s the process to request or go about adding one? I can see there’s many PRs open on that repo with individual apps that are being added, should we just be adapting a PR and opening one as needed for each app we want to see added?
Even with the ones on that repo, whilst a good start, there’s still outlier apps that will prevent people migrating from third-party catalogues to iX/TrueNAS/Community apps simply due to lack of quantity, or because apps aren’t available via the above in any capacity. Perhaps there should be somewhere (a thread?) where people can request apps to be added if it’s not a case of just opening a PR on the repo?
Edit: Found all the issues on the /charts/ repo with people suggesting chart/app additions. Will take them there, here’s hoping iX can get some traction on all the backlogged requests once the move to Docker is sorted.
Well, at least this will motivate me to finally setup a proper kubernetes cluster at home. I probably should never have used TrueNAS as anything but the storage backend but I was lazy (and my TrueNAS box has a lot of compute available that otherwise goes unused).
I agree with you here. Been a truenas user for 12 months, setup 20 apps.
Was in the process of setting up nextcloud to replace a costly cloud storage subscription in Dropbox.
Sexondly started to write my first helm chart for an app that i wanted added, glad that only started 1 week before the announcement.
Truenas scale has been anything but stable from an apps perspective with breaking changes and additional work required to upgrade major releases.
Moving to docker is the wrong decision on my opinion and will be persisting with kubernetes at this time.
I do however like the other features of Truenas and hope that more investment will be spent on the NAS side of the application and making this even better.
Combining NAS and apps in the one package as good as it sounded on paper just isn’t worth it anymore. If anything I’m now more determined to ensure kubernetes and apps are a permanent stay in my homelab as self contained entities.
I’ve even started to setup more of the other components of truenas smb/unix shares.
If i want to use truenas storage as the underlying storage for my apps still in another product would this be best as an nfs share if using a linux distro?
I like the backup and snapshot functionality available on truenas gui.
Agree for third-party Apps and that is a primary reason for the switch to Docker and Compose. Allow easier importing and migration of Apps.
We will make the transition of Official/Community Apps to Docker easy. However, custom Apps will require some work… if you can’t find a Docker Compose file for it.
Agreed. That holds for a dedicated enterprise NAS. I don’t see how Compose based apps escape this argument though. Any NAS running 99% idle, dedicated or not, is OK to handle either k8s or Docker Compose additionally and save you hardware cost if you accept any risks that come with that. The choice of doing so is up to the end user. Suddenly jumping from k8s to Compose is not OK nor up to the end user in this case. Only a fortunate few will be able to exercise the choice of sticking with k8s
This is exciting news. Has anyone evaluated using Podman as a drop-in replacement for Docker? This would provide greater security and a similar experience to Docker.
