Requesting docker-compose example

[hhinma]

I am looking for a simple, detailed example on how to implement a docker-compose based application in TrueNAS SCALE, or pointers to where I can find this information. All of the material I have found so far rapidly delves into discussions about k3s and helm charts and all manner of capabilities that are provided by that - I cannot find a simple, direct answer to the question "how do I migrate my docker compose application to run in TrueNAS scale"? I am hoping the info is in here somewhere and that I just haven't found it yet.

 

[sretalla]

Since a helm chart is what you need at the end, I suppose starting here is a good idea:

Translate a Docker Compose File to Kubernetes Resources

What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift). More information can be found on the Kompose website at http://kompose.io. Before you begin You need to have a Kubernetes cluster, and the kubectl...

kubernetes.io

I'm no expert on how to then use that in the Apps section, but I think the truecharts catalog provides this template for exactly the purpose you're talking about so you can make your own app list:

GitHub - truecharts/template: Use this to start your own Basic Catalog

Use this to start your own Basic Catalog. Contribute to truecharts/template development by creating an account on GitHub.

github.com

 

[ornias]

"how do I migrate my docker compose application to run in TrueNAS scale"?

What you are basically asking is:
"How do I migrate docker-compose to helm-kubernetes?"

And the answer is always:
manually with hard labour, either by yourself or using the work others have done already.

 

[Ixian]

I cannot find a simple, direct answer to the question "how do I migrate my docker compose application to run in TrueNAS scale"? I am hoping the info is in here somewhere and that I just haven't found it yet.

You aren't able to find the answer because it doesn't exist. There's no easy way to do it. You need to figure out what the equivalents are in Kubernetes - in some cases, this is simple, in others, not - and basically re-create it. You can do this with the app templates provided, or in newer releases of SCALE you can add single "docker" apps via the GUI though in the end those are just docker containers run inside a k3s pod.

As I've said in other threads I am puzzled by who Ix system intends to be the end user for how they've implemented apps, given it satisfies neither businesses looking to capitalize on their existing Kubernetes deployments or single-deployment/NAS end users who need something simpler.

In the end the easy answer to your question could be "disable SCALE apps completely and use Docker/Docker-compose with Portainer, Yacht, or CLI tools". Which you can technically do today with some simple workarounds, but the long-term viability of that approach is still up in the air (i.e. will Ix systems make a breaking change down the road, etc.). Not a great situation.

 

[ornias]

As I've said in other threads I am puzzled by who Ix system intends to be the end user for how they've implemented apps, given it satisfies neither businesses looking to capitalize on their existing Kubernetes deployments or single-deployment/NAS end users who need something simpler.

I'm quite certain that SCALE Apps do not have a much higher factor of knowhow required than docker-compose.
For Truecharts most Apps can be installed by just entering the name and spamming next. Try that with Docker-Compose ;-)

With our recent daily released quick tutorial video's, everyone should be able to install TrueCharts Apps with a lot more ease than docker-compose, but I'm not sure you checked those out already ;-)

The goals where to provide an easier and more solid plugin system than CORE and I think they succeeded very well doing that. But it still is mostly suited for Enthousiast and, in the future, SMB users.

 

[inman.turbo]

I'm quite certain that SCALE Apps do not have a much higher factor of knowhow required than docker-compose.
For Truecharts most Apps can be installed by just entering the name and spamming next. Try that with Docker-Compose ;-)

With our recent daily released quick tutorial video's, everyone should be able to install TrueCharts Apps with a lot more ease than docker-compose, but I'm not sure you checked those out already ;

Many people are already familiar with docker-compose, so this is an empty statement.

 

[ornias]

Many people are already familiar with docker-compose, so this is an empty statement.

Many people are also familiar with Helm and kubernetes. In fact: These are industry standards, while Docker-Compose is not. Just because you doesn't know something and most people you know don't, doesn't make it fact.
I think iX create a great way of getting people to use industry standard software, while keeping it as easy as possible.

Calling the many hours we spend on quick start tutorials an empty statement, is not something i'm even close to take serieusly.

 

[inman.turbo]

Many people are also familiar with Helm and kubernetes. In fact: These are industry standards, while Docker-Compose is not. Just because you doesn't know something and most people you know don't, doesn't make it fact.
I think iX create a great way of getting people to use industry standard software, while keeping it as easy as possible.

Calling the many hours we spend on quick start tutorials an empty statement, is not something i'm even close to take serieusly.

Industry standard or not (and it is only an industry standard insomuch as it has standards and it is part of an industry -- it itself is not a standard ), docker and docker-compose are far more ubiquitous. There are plenty using docker who have no idea what Kubernetes even is. You'd be hard pressed to find someone who deals with Kubernetes and helm charts on a day to day basis and can't wrap their head around the yaml in a docker-compose file.

The question here isn't about the quantification of know how, but particularly what one might know. It's more common for people to be familiar with docker and docker compose, especially when it come to DIY'ers, laymen, Homelab'ers and even web developers. Most of the people who work with Kubernetes are DevOps and systems or operations engineers in a particular corner dedicated to managing containers on a large scale. Not many people know about docker shim, OCI compliance, etc. etc.

You tell someone with five kids and small businesses and no time who spent a bunch of sleepless nights figuring out docker so he could run a web app to help keep his shop afloat that Kubernetes takes no more knowhow than docker. Well, OK? But, I already know docker, he'll say, doesn't that help? Well maybe a little but not much, so ..

But hey yeah it is great that you are doing what you are doing, but telling the docker guy that starting over and learning something new takes no more KNOW HOW than doing what he already KNOWS HOW to do just makes no sense to me.

And I certainly don't mean to offend, or belittle any of your hard work. I was just thinking about that statement in particular.

 

[morganL]

It should be noted that native Docker and docker-compose can be supported as a VM. Its easy to use that for existing applications while Kubernetes and the Apps catalog get used for newer applications. There are very few restrictions with this model.

 

[ornias]

But hey yeah it is great that you are doing what you are doing, but telling the docker guy that starting over and learning something new takes no more KNOW HOW than doing what he already KNOWS HOW to do just makes no sense to me.

- Name
- next, next, next, submit

Sorry, but if thats too hard i'm not even interested in the feedback tbh.

 

[inman.turbo]

- Name
- next, next, next, submit

Sorry, but if thats too hard i'm not even interested in the feedback tbh.

Really? That will work for an app that is already available in a catelog. Not for his app that he has running on docker-compose.

should be noted that native Docker and docker-compose can be supported as a VM.

That is his simplest option here. He can spin up a VM, install docker and docker-compose and have his legacy apps up and running in minutes.

 

[Basil Hendroff]

That is his simplest option here. He can spin up a VM, install docker and docker-compose and have his legacy apps up and running in minutes.

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?'

 

[inman.turbo]

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?'

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.

 

[stavros-k]

Really? That will work for an app that is already available in a catelog. Not for his app that he has running on docker-compose.

Apps out of the box can't have ALL the apps that people want, but with an App request and hopefully later on more maintainers, we could add apps faster.

Actually adding an app is not too hard, @ornias have built a beast of a common lib. It's just a lot of copy pasta and some renames.
The problem comes in maintaining it. Or tracing small things that don't work.
And also you can have your own catalog with predefined values and just hit install > name > submit. Just like with compose, but in GUI.

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?'

I have never used VM's in BSD, but if i'm not mistaken, with KVM you can pass through devices, like GPU, or Capture cards, or Machine Learning accelerators (which all of them can be used on docker for example).



Yes, Apps as feature in SCALE, in my opinion needs improvements and polishing. But it's still in BETA and I believe that we will see improvements/polishing until release.
Some of the features/polishing I'd like to see is already posted here. This list is mostly compiled by me and some other people in TrueCharts discord.

 

[ornias]

I have never used VM's in BSD, but if i'm not mistaken, with KVM you can pass through devices, like GPU, or Capture cards, or Machine Learning accelerators (which all of them can be used on docker for example).

There are a lot of small issues with the hypervisor in BSD, where KVM is basically an industry standard, so things are a LOT more polished... But thats basically it :)

 

[Patrick M. Hausen]

Ubuntu VMs for docker-compose do run just fine on CORE, though. So if all your other use cases are covered by CORE and you just need that one extra Linux app, e.g. OnlyOffice or Collabora, the technology is available and stable.

 

[inman.turbo]

There are a lot of small issues with the hypervisor in BSD, where KVM is basically an industry standard, so things are a LOT more polished... But thats basically it :)

Qemu/KVM is way more polished. And has tons more driver support. It is the gold standard in the industry. It is really the only open source hypervisor I trust for mission critical deployments. But then I usually just deploy truenas or freenas as a Kernel Based Virtual Machine. Normally I run my docker-compose and kubernetes workers and control planes in VM's as well. It's just really flexible. You can migrate everything out of a cabinet for instance and put it under maintenance.

Of course you can't migrate the Nas when you're using hardware pass-through, but then you don't have to: you can just replicate the pool on another rack.

 

[jct]

Hi there! Long time reader; first time caller. I should know better than to jump straight into the deep end. :}

I count myself as one of those hobbyists who feels warm and comfortable in Docker Compose — and who continues to be frustrated while getting up-to-speed on Kubernetes. So far it's been an arduous journey.

But I agree that Kubernetes is the correct strategy for this project at this time, looking forward.

In fact I came to TrueNAS SCALE and then to FreeNAS and Core by way of trying to coordinate storage for an on-premises K8s cluster.

Maybe Apps is the right model and only needs some love during the beta to reach its potential? But then again, maybe it's just the wrong model up front — not only for lost Docker users but especially for vanilla Kubernetes.

Frankly, I read back into years of discussion as to whether Plugins was ever a realistic or sustainable model for simplifying Jails. It seems as if SCALE had grown out of that discussion in many ways. But then it doubled back, straining to carry the same essential baggage? I suspect that an opportunity was missed.

Overall I'm awestruck to see everyone's hard work. I'm also encouraged to see thoughtful debate. I wish I'd come here with a workable, well-organized, alternate solution, but again I'm still struggling to grasp the field of play.

In my case, unlike most true home hobbyists, I'm looking to apply a bit more SMB mojo to my homelab. I host a non-profit service community, plus I'm teaching my daughter coding. For each of these separately I'd dearly love to gather or create, then review and deploy services by teams using GitLab Auto DevOps with my TrueNAS storage.

Given this, it's likely that my own needs would be better met by learning to integrate Democratic CSI into my own separate K8s cluster. I would like to find clearer introductory content so I can make that work.

But then again: maybe that's a useful data point. Zooming out: perhaps an IT department or a Docker Compose refugee would feel most comfortable managing pods using Kubernetes Dashboard, or Portainer, or GitLab…

If that's true (and if it describes target markets of interest) then maybe custom layers and abstractions aren't the key to the puzzle. Maybe SCALE could focus on hosting a barebones K8s cluster with preconfigured storage orchestration and RBAC for guard rails.

Then Apps and TrueCharts, cordoned within their own namespace, would be pure value-add joy. They wouldn't inadvertently add confusion to end users struggling to find guidance on where their work should/could fit in.

Anyway, delighted to tip my hat to the gang. Thank you immensely for doing all that you do!

 

[danb35]

because they thought they would have a simple 1:1 api for running docker-compose scripts.

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

 

[ornias]

Maybe Apps is the right model and only needs some love during the beta to reach its potential? But then again, maybe it's just the wrong model up front — not only for lost Docker users but especially for vanilla Kubernetes.

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

Frankly, I read back into years of discussion as to whether Plugins was ever a realistic or sustainable model for simplifying Jails. It seems as if SCALE had grown out of that discussion in many ways. But then it doubled back, straining to carry the same essential baggage? I suspect that an opportunity was missed.

The problem with plugins was mostly related to the fact it was flawed and unmaintainable from the get-go. The biggest problems with the plugin system really are not present in SCALE in its current state, those are pretty well mitigated.

Overall I'm awestruck to see everyone's hard work. I'm also encouraged to see thoughtful debate. I wish I'd come here with a workable, well-organized, alternate solution, but again I'm still struggling to grasp the field of play.

There are so many wishes, that I doubt one would be able to 100% fullfill them all.
However: I think iX did a great job with it anyway. by allowing Native Helm access for enterprise users, Apps for one-click installs and the big-blue-button for simple docker containers.

In my case, unlike most true home hobbyists, I'm looking to apply a bit more SMB mojo to my homelab. I host a non-profit service community, plus I'm teaching my daughter coding. For each of these separately I'd dearly love to gather or create, then review and deploy services by teams using GitLab Auto DevOps with my TrueNAS storage.

Given this, it's likely that my own needs would be better met by learning to integrate Democratic CSI into my own separate K8s cluster. I would like to find clearer introductory content so I can make that work.

GitLab Auto seems to be a comparable with things like Flux and ArgoCD, both of which can be run on TrueNAS SCALE, without too many modifications. I think the same should be (tm) possible with GitLab Auto as well.

But then again: maybe that's a useful data point. Zooming out: perhaps an IT department or a Docker Compose refugee would feel most comfortable managing pods using Kubernetes Dashboard, or Portainer, or GitLab…

If that's true (and if it describes target markets of interest) then maybe custom layers and abstractions aren't the key to the puzzle. Maybe SCALE could focus on hosting a barebones K8s cluster with preconfigured storage orchestration and RBAC for guard rails.

Thats precisely what SCALE is doing, SCALE itself doesn't actually abstract much, SCALE Apps are 99% standard Helm charts.
The Storage orchestation (however) requires the API/middleware layer to handle things like upgrade rollbacks and such.

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

Then Apps and TrueCharts, cordoned within their own namespace, would be pure value-add joy. They wouldn't inadvertently add confusion to end users struggling to find guidance on where their work should/could fit in.

SCALE gives every App their own namespace.

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.

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.