How can I create an Ubuntu container ("app") in TrueNAS Scale w/ SSH?

[ajgnet]

Hi guys - I have a bunch of python scripts that I run to organize the files on my media server. Instead of installing the scripts directly on the host, which would require adding a ton of python libraries or using a VM, I thought I could take full advantage of TrueNAS Scale and launch a simple ubuntu docker container with ssh access.

What's a good way to do this?

I tried adding an app with "ubuntu:latest" as the image repository but when I launch the container just closes. From the console, I can launch a container with "-it /bin/bash" to keep the container open until I close it manually. Any idea how I can accomplish something like this through the GUI? Thanks for your help.

 

[waqarahmed]

@ajgnet you can start a ubuntu/debian container easily from the UI and set entrypoint/command to "sleep" and the arguments to "infinity" which would result in the container running and then via UI you can access the console of the container and manipulate it as you would like. To clarify for clarity, in kubernetes ( which SCALE uses for containers ), on each restart of the app - the container is recreated and if you want to have some data which you want to persists like scripts or something related, please configure storage appropriately from the Storage section in the "Launch Docker Image" wizard. Good luck!

 

[ajgnet]

That's exactly what I was looking for! Thank you

 

[ajgnet]

Also, what settings do I use to give this machine its own IP address assigned by DHCP from my network? Is there a way to "bridge" it to the network adapter in use by TrueNAS Scale? I'd prefer this instead of forwarding a port to the internal network. Thank you

 

[beagle]

That's exactly the kind of application where LXC containers come handy. Similar to BSD jails.

 

[sretalla]

It sounds like you want a VM, not a docker container... (or as mentioned just before I hit post, LXC, when that is delivered)

 

[yottabit]

I have the same need, trying to use Debian instead of Ubuntu, basically the same. I had a couple general purpose jails on CORE where I did batch operations, and I need that same functionality on SCALE. Containers is the right approach, less overhead than a VM. I thought K3s & Docker was all we were going to get... I didn't know there what a plan to add LXC/LXD support to the GUI... That would be great if it could be managed just like jails were in warden and then iocage.

Until then I'll keep trying to figure out how to get the debian docker to suit my needs.

 

[Ixian]

A VM for this use case would hardly be any more trouble, in terms of setup or resource usage, than an LXC container.

Heck, you could spin up a tiny VM with Alpine linux installed under 100mb in size that could run Python scripts. Use an NFS soft mount to your media storage and match permissions and you're GTG.

I don't know the latest on LXC support but it hasn't seemed like a high priority so this is probably the best interim approach vs. trying to figure out how to get a Ubuntu/debian docker working through the Apps interface for the same purpose.

 

[yottabit]

A VM would work, but is more complicated (NFS access to the host, for example) and incurs large overhead (NFS client/server, additional kernel running unnecessarily, memory pressure/ballooning, cache duplication, swap duplication, etc.).

Avoiding these complexities and overheads are the reasons I used jails in the first place. In fact, the only VM I had in CORE was to run Linux for one use case where I couldn't run the same software in BSD.

In this respect, Docker or pure LXC is no different really, and both/either should accomplish this goal.

P.S. My use cases are I/O-heavy on disk and network.

 

[Ixian]

A VM would work, but is more complicated (NFS access to the host, for example) and incurs large overhead (NFS client/server, additional kernel running unnecessarily, memory pressure/ballooning, cache duplication, swap duplication, etc.).

Avoiding these complexities and overheads are the reasons I used jails in the first place. In fact, the only VM I had in CORE was to run Linux for one use case where I couldn't run the same software in BSD.

In this respect, Docker or pure LXC is no different really, and both/either should accomplish this goal.

P.S. My use cases are I/O-heavy on disk and network.

For your use case(s), I agree. I was addressing the OP - a collection of Python scripts for media management (Plex enhancement scripts, subtitle cleaners, and so on, I'm guessing - I use several myself) could fit in a low-impact VM no problem and also be quite simple to setup.

An LXC or LXC-like container that segregates userspace while leveraging the underlying kernel, etc. would be better overall, no question. You could use that as a proper docker host vs. a VM among other things, which is why I sincerely hope it's still part of Ix system's plans.

 

[yottabit]

xpost from my other thread after I managed to get the debian docker container into an active state:

Grabbed the container ID from `docker ps` and then used `docker exec -it <container_id> /bin/bash` and it worked. (The shell command in the SCALE UI did not work.)

Next I did `touch /home/testfile`, restarted the container, and then wept as I discovered my testfile was missing.

I guess I will need to use a VM until we get a jail-like solution in SCALE and/or I have enough time to create my own container with the userland I need.

Good learning experience.

 

[amiskell]

xpost from my other thread after I managed to get the debian docker container into an active state:

Grabbed the container ID from `docker ps` and then used `docker exec -it <container_id> /bin/bash` and it worked. (The shell command in the SCALE UI did not work.)

Next I did `touch /home/testfile`, restarted the container, and then wept as I discovered my testfile was missing.

I guess I will need to use a VM until we get a jail-like solution in SCALE and/or I have enough time to create my own container with the userland I need.

Good learning experience.

And this would be normal for a container. Containers are immutable. Any changes you make to a container are gone when the container "restarts" (containers doesn't technically restart, they are destroyed and recreated from their available image).

You could create your own container with all the python tools you need pretty easily. Dockerfiles are pretty easy to create and build. You could almost mount a directory from TrueNAS into the container for persistent storage (e.g. map /mnt/tank/scripts on TrueNAS to /home within the container) to keep persistent storage between container restarts. The trick would be handling things like cronjobs and the like but there's tools like jobber for job scheduling within containers.

 

[Jip-Hop]

P.S. My use cases are I/O-heavy on disk and network.

Perhaps you may be interested in trying out the jailmaker.sh script I'm working on. It creates a persistent 'jail' similar to LXC where you can bind mount any directory from the NAS. Still experimental so I recommend testing it on a non-critical system.

 

[yottabit]

Perhaps you may be interested in trying out the jailmaker.sh script I'm working on. It creates a persistent 'jail' similar to LXC where you can bind mount any directory from the NAS. Still experimental so I recommend testing it on a non-critical system.

I'll check it out sometime. For now I just grabbed a Debian docker image, added what I needed into it, created a new image from it, and backed up the image since it gets cleared every once in a while. Been using it that way successfully for months now. I would like to automate creating it sometime so I can refresh easily with updates, etc., but not urgent at all.