Docker-within-Scale Questions

[jeyare]

back to the k3s
I would like to use Kbnts Dashboard to manage this part of the environment.
Running:

Code:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml

everything was created but stuck in kube-bridge: port creations on:

hrtimer: interrupt took XXXXX ns

Did I forget something before this step? Thx.
@impovich : thx for the definition of the shortcut for the kubectl

 

[jeyare]

so everything installed as expected, follow this guide:
https://rancher.com/docs/k3s/latest/en/installation/kube-dashboard/

running the Dashboard by:

Code:

sudo k3s kubectl proxy --port 9002

Result:

Starting to serve on 127.0.0.1:9002

but the dashboard is not available at the host IP address, including all the necessary link def.

tcpdump port 9002
- request received by the host at port 9002


is there someone who already is running the Dashboard?

 

[truecharts]

I would like to use Kbnts Dashboard to manage this part of the environment.

It's important to note that using alternative dashboards (other than SCALE Apps), is not officially supported.
kubectl proxy shouldn't be needed at all, creating a service object with type nodePort or Loadbalancer should be enough.

K.S.

 

[jeyare]

Thx, for the clarification.
The problem of the Scale Apps is the "newborn" status. Don't take it wrong. For the SME segment experience, I need more than 200 clicks through GUI.
Yes, I can click on the Apps from the catalogue and be done. I tested the NextCloud APP, defined there. Peanut. Great. Useful for home users. Not what I'm looking for in my SME environment. And management like Portainer is missing there (used by me a long time).

So back to the reality:
But I have a bunch of my own microservices/containerized by docker + docker/official containers mainly DB - that I would like to transfer them from the existing Syno environment to the TrueNas Scale. And I would like to continue in this way (when I will chose the TN Scale as final destination for the containerized platforms). Portainer also can manage K3S. I would like to stay in this management for many reasons. Manage docker and K3S in the single box is one of them.

Question:
But I can't find a way how to reach TrueNAS Scale node for the Portainer. Is there a way how to manage TrueCharts in the TrueNAS through Portainer?
Thx

 

[truecharts]

The problem of the Scale Apps is the "newborn" status. Don't take it wrong. For the SME segment experience, I need more than 200 clicks through GUI.
Yes, I can click on the Apps from the catalogue and be done. I tested the NextCloud APP, defined there. Peanut. Great. Useful for home users. Not what I'm looking for in my SME environment. And management like Portainer is missing there (used by me a long time).

We view our TrueCharts catalog and the first release of SCALE as "not suitable" for SME/SMB.
Mostly because some features are still missing in the first release of SCALE.

With the second release of SCALE, when kubernetes clustering gets added, we also planned to work on high availability (or at least resiliancy) on our Apps, which would put them in the SME/SMB "ballpark".

And management like Portainer is missing there (used by me a long time).

On purpose, even with TrueCharts, because it isn't supported by iX Systems and certain features baked in (like backups and rollback) are inherently not-working-correctly when using other management tools.
It creates a scenario where an update might destroy your deployments (as they are not guaranteed to survive it by iX Systems) and people pointing at our management Apps.

But I have a bunch of my own microservices/containerized by docker + docker/official containers mainly DB - that I would like to transfer them from the existing Syno environment to the TrueNas Scale.

Thats a bit... odd...
Because that is definately even less SMB/SME grade than some of the currently available SCALE Apps...

Portainer also can manage K3S. I would like to stay in this management for many reasons. Manage docker and K3S in the single box is one of them.

While portainer should technically be able to work, docker and k3s CANNOT be run on the same machine by design.
Even with hacks, it's either-or.
Not every k3s deployment is the same and the on in SCALE does not support combining that with docker, even when running portainer.

But I can't find a way how to reach TrueNAS Scale node for the Portainer. Is there a way how to manage TrueCharts in the TrueNAS through Portainer?

SCALE does not support other management tools nor do we, it's basically considered a hack.
Some things are disabled/prevented on purpose, such as some forms of node-access.

But technically all our Apps are also supplied as plain helm charts, which are, technically, capable of being loaded into portainer or helm natively. However, we do not actively support that. (as we build SCALE Apps primarily)

We do actually add some documentation for the values.yaml variables on the website, in case you want to load our Apps as a Helm-Chart instead. :)

 

[jeyare]

Thx,
more clear in this point.

Maybe I would like to repair my wording - I would like to use single management for docker/k3s containers as Portainer does it. It was maybe understood, that I would like run docker/k3s at the same time in the same host - no. Understand, that this is not the Scale future.

While portainer should technically be able to work, docker and k3s CANNOT be run on the same machine by design.
Even with hacks, it's either-or.
Not every k3s deployment is the same and the on in SCALE does not support combining that with docker, even when running portainer.

no need for hacks. I need a stable environment.

Regarding the Portainer:
- I have an environment setup/rules with no troubles in containers update or weak rollbacks. Daily work.
- no need support from Synology (now), because they don't have support for SMB/SME. The reason, why I'm leaving this platform.
Some power users running on independent Synoforum.com from 4/2019 (deep dive to the virtualization topics).

Back to the Scale APPs conclusion:
- there is no possible way how to change ENV variables or ports or networks right now
- even there is no possible setup for a linked container setup, e.g. one container for web app and another for db ... in your language the Chart dependencies (I would like to use an existing container with MariaDB v.X over MySQL v.X in the APP full-stack provided by you, ...)
- Scale does not support other management tools by definition
- TrueCharts does not support other management tools by definition

Am I right?

 

[truecharts]

- there is no possible way how to change ENV variables or ports or networks right now

Both env-vars and port changes are 100% supported, on every TrueCharts Apps.
Even internal portchanges are supported on most Apps.

Different external networks for each App, is supported within the TrueCharts Ecosystem, using MetalLB. Which is possible to be installed by disabling the integrated loadbalancer, which is possible in Nightly and the future RC2 release.

Splitting internal networks for different Apps, could be done using networkPolicies on kubernetes (it would still be the same subnet, Apps would just be able to be limited to certain IP ranges for communications). We plan to have this included somewhere between januari and april.
But this is a VERY advanced kubernetes feature, so unless you have vast experience with k8s, it's adviced not to use it anyway.

- even there is no possible setup for a linked container setup, e.g. one container for web app and another for db ... in your language the Chart dependencies (I would like to use an existing container with MariaDB v.X over MySQL v.X in the APP full-stack provided by you, ...)

We have thorough documentation on container linking.
But yes, all our Apps get delivered with integrated databases. As it's absolutely crucial to sync the databases and the App when doing a SCALE App Rollback.

In the future this will be expanded to HA databases when clustered kubernetes launches.

- Scale does not support other management tools by definition

It's slightly more complicated:
There is technical support and something "being supported".
Technically it is supported on the current SCALE layout to run other management tools, but it is not being supported by iX Systems, so no guarantee an update won't nuke everything you've build and don't expect support requests to be fixed.

- TrueCharts does not support other management tools by definition

Technically it should work to run the Helm Chart variants of our Apps using plain Helm on SCALE (or a tool that launches Helm charts).
We most likely, just won't accept other management tools as an App currently. Though we have not made a formal decision on that yet.

However, you most likely won't get much support from us if you cannot get our Apps to work as a Helm chart. Unless something is proven to be an actual bug.

K.S.

 

[jeyare]

all our Apps get delivered with integrated databases. As it's absolutely crucial to sync the databases and the App when doing a SCALE App Rollback.

This is really nice for SoHo segment, till a time when some will use Piwigo with 60k photos and delivered DB will stop performing because needs more performance from diff host (what is a common situation). Because with Piwigo I can choose my own db instance.

but this "single monolithic App" idea is in contradiction with your explanation:

Splitting internal networks for different Apps, could be done using networkPolicies on kubernetes.
Different external networks for each App, is supported within the TrueCharts Ecosystem, using MetalLB. Which is possible to be installed by disabling the integrated loadbalancer

because no one from SoHo will understand it

And last:

However, you most likely won't get much support from us if you cannot get our Apps to work as a Helm chart.

in the docker based world:
e.g. for Unifi controller running on Mongo DB, there is more suitable use ui.community directly
where is an added value for the SME/SMB environment - just the only possible way to use containers modified for k3s from you?
How you will cover the situation when some would like to use Telegraf+InfluxDB+Grafana but with Influx version 1.8 and not in 2.0 because the new one uses diff. Flux language which isn't compatible?

Question:
- it means, that all databases inside the "monolithic" containers use the same setup of root, psw, db names, ... ?

 

[truecharts]

This is really nice for SoHo segment, till a time when some will use Piwigo with 60k photos and delivered DB will stop performing because needs more performance from diff host (what is a common situation). Because with Piwigo I can choose my own db instance.

We are a kubernetes native project, where we aim that the complete solution is rolled out in the same kubernetes cluster.

As we explained earlier we view the first release of SCALE (22.02) as SOHO only, as it does not support multi-node kubernetes clusters. For the later release of SCALE supporting kubernetes clusters, we will be working on both HA databases and spreading of load.

In our opinion, it's not yet ready for SMB/SME use.

but this "single monolithic App" idea is in contradiction with your explanation:

It's not a monolithic App. The databases are seperate containers in the backend, that can be loadbalanced accordingly, which, as explained, will be more thorougly employed on future SCALE releases.

It's also not in contradiction with anything, because such features are always nicely hidden behind advanced settings checkboxes.
We offer a LOT of options most users will never use. That doesn't mean they are worthless, just because you won't use them.

We are also already working our butts off, getting closer to SMB/SME grade. Just because a future is useless for most people now, doesn't mean it doesn't have a place in our design for the future.

for Unifi controller running on Mongo DB, there is more suitable use ui.community directly

No idea what you are trying to say here.

where is an added value for the SME/SMB environment

We don't offer an SME/SMB product yet, as explained a few times now.
Nor does iX Systems when it comes to SCALE Apps, in our opinion.

just the only possible way to use containers modified for k3s from you?

We, generally, don't build the containers (yet). There are some future drafts for going (more) in that direction, but those are not anywhere close to being actively worked on.

How you will cover the situation when some would like to use Telegraf+InfluxDB+Grafana but with Influx version 1.8 and not in 2.0 because the new one uses diff. Flux language which isn't compatible?

In case a breaking change is just breaking because a company restructured stuff, we aim to make migration as easy as possible.

In cases like Influx 1 to Influxdb 2, it would be considered a completely new product (As that's how other projects view it as well), hence there would just be InfluxDB-1 and InfluxDB-2.

Question:
- it means, that all databases inside the "monolithic" containers use the same setup of root, psw, db names, ... ?

We at TrueCharts (as can be read in one of our latest posts thoroughly laying out our security views), take security serieusly.
Obviously passwords are randomised. DB names and usernames are not randomised however.

In case a user wants additional security, the best way of doing that would be implementing networkPolicies in the future.

---
All being said:

We are our own community, with our own goals and idea's. To which we are (somewhat) accountable.
So we will leave it at this. If you've any input on our project, you can converse with our community directly, using the usual channels.


K.S.

 

[jeyare]

no ned more explanation

 

[vampirebyte]

We just want to mention, for posterity, that now we run portainer from truecharts and that works beautifully for our SME for web development needs, including cert-manager + ingress with SSL. Also, we run a separate docker VM that we also added to the portainer config, so we can manage this too, alongside the integrated k3s local node.

 

[truecharts]

We just want to mention, for posterity, that now we run portainer from truecharts and that works beautifully for our SME for web development needs, including cert-manager + ingress with SSL. Also, we run a separate docker VM that we also added to the portainer config, so we can manage this too, alongside the integrated k3s local node.

Thats a very neat solution you made there, technically this would also be possible using a docker-in-docker chart/app as well, for those interested!