Truenas Scale Docker

[Imran]

Hello Guys,

I am planning to install true nas scale. Pls advise if docker application is available to be installed. If not how can this be archived to connect to cloudfare tunnels for remote access.

Any other reliable solution apart from jailbreak.

Thanks in advance for your responses.

[etorix]

@Imran

Any other reliable solution apart from jailbreak.

The reliable solution you’re looking for is “jailmaker”, not breaker.

[LarsR]

or wait till later this year when native docker & docker-compose support will be implemented in the next version of truenas called electric eel

[sfatula]

@etorix

The reliable solution you’re looking for is “jailmaker”, not breaker.

Personally avoiding it, want to stay native Scale. I do hope this is addressed one day as well, right from the github site:

" USING THIS SCRIPT IS AT YOUR OWN RISK! IT COMES WITHOUT WARRANTY AND IS NOT SUPPORTED BY IXSYSTEMS."

Is it actually still the case? Is IX Systems not supporting the use of the code, i.e., just volunteers are? What happens should he go away?

[Stux]

The jailmaker disclaimer is really irrelevant. It’s open source.

What’s more important is IX’s disclaimer

Sandboxes (Jail-like Containers)

It’s an official advanced feature. The core feature is not going away. They won’t “support” it. Which is not actually 100% true, as iX themselves have made tutorials using jailmaker, and are testing gpu support using jailmaker. And accepting PRs/bug reports against TNS for issues triggered by jailmaker.

Having said that, I think @Jip-Hop could probably tone down the last part of the disclaimer

Although it is correct, IX Systems does not provide technical support for the Jailmaker script.

Nor any other community provided script for TrueNAS.

[sfatula]

I wouldn’t call that irrelevant. A software update could render it unusable/unstable, let’s say a worst case like sort of happened with ZFS/kernel changes in Dragonfish. I understand it’s not going away, but, my question is what effort would IX provide to fix it? What if the issue is an incompatibility and the open source needs fixed, who might fix it? That is not a concern for many larger open source projects. It can definitely be the case for smaller projects or abandonware. Heck, what if a new version of the underlying linux code breaks it?

I am not bashing it. I am just curious as to where it really stands as far as support. I see the guy providing a lot of help to people which is admirable. But what if he gets tired of it, i.e. burn out? There are still changes to the code and fixes being made as long as he is around.

Yeah, it’s kind of we won’t support it, but, we’ll accommodate it, lol. I realize it’s a good thing coming from the Core guys. But it’s a divergent path too. Why should IX invest in Eel and docker related UI stuff if people are not using it due to jails and rolling their own?

Just curious how this fits in really more than anything. I am always glad to see new options. I guess I’d like to see a clearer policy regarding it, and, perhaps the tone down you mentioned. But factual too.

[etorix]

One month ago, deploying Helm charts from TrueCharts looked like a good, supported, idea…

I suppose that there’s no guarantee that iX will not break jailmaker, or remove nspawn, in a future release. But doing so would irrate a lot more people than the k3s removal.

[Jip-Hop]

This may reassure you about the future of jails:

@kris

Jailmaker is a nice tool. We figure its only time before we do a proper UI-based “sandboxes/jails” system in SCALE and when we do that we’d expect it to carry forward any current jailmaker managed environments fairly easily.

And even if I were to stop working on jailmaker, and TrueNAS hasn’t yet come around to implementing a Sandboxes management feature, you’d still be able to run your jails as long as systemd-nspawn is installed on the system.

You don’t even need the jailmaker script at all to run jails, it’s just a convenience wrapper script around systemd-nspawn and related commands. In fact, once you’ve setup your jails you might as well remove jlmkr.py completely and just use systemd-nspawn directly to start your jail. That’s why jlmkr.py prints the command it uses to start the jail:

Starting jail {jail_name} with the following command:

Which looks something like this:

systemd-run --property=KillMode=mixed --property=Type=notify --property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 --property=Delegate=yes --property=TasksMax=infinity --collect --setenv=SYSTEMD_NSPAWN_LOCK=0 --unit=jlmkr-docker --working-directory=./jails/docker ‘–description=My nspawn jail docker [created with jailmaker]’ --property=ExecStartPre=/mnt/ssdev02/jailmaker/jails/docker/.ExecStartPre – systemd-nspawn --keep-unit --quiet --boot --bind-ro=/sys/module --inaccessible=/sys/module/apparmor --machine=docker --directory=rootfs --notify-ready=yes --network-macvlan=enp4s0 --resolv-conf=bind-host ‘–system-call-filter=add_key keyctl bpf’

And there’s at least one other script which use the same approach I came up with, without depending on jailmaker.

[sfatula]

Well, you’ll forgive me for skepticism, in the same post you link to, they were talking about Kubernetes too and we know where that went.

I suspect though that nspawn will endure. It’s been around a while, they have incentive to keep it (esp Core users). The systemd haters here don’t have to use it I suppose.

The question will be, how many folks will adopt it and does that conflict with IX development of native docker compose or not. I am guessing the more basic users will want to simply use the UI on new systems to run their containers. But we’ll see how it shakes out. Already been questions on reddit about this.

[Captain_Morgan]

@sfatula

The question will be, how many folks will adopt it and does that conflict with IX development of native docker compose or not. I am guessing the more basic users will want to simply use the UI on new systems to run their containers. But we’ll see how it shakes out. Already been questions on reddit about this.

The combination of Sandboxes and Apps was deliberately chosen for the long-term.

Sandboxes provides a jails-like environment…almost lightweight VMs with good access to the ZFS file system. It can run a whole Kubernetes instance or Docker instance. The user has to administer that environment. TrueNAS helps administer the environment, but not the internal applications.

The Apps environment provides point and click applications that are easier for users to start, configure and operate.

Both can be run on the same system, but they are independent islands. They can be connected via networking, but it will be like connecting to another machine.

VMs are also independent.

Why support all three? - we have a diverse user and customer base.

We don’t really care whether users use Apps or Sandboxes… we just want a happy TrueNAS community with successful outcomes.

However, we don’t want to provide Apps functionality on Sandboxes… or visa-versa. So, select your tools based on their missions.

[sfatula]

Ok, that’s the kind of thing I was looking for, specifically, long-term.

I will probably move my HAOS to a “jail” one day.