We think it's relevant to make some official statements here.
Even though this is just, yet another, docker-compose topic.
But very saddened to find out that I must use yet another layer, TrueCharts, and Kubernetes.
We're just another, community build, catalog. Not related to iX-Systems.
You don't "have to" use our catalog for anything.
Has there been some new statements? I can only find this so far from the truecharts username:
There is no rumor at all.
Docker-Compose presence is simply not guaranteed by iX-Systems, so it's not guaranteed to stay in the future. Hence it "may" go away.
Actually its binary is even disabled by default on latest version.
.That said, if it gets removed, I'm also out. I find the idea of Kubernetes for single node systems kinda offending, because I don't see what it offers over pure Docker in that context, other than wasting some more energy (backplane thread keeping a CPU core at full blast).
TrueNAS is an enterprise grade storage solution, now supporting enterprise-grade applications as well.
Docker-Compose is simply not an enterprise grade solution and there are many features docker-compose lacks that are vital for enterprise deployments.
About the CPU load, that bug has mostly been solved in the latest nightlies. As far as we're aware
You can have docker images with static ips or dhcp from your main network in the docker-compose container
I have 4 docker networks setup within the compose app; one on my local network ip (the same subnet truenas is on), and 3 for various vlans on my network
These can be setup within portainer or the way I do it is console into the docker-compose app and run the following:
docker network create -d macvlan --subnet=192.168.x.0/24 --gateway=192.168.x.1 -o parent=br0 Internal
docker network create -d macvlan --subnet=192.168.x.0/24 --gateway=192.168.x.1 -o parent=br0.20 Vlan20
docker network create -d macvlan --subnet=192.168.x.0/24 --gateway=192.168.x.1 -o parent=br0.21 Vlan21
docker network create -d macvlan --subnet=192.168.x.0/24 --gateway=192.168.x.1 -o parent=br0.22 Vlan22
br0 in my case is a bridged adapter setup on the Truenas host. I have tested Internal using DHCP and static IP's from my router and all work without issues. I have also tested the Vlan's although only with static ip's and all was fine there as well
The docker-compose app is configured in a way that allowed itself full access to the main TrueNas nic's and should therefore have no issues doing anything you can on a bare metal host (that I am aware of at least)
This setup is indeed correct and should work without significant issues :)
Ok like I said i'll have a look. Not sure if you saw this, as I edited my last response and you may have missed it: When I watched this
https://www.youtube.com/watch?v=QXooywQSfJY he mentioned that it is one of the limitations that you should not define a network that is the same as the host.
EDIT: Ah I misspoke..... it's not supposed to conflict with
KUBERNETES networks... not the
Host as I originally thought :).
Perhaps this has life afterall.... i'll need to take a look more deeply.
From the top of the head, this is correct.
The video's should always be viewed as a companion to the writhen guide, in this case (baring url changes in the future):
While Docker-Compose is not officially supported by iX Systems, we have designed a special "Docker-Compose" App, that is available in the "core" train.
truecharts.org
We're going to remake the video's next year to get rid of issues like these. The previous video creator (HeavyBullets) got a lot of freedom and some minute references where not caught when reviewing the video's prior to release.
If this works out then, like
@morganL said before, making Docker-Compose TrueCharts App an official app then that would probably help.
Thanks for the tips.
We want to highlight that the Docker-Compose App, uses the official docker "docker-in-docker" container and a minute addition to add docker-compose (and nano). The App is configured very simply to use the host stack and ignore kubernetes where possible.
This is all in accordance to what SCALE Apps are allowed to be doing by iX-Systems, so the design is in fact already officially supported. It's not some sort of unsupported "hack", it a normally supported SCALE App, using official containers.
There is also not much you can design differently, baring some minute details.
Docker is already there because Kubernetes needs it -- unless it's decided to switch to a different container run time. Since docker is already on the system, it's not really going off into uncharted territory by asking for docker-compose as they are all in the same family.
As
@morganL already highlighted earlier.
You inherently cannot run both kubernetes on dockershim and docker-compose at the same time. It has been tested and tried and will not work.
FYI... the future of TrueNAS SCALE is containers, Apps and Catalogs,
TrueCharts happens to be the first and largest 3rd party Catalog.. we applaud them for their effort.
Other Catalogs may be created and cultivated...... its an open ecosystem.
We indeed also want to highlight that the SCALE Apps ecosystem is not limited to TrueCharts in any way shape or form.
It's not likely that there will be many more catalogs of our size, As there are only a few handsfull of people with experience with 250+ helm-chart repositories world-wide. But smaller onces are, and should be, cultivated.
The official Apps are focussed on those that we need to provide systemic testing and support for, We can't do them all.
We want to highlight two parts of this comment, because it's rather important:
1.
K8S-At-Home (and previously the official helm branded helm-repository), closed up shop because it takes INSANE amounts of time to maintain even 100 Helm Charts (which is basically the same as SCALE Apps). They where with multiple maintainers and contributors.
We hit less of their issues, because we've more maintainer hours available and have optimised in certain area's as well. But the core issue stands: Having more than a few dozen SCALE Apps in a catalog becomes expodentially(!) harder to maintain.
This is important for users to keep in mind, when asking for Official Apps.
2.
The support and testing thing.
Sorry, this is awkward:
- Your "support" is non-existing (allowing bugreports for issue != support)
- Your App testing is minimal at best.
- You even have Apps (pihole) that are barely functional to begin with, because of inherent design mistakes.
We're aware that you guys just started investing more heavily on getting dedicated, and more experienced personel, for App maintenance/development. But we do want to push back on, what we consider, marketing lies.
---
In essence, what we want to highlight is that there are many tests in how one want their applications running. Even using the same ecosystem, there sometimes are inherent differences and sometimes those differences barely mater.
Also adding support for totally different ecosystems into the mix, assuming that's even possible, increases these issues even more.
Currently the Apps system as-is, needs a **LOT** of work. We're talking hunderds of thousands of dollars in development costs.
Adding more ecosystems and complications is simply not feasable within a reasonable development timeframe.
How we know? We need to work with the issues on a daily basis ;-)
