Install Helm Chart Via Command Line

[HarryMuscle]

Is it possible to install a helm chart directly via the command line on TrueNAS Scale? Any tutorials on how to do that? Also curious, will a manually installed helm chart show up in the GUI like other apps?

Thanks,
Harry

 

[xinfli]

Seems it's impossible, it's by design of TNS.

Refer to the discussion here.

 

[truecharts]

Using Helm commands is 100% possible, the command is just not enabled by default because iX doesn't want to support users using it.

The unlock for it is:
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

We use it all the time for bugtracing of our Apps.
But we also have made a previous PoC for running, for example, ArgoCD on SCALE. Which is technically perfectly possible :)

With all things in TrueNAS:
If it's not in either the GUI or API, it's not supported by iX Systems. That goes for shares, mounting storage, gluster and, yes, kubernetes/docker. Sometimes it just works (Gluster),Often you can enable it yourself (Helm) or enable it by hot-patching the system (docker-compose). It's all possible, just very not-supported.

Refer to the discussion here.

Which is just a plain repeat of multiple older threads. The request "allow us direct access to docker-compose and/or kubernetes", has been asked many times before.
As people with a very thorough experience on the SCALE Apps/Kubernetes system, we can say with relative certainty that adding those options will introduce a multitude of possible new bugs for users using the system normally and does not suit well within the design they are making for the long term.

 

[xinfli]

Using Helm commands is 100% possible, the command is just not enabled by default because iX doesn't want to support users using it.

The unlock for it is:
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

We use it all the time for bugtracing of our Apps.
But we also have made a previous PoC for running, for example, ArgoCD on SCALE. Which is technically perfectly possible :)

With all things in TrueNAS:
If it's not in either the GUI or API, it's not supported by iX Systems. That goes for shares, mounting storage, gluster and, yes, kubernetes/docker. Sometimes it just works (Gluster),Often you can enable it yourself (Helm) or enable it by hot-patching the system (docker-compose). It's all possible, just very not-supported.



Which is just a plain repeat of multiple older threads. The request "allow us direct access to docker-compose and/or kubernetes", has been asked many times before.
As people with a very thorough experience on the SCALE Apps/Kubernetes system, we can say with relative certainty that adding those options will introduce a multitude of possible new bugs for users using the system normally and does not suit well within the design they are making for the long term.

Thanks, so technically it's possible, but a bit risky?

Could you give user an option to have their own choice in their own risk?

I'd like to take such risk to use TNS to replace my home server and Synology NAS, but it's impossible for current RC version.

 

[truecharts]

Thanks, so technically it's possible, but a bit risky?
Could you give user an option to have their own choice in their own risk?

Enabling helm is, basically, zero risk.
We even discussed enabling it with iX staff, but they don't want to add the unlock natively because (summarised) "users shouldn't be using the shell on SCALE, outside of troubleshooting"

Disabling Kubernetes completely on the other hand, means writing code that actively intertwines (has to revert), the configuration of their docker system, that means it inherently can break the actually supported system, by allowing it to be disabled.

But, about the "on your own risk" and "without support" arguments... it's a wrong premise. If they offer that switch, would you be "okey" if docker was still simply a brick (aka not working)?
No ofcoarse you would then expect docker to work. Which means, by offering the switch to "do it yourself", you actually added a feature (docker without k3s) that also is expected to be technically supported.

---
So there are basically two different issues here:

1. Expanding the system byond it's current features

For example: running Helm Charts using the native Helm CLI, technically 100% possible, just not officially supported. It's byond the current featureset, but not byond it's technical capabilities

2. Replacing the current featuresset or making breaking changes to it

By disabling kubernetes, running docker-compose, running k8s in a hacked cluster.
All are technically possible with the parts inside SCALE. They do, however, require actually changing how the system works on one or more fundemental levels.


1. is safe
2. is not.

 

[xinfli]

Enabling helm is, basically, zero risk.
We even discussed enabling it with iX staff, but they don't want to add the unlock natively because (summarised) "users shouldn't be using the shell on SCALE, outside of troubleshooting"

Disabling Kubernetes completely on the other hand, means writing code that actively intertwines (has to revert), the configuration of their docker system, that means it inherently can break the actually supported system, by allowing it to be disabled.
......

Thanks, then I think I understand who is expected to be target user of TNS by iX staff, they think TNS users should use everything with UI, users should not care about anything of technical detail, it's better the users should know nothing about technology, so iX staff hope all technical details be hidden and could not be touched by user.

But unfortunately I don't think such user will select TNS (Here I only talk about personal user).

For personal user don't care about technology or know nothing about technology detail, maybe Synology NAS will be a better choice; users understand basic concepts of TNS (ZFS, storage pool, SMB, NFS, etc.) is not such a user.

So the technology level of personal users who select TNS is higher than average, I don't think they are happy to be blocked to touch the shell, and they will not be satisfied that installation of application is controlled by the TNS team or someone else.

And from this discussion: https://www.truenas.com/community/threads/error-deploying-apps-from-truecharts.97167/, you said "It seems that way" ("iX System developers think all TNS users should understand regex"), but they do not hope user to use the shell on SCALE?

Interesting.

 

[jgreco]

It doesn't really matter what you think.

An appliance OS almost always happens to be built out of components that you might inadvertently recognize as more capable and more competent components than the way in which the appliance designer has allowed for.

This makes it very hackable.

However, the problem then becomes that users who have found some random blog post or half-baked clue somewhere on the Internet decide that they are now The Greatest UNIX Powerful SuperUser Since The Epoch, and make some change that kills or corrupts their appliance's firmware.

I am fine with you corrupting your firmware.

The part that I am not fine with is when people who have done this invariably come to the forum, expecting support, and, experience says, quite often don't bother to divulge their skulduggery. This is a strain on the forum, whose participants are generally unpaid members of the community.

So, my suggestion is to either put on your big boy pants, which requires that understand that you can do as you please, expect to own the results, whether spectacular or catastrophic, or you can live within the constraints that the developers have placed, which is generally at a modest level where they feel like they're able to provide basic support and compatibility moving forward.

In short, it is unreasonable for you to expect that the developers support or allow easy access to more than what they are willing to do as part of their design. Feel free to do as you please, but, please, make sure you tell people what you've done before asking for help fixing a mess of your own making, and expect that you might get no help in such a case.

 

[truecharts]

And from this discussion: https://www.truenas.com/community/threads/error-deploying-apps-from-truecharts.97167/, you said "It seems that way" ("iX System developers think all TNS users should understand regex"), but they do not hope user to use the shell on SCALE?

That was obviously a Joke, iX just hasn't come to fix that ;-)

K.S.

 

[HarryMuscle]

After lots of research I was able to come up with the next best thing ... an API call that is the equavalent to the "Launch Docker Image" button in the GUI. It's not a docker compose file or a helm chart but it does solve the problem of having to input lots of repetative data in the GUI and allows scripting the deployment of a docker container. It also allows the container to show up in the GUI and be fully manageable from it which gives me the best of both worlds. A simple example would be to paste (shift + insert) the following into the GUI shell:

Code:

midclt call -job chart.release.create '{
  "catalog": "OFFICIAL",
  "train": "charts",
  "item": "ix-chart",
  "release_name": "emby",
  "version": "latest",
  "values": {
    "image": {
      "pullPolicy": "IfNotPresent",
      "repository": "emby/embyserver",
      "tag": "latest"
    },
    "volumes": [
      {
        "datasetName": "path",
        "mountPath": "/path"
      }
    ],
    "portForwardingList": [
      {
        "containerPort": 9000,
        "nodePort": 9000,
        "protocol": "TCP"
      }
    ],
    "containerEnvironmentVariables": [
      {
        "name": "var_name",
        "value": "var_value"
      }
    ],
    "securityContext": {
      "capabilities": [],
      "privileged": false
    }
  }
}'

I chose Emby for my test and just used placeholders for the paths and environment variables and chose the first port, but this should provide a good starting point. Hope this helps others. I will be going with this approach for my other containers and learning more as I go so if you are attempting this also and have any questions feel free to ask.

Thanks,
Harry

 

[crkinard]

After lots of research I was able to come up with the next best thing ... an API call that is the equavalent to the "Launch Docker Image" button in the GUI. It's not a docker compose file or a helm chart but it does solve the problem of having to input lots of repetative data in the GUI and allows scripting the deployment of a docker container. It also allows the container to show up in the GUI and be fully manageable from it which gives me the best of both worlds. A simple example would be to paste (shift + insert) the following into the GUI shell:

Code:

midclt call -job chart.release.create '{
  "catalog": "OFFICIAL",
  "train": "charts",
  "item": "ix-chart",
  "release_name": "emby",
  "version": "latest",
  "values": {
    "image": {
      "pullPolicy": "IfNotPresent",
      "repository": "emby/embyserver",
      "tag": "latest"
    },
    "volumes": [
      {
        "datasetName": "path",
        "mountPath": "/path"
      }
    ],
    "portForwardingList": [
      {
        "containerPort": 9000,
        "nodePort": 9000,
        "protocol": "TCP"
      }
    ],
    "containerEnvironmentVariables": [
      {
        "name": "var_name",
        "value": "var_value"
      }
    ],
    "securityContext": {
      "capabilities": [],
      "privileged": false
    }
  }
}'

I chose Emby for my test and just used placeholders for the paths and environment variables and chose the first port, but this should provide a good starting point. Hope this helps others. I will be going with this approach for my other containers and learning more as I go so if you are attempting this also and have any questions feel free to ask.

Thanks,
Harry

Crazy necropost but sir you are doing God's work.

Just need to wrestle this to make it to what i need it to do for my containers and I never have to use the AWADFUL GUI again.

 

[PackElend]

After lots of research I was able to come up with the next best thing ... an API call that is the equavalent to the "Launch Docker Image" button in the GUI.

is that still the case?
by the way, how did you find this command? The API documentation can be found via Managing API Keys but they are written slightly differently over there.


At least you find the settings for Apps from the catalogue in

Code:

/mnt/SSD/ix-applications/releases/putty/charts/5.0.0/ix_values.yaml

but that does not apply to Launch Docker Image. I have not found yet the location where its settings are stored.

by the way, it is now, if anyone copies the code above

Code:

midclt call -job chart.release.create '{
  "catalog": "OFFICIAL",

becomes

Code:

midclt call -job chart.release.create '{
  "catalog": "TRUENAS",

 

[Kieros]

is that still the case?
by the way, how did you find this command? The API documentation can be found via Managing API Keys but they are written slightly differently over there.


At least you find the settings for Apps from the catalogue in

Code:

/mnt/SSD/ix-applications/releases/putty/charts/5.0.0/ix_values.yaml

but that does not apply to Launch Docker Image. I have not found yet the location where its settings are stored.

by the way, it is now, if anyone copies the code above

Code:

midclt call -job chart.release.create '{
  "catalog": "OFFICIAL",

becomes

Code:

midclt call -job chart.release.create '{
  "catalog": "TRUENAS",

Does it still apply?

 

[PackElend]

Does it still apply?

what do you mean by this?


here is my file to launch a custom docker image quickly, as a follow-up from https://gist.github.com/Jip-Hop/4704ba4aa87c99f342b2846ed7885a5d?permalink_comment_id=4613182.

Code:

midclt call -job chart.release.create '{
  "catalog": "TRUENAS",
  "train": "charts",
  "item": "ix-chart",
  "release_name": "dind-TEST",
  "version": "latest",

  "values": {
    "chart_metadata": {
        "icon": "https://raw.githubusercontent.com/filebrowser/logo/master/banner.png",
    },
    "image": {
      "pullPolicy": "IfNotPresent",
      "repository": "docker",
      "tag": "latest"
    },
    "hostPathVolumes": [
      {
        "hostPath": "/mnt/SSD/TEST/dind/var",
        "mountPath": "/var/lib/docker",
        "readOnly": false
      },
      {
        "hostPath": "/mnt/SSD/TEST/test",
        "mountPath": "/home/test",
        "readOnly": false
      }
    ],
    "portForwardingList": [
      {
        "containerPort": 443,
        "nodePort": 9443,
        "protocol": "TCP"
      }
    ],
    "containerEnvironmentVariables": [
    ],
    "containerArgs": [
      "--default-address-pool",
      "base=172.20.20.0/16,size=24",
      "--storage-driver",
      "overlay2",
      "--exec-opt",
      "native.cgroupdriver=cgroupfs"
    ],  
    "securityContext": {
      "capabilities": [],
      "privileged": true
    },
    "externalInterfaces": [
      {
        "hostInterface": "br8",
        "ipam": {
          "staticIPConfigurations": [
            "10.10.8.205/24"
          ],
          "staticRoutes": [],
          "type": "static"
        }
      }
    ],
    "portalDetails": {
      "host": "10.10.8.94",
      "port": 443,
      "portalName": "Web Portal12",
      "protocol": "https",
      "useNodeIP": false
    }  
  }
}'

only

Code:

    "chart_metadata": {
        "icon": "https://raw.githubusercontent.com/filebrowser/logo/master/banner.png",
    },

is not working as it is not available in the GUI: https://www.truenas.com/community/threads/docker-icon-and-wegui-link.99792/

You can even mount folders created with https://www.youtube.com/watch?v=XCouS6Zw5vA (File Browser) if you don't want to have each mount be a dataset.

field names for values can be learned using https://www.truenas.com/docs/scale/api/

 

[Kieros]

Awesome that is what I meant with does it still apply. Thank you for all the links and information. Tommorow I will dive into this info you gaved.

 

[PackElend]

Awesome that is what I meant with does it still apply. Thank you for all the links and information. Tommorow I will dive into this info you gaved.

how does it go?
I guess I found the location to find out how a command has to look like.
Open Jobs (uper right corner) -->

History

there is the syntax, so I figured out how to run the delete command, it is a bit trail and error in regard to string, list, elements for the JSON

Code:

midclt call -job chart.release.delete 'dind-sysadmin' '{"delete_unused_images": false}'

 

[Kieros]

I thought it was easier. I haven't dared to try it yet and I was merely looking to use this to add some container that needed usb passthrough. But I could not find such thing in the chart.release. I find it difficult to understand how to find and use the fieldnames and values.

 

[PackElend]

I thought it was easier. I haven't dared to try it yet and I was merely looking to use this to add some container that needed usb passthrough. But I could not find such thing in the chart.release. I find it difficult to understand how to find and use the fieldnames and values.

Are you able to build that container using the GUI?
If so, the full job will appear in Tasks.

 

[Kieros]

Haven't tried that yet. But then still I don't think usb passthrough is available. Kubernetes does not support it yet. A shame that it is not capable off doing this, rather than going privileged. Which is less secure.

And then to think off they will stop with docker.
I am Looking into running natively docker. With a straight course. I am done with these struggles.

It all looks messed up. In the background I see rancher, docker, helm, kubernetes, k3s what the heck. It looks like some big overhead with no straight course. I will go with native. And disable apps. Check out jip-hop jailmaker. It looks very promising. Done some first tests with portainer. Looking good.

 

[PackElend]

Haven't tried that yet. But then still I don't think usb passthrough is available. Kubernetes does not support it yet. A shame that it is not capable off doing this, rather than going privileged. Which is less secure.

And then to think off they will stop with docker.
I am Looking into running natively docker. With a straight course. I am done with these struggles.

It all looks messed up. In the background I see rancher, docker, helm, kubernetes, k3s what the heck. It looks like some big overhead with no straight course. I will go with native. And disable apps. Check out jip-hop jailmaker. It looks very promising. Done some first tests with portainer. Looking good.

let's hope that https://github.com/Jip-Hop/jailmaker still works on v23 there might be official Jail support as mentioned in https://www.truenas.com/community/threads/best-way-to-run-vanilla-docker.108146/.
If you want to learn about the passthrough options read this: https://gist.github.com/Jip-Hop/4704ba4aa87c99f342b2846ed7885a5d, Codelica was quiet successful.

 

[Kieros]

Yes I got this whole thing up and working and testing with it. Thanks and I hope this is something ging to stay. The odds are looking good.