What is the best way to deploy nextcloud?

[ninjai]

I just started messing with scale. I would like to migrate to it, but I'm probably struggling the concepts of docker and kubernetes a bit here.

Here's what I currently do, and essentially what I'm trying to replicate:
* I have apps like plex, nextcloud, transmissions, etc - deployed as iocage jails
* I back them up with periodic snapshots + replication
* If I break something, I can just roll back a snap - simple.

Here's what I'm trying to understand, but not sure if I do or not:
* On the apps section, my understanding is that it is using docker containers
* If a container is torn down and restarted, all data within that container is lost
* I can map ZFS datasets to directories within containers, and those are persistent between container restarts

So for nextcloud for example, I do not want to use the prebuild "app". I don't want to use port address translation on a container. I found another image, here:

nextcloud - LinuxServer.io

[Nextcloud](https://nextcloud.com/) gives you access to all your files wherever you are. Where are your photos and documents? With Nextcloud you pick a server of your choice, at home, in a data center or at a provider. And that is where your files will be. Nextcloud runs on that server...

docs.linuxserver.io

But I think it's using some different stuff than me. For one I can't find out what it's using for a database. So I'm not sure how I can migrate.

I'm willing to completely reconfigure it if I can figure out how to properly manage data persistence and snapshots using ZFS. I do not want to reboot the container one way and lose my changes :D.

What is the best way to leverage app containers for a nextcloud deployment?

*I did extensively search this forum and was not able to find the answers I'm seeking

 

[truecharts]

You want all the features of SCALE Apps, but without SCALE Apps.
Then you need to use the "build docker" button, it's hacky IP assignmment system and hope for the best.
(because in practice the build-docker button is secretly "just another app", so most of your tools should work)

Considering some of your questions are super basic, there is quite a high risk of dataloss.
Really for your usecase Apps seem to be the best tool for the job, besides migration which can be tricky at times (but that's almost always the case).

In both cases backup is not officially supported yet, but we made a CLI based WIP guide for it on our website, that should also work for official Apps and the "big blue button"

 

[ninjai]

You want all the features of SCALE Apps, but without SCALE Apps.

Are SCALE Apps those prebuilt ones? Plex, Nextcloud, minio, etc? Ya the thing I didn't like about those was the inability to bridge their IPs to my network. I'm also skeptical on updates on these. Maybe I'm wrong but I remember more than once migrating off of the plugins on freenas/truenas core because of lack of updates and other quirks and found it a lot easier to maintain myself.

Then you need to use the "build docker" button, it's hacky IP assignmment system and hope for the best.

I've done this already, I don't understand what's hacky about the IP assignment, can you please elaborate? I spent a few hours reading into kubernetes and docker last night and it seems like these are all kubernetes cubes with their own local virtual network adapter (IE they can all speak to one another with some dynamically assigned address local to the system), but you can also set up an external interface which is just a bridge adapter into my LAN which is exactly what I want so I did that.

Considering some of your questions are super basic, there is quite a high risk of dataloss.

Can you elaborate on this too? For example, on nextcloud I attached ZFS datasets within the container like this:

This is where my old nextcloud files are located. When I turn on the container, I can access this path without issue. I can still take periodic snapshots of this ZFS dataset so I'm not sure where the data loss part comes in.

Additionally, I learned pretty quickly how the whole thing basically reinstalls itself every time it's booted and stopped, this is where I read into Persistent Volume Claims. I think that's what this is here:

At least in testing it seems to be. This basically maps that directory within the container (/config) to a dataset located in my pool, which is all dynamically handled by kubernetes it seems:

As per this: https://www.truenas.com/docs/scale/apps/usingapps/#custom-applications
It says that these mappings are stored on a ZFS dataset, here:
/ix-applications/releases/<ContainerName>/volumes/ix-volumes/.
Which I can see is accurate:

This is the data within the /config directory of the container. When I tear the container down and boot it back up, this all stays. So given that it's a ZFS dataset, it can do snapshots. If it can do snapshots, I can back it up. If I can do those things I don't see where the data loss comes in.

In any case can you please help me understand?

 

[truecharts]

Most of the things you mentioned are tools we for more or less complicated technical reasons, decided not to use for our App catalog. For the same reason we will refraign from endless discussions which design choices (ix or ours) are superior.

We, sadly enough, don't have the time to go completely into technical detail about what we wrote above, we just wanted to highlight that with your requirements it might be best to use the Apps.

 

[ninjai]

I'm not trying to start a discussion around which design choice is superior, I'm just trying to understand how I can leverage kubernetes within scale to effectively deploy the apps I want to. Sorry if you felt that's the way the discussion was going, was not my intention at all.

 

[truecharts]

I'm not trying to start a discussion around which design choice is superior, I'm just trying to understand how I can leverage kubernetes within scale to effectively deploy the apps I want to. Sorry if you felt that's the way the discussion was going, was not my intention at all.

Non offence taken :)
Byond our Apps and the official Apps, your current way of doing things is pretty solid :)